[DAS2] Why use URIs for feature IDs?

[Lincoln Stein]

Hi Folks,

I've drunk the W3C Kool-Aid and do feel that a major feature of DAS/2 as it 
now stands is that all data objects are referenceable as URIs. Furthermore, I 
think it is a handy-dandy feature for them to be fetchable URLs as well, 
having, I suppose, drunk the REST Kool-Aid. For this reason, I prefer the / 
notation to the # notation. Over and above the fact that the #fragment is not 
a part of the URI at all (according to the part of the spec that Andrew 
quoted), a practical issue with the # notation is that all browsers (and, I 
believe, some client-side libraries, although not the Perl LWP) strip out the 
# and whatever follows it. The server never gets a chance to act on the 
fragment.

Since xml:base is giving us a hard time with respect to the queries, and 
causing major confusion and dissension in the group, I'd prefer to go with 
Andrew's strict idea of making all the IDs passed to the queries full URIs. 
In other words, including the properly escaped http://etc.etc in the query 
string. This is going to make it a bit annoying to debug servers from within 
browsers, but will clean up the semantics considerably and once and for all 
remove the confusion about who "owns" a feature versus who "serves" a 
feature.

Lincoln



On Thursday 09 February 2006 10:43, Andrew Dalke wrote:
> 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

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
FOR URGENT MESSAGES & SCHEDULING, 
PLEASE CONTACT MY ASSISTANT, 
SANDRA MICHELSEN, AT michelse at cshl.edu