[DAS] DAS URI resolvability

[Gregg Helt]

Sorry, I think I confused the issue again -- I seem to be on a terminology
abuse binge.  I used "addressable" and "addressability" in referring to URIs
when I should have used "identifiable" and "identifiability".  Please
mentally do s/addressable/identifiable/g and
s/addressability/identifiability/g on everything I've written in the past
week...

I think you and I are in agreement as far as whether DAS URIs should be
resolvable.  Quoting myself from a previous thread I forwarded to the list
last night (with terminology corrections applied):

In general as part of a spec revision (DAS 2.1?) I'd like to eliminate more
of the resolvability requirements in the specification, and specify that
most URIs be used as identifiers with _optional_ resolvability.  After two
years of working with the current spec I've come to believe that for most
cases requiring resolvable URIs is not necessary, places added burden on
server implementations, and limits the ability to do non-authoritative
decentralized annotation.

The spec can be stripped down so that the only URI references required to be
resolvable are those specified by the "query_uri" attribute of the
CAPABILITIES element.

The only problematic part in the DAS/2 annotation retrieval spec would be
the segment URIs.  The current spec needs these to be resolvable as that's
the mechanism used to retrieve residues for a particular segment/sequence.
But I think this could be revised without too much implementation overhead
to merge residues retrieval and the segments query to make something more
like a hybrid of the DAS2.0 segments and DAS1.53 sequence queries.

       Gregg

On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk>wrote:

> The difference between an ID and a URI is not so great, any ID can be a URI
> if we refer to the URN definition. But whether this URI should be resolvable
> (that is, a URL) is a big question. Whilst it is certainly a nice thing to
> be able to do, I'm not convinced of the practicality given the relationship
> between simplicity and adoption of technologies like DAS.
>
> Ignoring the difficulty in making something actually resolvable (which can
> potentially be accomplished for features by just having "
> http://server/das/source/features?feature_id=foo") there is more pressure
> than ever on keeping verbosity low, and I'm not sure if this can be
> accomplished as things are right now when you have different URI prefixes in
> the same document. Gregg, perhaps you can elaborate?
>
> I know you also advocate alternative content negotiation to solve this
> issue - do your alternative formats contain these URIs or do they strip
> them?
>
> Gregg Helt wrote:
>
>> Using the DAS/2.0 specification, this idea of "annotations of annotations"
>> is easy to do.  That's because every feature in DAS/2.0 has a unique URI and
>> is therefore addressable by _any_ other system that uses URIs -- including
>> another DAS/2.0 server:
>>
>> <FEATURE uri="http://somewhere.else/feat123" ... >
>>     <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue XYZ"
>> />
>> </FEATURE>
>>
>> Or if you prefer allowing your meta-annotation to have it's own URI:
>>
>> <FEATURE uri="http//my.server/feat123" ... >
>>      <PROP key="my_thoughts" value="overexpressed in tissue XYZ" />
>>      <LINK href="http://somewhere.else/feat123" rev="meta-annotation" />
>> </FEATURE>
>>
>> Used in this way DAS/2.0 becomes very RDF-like..
>>
>> This is not just a happy accident but the result of a central tenet of
>> DAS/2 -- addressability of all important DAS/2 entities outside the local
>> system via URIs.  The DAS/2 writeback spec is built on top of the DAS/2
>> retrieval spec, so if you're fully implementing the writeback spec you
>> should be able to use this ability to do meta-annotations.
>>
>>      Gregg
>>
>

On Wed, Oct 29, 2008 at 3:15 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Gregg Helt wrote:
>
>>
>> Sorry for being imprecise about URIs, what I meant to say was that every
>> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
>> relative URIs but not absolute URIs, and referring to relative URIs is not
>> particularly useful outside their context.
>>
>
> By relative URI do you mean URN (e.g. SO:12345)? As opposed to the HTML
> definition (e.g. index.html). URNs are still useful since they allow us to
> solve this issue of identifying things that are the same. A resolvable URI
> (i.e. a URL) is undoubtedly "better", but this is semantic web territory and
> I'm not convinced it is necessary for DAS. Certainly I think it would be too
> much a constraint to layer onto the existing spec in one increment. In fact
> even using URNs is not easy for everything - segment IDs cannot have colons.
>
>