[
https://issues.apache.org/jira/browse/ATLAS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091419#comment-16091419
]
Graham Wallis commented on ATLAS-1698:
--------------------------------------
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
* 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).
* Create - a classification relationship between a Classification and either a
Glossary, Category or Term
* Create - a relationship between a Referenceable and a Term (for Semantic
Assignment)
* Read - any of a Glossary, Term, Category, Classification or any of the
relationships listed above
* 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?
* 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.
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} ?
Wouldn't all v2/omas/glossary/... URIs need the glossary {guid)?
Wouldn't v2/omas/glossary/category/classifications also need the category
{guid}?
Wouldn't v2/omas/glossary/term/classifications also need the term {guid}?
Should we also have v2/omas/glossary/{guid}/term/{guid}/assets, to allow for
retrieval of all assets with a specified term?
And v2/omas/glossary/{guid}/assets/{guid}/terms to retrieve all the terms
associated with an Asset?
Do we also need to allow navigation via Term to (set of) Category - i.e.
v2/omas/glossary/{guid}/term/{guid}/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.
> 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)
