[DAS2] Ontology URIs (was RE: types.rnc)

[Andrew Dalke]

Steve:
> The ontology attribute in the type element is currently documented as:
>
>   # ontology identifier.  The naming scheme is still undecided.
>   # This will be a URI.
>   attribute ontology { text }?,
>
> I think this is too vague. It's subject to lots of interpretation as 
> to what
> it could point at and what it might resolve to. It could justifiably 
> be used
> to identify any of these:

Indeed it could.  There are other parts of DAS which are URI
identifiable but which are not guaranteed to be resolvable.  Eg,
the individual features from a feature search don't need to be
resolvable.  It could be dealt with as an opaque string.

Excepting how it interacts with relative url absolutizing.

> The so_accession attribute gets us most of what we want and should 
> suffice
> for this freeze. In one fell swoop it identifies the ontology and a
> particular term within it, and it defers the issue of ontology URIs.

What about leaving it there as "this is reserved for future use"?

> Some SO things to consider:
>
> 1) Should so_accession be restricted to SOFA (only locatable feature 
> types)?
> If so, call it sofa_accession. (maybe too limiting)

I have no experience with this to guide me.  I'm a structure guy.  ;)

> 2) What about SO versioning? Maybe a 'so_version' attribute would make 
> sense
> (so_version="SOFA 2.1"). SO term IDs are stable across releases, but
> sometimes terms become obsolete and are no longer listed.

No.  That does not work, for two reasons.

You say the IDs are stable across releases.  I assume that includes
that obsolete ones are not reused.  If the client knows how to
interpret "2.1" to get information about an old identifier then
it knows how to find the identifier in a list.

Other reason - you're reinventing the semantics described by
LSIDs.  Why not just create an lsid naming scheme like

   urn:lsid:biodas.org:sofa-2.1:0000123

and use the URI.

Okay, there's a third.  Suppose the client knows nothing about
the so term, even with the version information.  (Eg, it's a new
version, new term, and the client hasn't been updated; or there's
a bug on in the server code causing all numbers to be twice as
large.)  What does the client do?

I assert that it will treat unknown or missing ontology terms as
being identical to an direct descendent from the root node of SO.

Hence obsolete, new and erroneous terms are treated the same,
so having the extra version field doesn't help the client.

					Andrew
					dalke at dalkescientific.com