[DAS2] Why use URIs for feature IDs?

[Helt,Gregg]

Interesting, I hadn't fully absorbed part 4 of the URI spec (rfc2396).
So if I understand correctly:

If we replace everywhere we've called something a "URI" with "URI
reference" we're being correct -- a URI reference can be an absolute or
relative URI, and can also include a fragment identifier.  And according
to the spec saying "the URI" means the absolute URI, not the relative
URI.  So to restate, I think the ids we use in DAS/2 should be URI
references.  Maybe instead of "id" or "uri" we should use "uri_ref" for
the attribute name?

I still see no reason to exclude URI references with fragment
identifiers, though I agree with Lincoln that actually resolving a URL
with a fragment is problematic.  But we're not guaranteeing that these
URI references are URLs anyway.

The capabilities "query_id" attributes are another story.  These need to
be not just URI references but also resolve via XML-Base to full URLs.

	gregg  

> From: das2-bounces at portal.open-bio.org
[mailto:das2-bounces at portal.open-
> bio.org] On Behalf Of Andrew Dalke
> Sent: Thursday, February 09, 2006 7:43 AM
> To: DAS/2
> Subject: Re: [DAS2] Why use URIs for feature IDs?
> 
> Gregg
> > As I understand it a fragment identifier approach would mean
> > URI = (URL of doc feature XML is embedded in) + "#" + value of
> > feature's
> > ID attribute.
> 
> As I understand it the part after the '#' is a query language
> which is document type specific and used by the client.  DAS does not
> define how that query language is used, so it has no meaning in the
> DAS world.
> 
> http://www.ietf.org/rfc/rfc2396.txt
> 
> 4. URI References
> 
>     The term "URI-reference" is used here to denote the common usage
of a
>     resource identifier.  A URI reference may be absolute or relative,
>     and may have additional information attached in the form of a
>     fragment identifier.  However, "the URI" that results from such a
>     reference includes only the absolute URI after the fragment
>     identifier (if any) is removed and after any relative URI is
resolved
>     to its absolute form.  Although it is possible to limit the
>     discussion of URI syntax and semantics to that of the absolute
>     result, most usage of URI is within general URI references, and it
is
>     impossible to obtain the URI from such a reference without also
>     parsing the fragment and resolving the relative form.
>   ....
> 4.1. Fragment Identifier
> 
>     When a URI reference is used to perform a retrieval action on the
>     identified resource, the optional fragment identifier, separated
from
>     the URI by a crosshatch ("#") character, consists of additional
>     reference information to be interpreted by the user agent after
the
>     retrieval action has been successfully completed.  As such, it is
not
>     part of a URI, but is often used in conjunction with a URI.
> 
>        fragment      = *uric
> 
>     The semantics of a fragment identifier is a property of the data
>     resulting from a retrieval action, regardless of the type of URI
used
>     in the reference.  Therefore, the format and interpretation of
>     fragment identifiers is dependent on the media type [RFC2046] of
the
>     retrieval result.  The character restrictions described in Section
2
> 
>     for URI also apply to the fragment in a URI-reference.  Individual
>     media types may define additional restrictions or structure within
>     the fragment for specifying different types of "partial views"
that
>     can be identified within that media type.
> 
>     A fragment identifier is only meaningful when a URI reference is
>     intended for retrieval and the result of that retrieval is a
document
>     for which the identified fragment is consistently defined.
> 
> 
> 
> 					Andrew
> 					dalke at dalkescientific.com
> 
> _______________________________________________
> DAS2 mailing list
> DAS2 at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/das2