atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nigel Jones (JIRA)" <>
Subject [jira] [Commented] (ATLAS-1698) Create Glossary OMAS API
Date Wed, 19 Jul 2017 14:18:00 GMT


Nigel Jones commented on ATLAS-1698:

A few thoughts
 * I notice the swagger API rendering from the build is a lot weaker/less readable that
or the standalone editor. I wonder if it needs updating? DO you know what tool it uses?
 * In the OCF documentation a series of scoping parameters is suggested. I tried to incorporate
these into (GAF OMAS) though the relevance
of each is dependent on the specific omas/operation, and in particular is of most relevance
to search/set operations rather than retrieval by guid. We should also decide on what consistency
is needed for the way these are scoped. It seems query parms work nicely for a GET.
 * We need to decide how to determine which OMRS to use for this OMAS. This could be statically
configured (property etc) and the same for all apps, or could be provided by the caller. The
OCF document suggests it's caller-specified, so I included "metaData connection" as a query
 * I don't think zone applies to most glossary operations, but might become relevant when
you are returning a graph. Your proposal will filter the type of data returned, but do we
need filtering also such as this once we go down to assets?
 * locale? Is this needed? It can affect sort-ordering for example, not just term translation?
 * namespace guid is a concept we've discussed using to allow for seperate glossaries between
development, test, production (with a default)
 * tenant is also proposed as a common scope parm - this definately applies here
 * "asOfQueryTime" is used for point in time queries

Also for responses I see 200 listed, but we also should have clear mappings for other conditions
& express the http response code + payload.

I tried to do this in my swagger api doc 

In a previous face to face discussion the suggestion that all our implementations should have
a built-in "limit" (the max results we can return) in addition to that espressed on the UI.
A safety mechanism. probably set as a property?

For each OMAS we also need to document the Kafka topics it consumes and produces (I've not
yet done this thoroughly for mine either!)

> Create Glossary OMAS API
> ------------------------
>                 Key: ATLAS-1698
>                 URL:
>             Project: Atlas
>          Issue Type: Sub-task
>            Reporter: David Radley
>            Assignee: David Radley
>              Labels: VirtualDataConnector
>         Attachments:, Atlas Glossary OMAS API proposal v1.0 .pdf, Atlas
Glossary OMAS API proposal v1.1.pdf, Atlas Glossary OMAS API proposal v1.2.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

This message was sent by Atlassian JIRA

View raw message