[DAS2] Why use URIs for feature IDs?

Helt,Gregg Gregg_Helt at affymetrix.com
Thu Feb 9 15:27:57 UTC 2006

I think that as Thomas says, using URI fragment notation, 
is a perfectly valid URI and thus is acceptable as a feature ID.

But, if the intent is to construct feature URIs using fragment
identifiers in combination with either ID attributes (as defined in a
DTD) or xml:id attributes, as an alternative approach to URI = ID
attribute with xml:base resolution, I think it would get messy.

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.  But then if the feature is returned as part of a query,
and the feature with attribute id="id12345", then the feature URI using
standard fragment notation would be 
In other words there would be a very large number of possible feature
URIs, with query string gunk in them, identifying the same feature.
Unless we define a nonstandard way of constructing fragment identifiers
that chops off the query string.

Instead of something nonstandard I'd rather use xml:base, adhere to the
XML Base spec, and allow the feature id attribute to be full or relative
URIs.  Then specifying in the top element that 
xml:base = http://das2.sanger.ac.uk/ensembl35/features/, a feature
returned by the features query whose with attribute id="id12345"
resolves the feature URI to:

There might even be a way to fiddle with xml:base and id to use a "#"
instead of the last "/", though I'm not at all sure about that.


> From: Thomas Down [mailto:td2 at sanger.ac.uk]
> Sent: Wednesday, February 08, 2006 3:21 PM
> To: Helt,Gregg
> Cc: DAS/2
> Subject: Re: [DAS2] Why use URIs for feature IDs?
> [I should prefix my comments here by saying that I don't actually
> have a terribly strong opinion on this matter *except that* I'd
> really like the spec to be explicit on how feature query language
> works...  Does it go .../features?type=exon, .../features?type=types/
> exon, or .../features?type=http://das2.sanger.ac.uk/ensembl35/types/
> exon?].
> Anyway, I'm still having a bit of trouble seeing why features need
> individually GETable URIs.  The use case I remember from the
> conference call was that it would be nice to be able to describe DAS/
> 2 features in RDF documents.  I guess that makes sense to me, but for
> this purpose is there anything wrong with a URI like:
>             http://das2.sanger.ac.uk/ensembl35/features#id12345
> This seems compatible with Andrew's ID proposal.
> My memory of RDF/DAML/OWL/etc is that most objects which get
> described in such documents are actually fragment identifiers in
> larger documents, rather than individually GETable entities.  Am I
> missing something here?
>                 Thomas
> On 8 Feb 2006, at 18:12, Helt,Gregg wrote:
> >       Regarding using URIs for DAS features, here's the quote from
> > Paul
> > Prescod that I used in the original DAS/2 grant proposal addressing
> > the
> > question "why use URIs?".  From
> > http://www.prescod.net/rest/rpc_for_get.html :
> >
> > You can give that URI address to anyone, anywhere and they can
> > reuse it.
> > In particular this means that we can compose applications that were
> > not
> > thought of in advance. Google is an example of an application that
> > composed "after the fact" out of URIs. Yahoo is another...There are
> > raft of deployed W3C recommendations that work with information
> > related
> > through URIs. Many of these are XML-related specifications that
> > work as
> > well in API-like applications as in user interface-based
> > These include: XPath, XPointer, XSLT, XLink, RDF, XInclude, XQuery,
> > xml-stylesheet.  Information published through HTTP URIs can be
> > combined
> > through XInclude, queried and sorted through XQuery and XSLT,
> > rendered with xml-stylesheet, related through RDF, linked through
> > XLink,
> > pointed into through XPointer.
> >
> >
> >
> > _______________________________________________
> > DAS2 mailing list
> > DAS2 at portal.open-bio.org
> > http://portal.open-bio.org/mailman/listinfo/das2

More information about the DAS2 mailing list