[
https://issues.apache.org/jira/browse/ATLAS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091541#comment-16091541
]
David Radley commented on ATLAS-1698:
-------------------------------------
Thanks [~grahamwallis]
great feedback. somments in <<David ....>> sections
Regarding CRUD:
To expand on the listed CRUD operations, is it fair to say that a user would
need to:
Create - either a Glossary, a Term, Category or Classification <<David yes -
classification instances need to be off an entity>>
Create - a relationship between a pair of Categories (for hierarchy), a
Category and a Term, or between a pair of Terms (for any of context, related
terms, spine objects). <<David yes and Glosary to glossary , glossary to term,
glossary to category>>
Create - a classification relationship between a Classification and either a
Glossary, Category or Term <<David As classificaiton is not an entity it does
not have a relationship in the Atlas sesnse of the word>>-
Create - a relationship between a Referenceable and a Term (for Semantic
Assignment) <<David yes - maybe this should be a Referencable and an asset >>
Read - any of a Glossary, Term, Category, Classification or any of the
relationships listed above <<David yes>>
Do they also need to read the Entity in a Semantic Assignment, and if so does
that include the entity's attributes and/or relationships? <<David I am not
sure what you mean by "read the Entity in a Semantic Assignment". We can
navigate to it. >>
Update of any of the above.
Delete of any of the above.
Regarding graph formats:
There are a number of graph serialisation formats - including both JSON and
XML. The most popular are GraphML (XML) and GraphSON (JSON). They are both well
supported by Tinkerpop. Personally I think GraphSON is quite verbose, but
that's just my opinion. Regarding jsongraph (as suggested in the PDF and which
is different to GraphSON) I suspect that it may not currently be sufficiently
expressive for Atlas. The lack of edge ids is an example. We could of course
contribute to jsongraph, but we should choose carefully what format(s) to
support.<<David I am thinoing the user requests the format they want - so it is
extensible >>
Regarding graph-style visualization:
D3 is a good visualization tool, but be aware that it's scalability is limited
in relation to drawing graphs - a few thousand elements is OK but SVG will max
out above that. Canvas scales better. WebGL scales better still (but is harder
to use).
Regarding the REST API:
Do you intentionally have both v2/omas/glossary/
{guid} and v2/omas/glossary/guid/{guid}
? <<David -I am still thinking about which format to use. having guid is in
line with existing Atlas but is not very rest. Without is we may need a
glossary resource name that is not the root >>
Wouldn't all v2/omas/glossary/... URIs need the glossary {guid)? <<David - I
like this idea - as it will look more rest friendly I will make this change >>
Wouldn't v2/omas/glossary/category/classifications also need the category
<<David - yes I think so>>
{guid}?
Wouldn't v2/omas/glossary/term/classifications also need the term {guid}
<<David - yes I think so>>
?
Should we also have v2/omas/glossary/
{guid}/term/{guid}
/assets, to allow for retrieval of all assets with a specified term? <<David -
assets and search are not included as this time>>
And v2/omas/glossary/
{guid}/assets/{guid} <<David I am not sure we would have this -as the glossary
does not own assets - apart from by virtual of it owning terms that have assets
assigned >>
/terms to retrieve all the terms associated with an Asset? <<David - yes - I
have not done assets and search yet >>
Do we also need to allow navigation via Term to (set of) Category - i.e.
v2/omas/glossary
{guid}/term/{guid} / <<David I am thinking I need to add
/v2/omas/glossary/{glossaryguid}/term/{termguid}/attributes/{attributeName}
this would return a set of the relationship attributes and the same for
categories>>
/categories?
Does the REST API also need to support exploration by relationship type? e.g.
retrieve Terms that are Synonyms of a specified Term? I guess that might look
something like v2/omas/glossary/
{guid}/term/{guid}
/synonyms. Similarly for other types of Term<->Term relationship. <<David
/v2/omas/glossary/{glossaryguid}/term/{termguid}/attributes/{attributeName}
should cover this>>
> Create Glossary OMAS API
> ------------------------
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
> Issue Type: Sub-task
> Reporter: David Radley
> Assignee: David Radley
> Labels: VirtualDataConnector
> Attachments: apidocs-4.zip, Atlas Glossary OMAS API proposal v1.0
> .pdf, Atlas Glossary OMAS API proposal v1.1.pdf
>
>
> The Glossary OMAS provides a specialized API for glossary applications to
> retrieve and store their glossary metadata and link assets of different types
> to these glossary entries.
> The Glossary OMAS makes heavy use of the Area 2 open metadata model. See
> https://cwiki.apache.org/confluence/display/ATLAS/Area+2+-+Glossary
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
