[DAS2] (x)link

Andrew Dalke dalke at dalkescientific.com
Thu Nov 17 02:35:32 UTC 2005


I mentioned having a generic <link> tag, again based on Atom.

Steve replied:
> Not sure about this one yet. In the Atom API, the value of the rel
> attribute is restricted to a controlled vocabulary of link
> relationships and available services pertaining to editing and
> publishing syndicated content on the web:
> http://atomenabled.org/developers/api/atom-api- 
> spec.php#rfc.section.5.4.1
>
> What would a controlled vocab for DAS resources be?

I don't think I understand the Atom one.  Turns out I was actually
looking at the Atom publishing protocol at
    http://code.blogger.com/archives/atom-docs.html

which defines links including

   <link rel="service.feed" href="https://www.blogger.com/atom/1"
         title="my first blog." type="application/x.atom+xml" />
   <link rel="service.post" href="https://www.blogger.com/atom/1"
         title="my first blog." type="application/x.atom+xml" />
   <link rel="service.feed" href="https://www.blogger.com/atom/2"
         title="fromage blog" type="application/x.atom+xml" />
   <link rel="service.post" href="https://www.blogger.com/atom/2"
         title="fromage blog" type="application/x.atom+xml" />

     The service.post is the URI where you would send an Entry
    to post to your blog. The service.feed is the URI where you
    would make an Atom API request to see the Blog's latest entries.

We could define similar links like:
   - where to edit and/or lock the given resource
   - how to get a list of locks
   - how to get from the given DAS resource to it's
      parent (ie, how to go "up" in the tree, in the case
      of a cross-link from another server)

These could be done as distinct elements or done as qualifications
of an existing element.  The advantage of the latter (using a <link>)
is that others may add their own link types.


> Skimming through the DAS/2 retrieval spec, our use of hrefs is
> simply for pointing at the location of resources on the web
> containing some specified content (e.g., documentation, database
> entry, image data, etc.).

But they are used in different contexts (for human browsing, for
machine fetching, for "service" requests).

> The next/prev/start idea for Atom might have good applicability in the
> DAS world for iterating through versions of annotations or assemblies
> (e.g., rel='link-to-gene-on-next-version-of-genome'). One relationship
> that would be useful for DAS would be 'latest', to get the latest
> version of an annotation.

Hmm.  So every annotation would have an optional <link> section?

In the current scheme do we always get the most recent version of
an annotation?  I didn't realize there was any way to get another
version, except if it's been edited while you weren't looking.

> DAS get URLs themselves seem fairly self-documenting (it's clear a
> given link is for feature, type, or sequence for example), so having a
> separate rel attribute may not provide much additional value for these
> links. But it might be handy for versioning and for DAS/2 writebacks.

I hadn't thought of versioning; I was thinking more of writebacks
an and how to find the parent.

I was also thinking of structure data where I might want the
experimental x-ray density data for a a given structure.  That
might be done like

  <link rel="density.experimental_xray" type="chemical/x-ccp4-edm"
     href="http://blah.blah/">

That's part of the newly submitted DAS proposal so should not really  
drive
this work.


Steve also mentioned xlink.  I've been looking at the spec but
still don't understand its implications.  There are several^H^Hmany
parts to the spec I don't understand, especially in the context of DAS.
locator? "arcrole"?  "actuate"?

Are all our links "simple"?  Do we use anything else because the
href?

Also, I see no mention in that spec of content-type.  One of the
things in the Atom spec is support (though not in the spec proper)
for alternate or multiple way to resolve a link

<link rel="something" title="This is a title">
   <x:mirror href="http://here/"/>
   <x:mirror href="http://there/"/>
   <x:mirror href="http://everywhere/"/>
</link>

or multiple formats

<link title="Look at the mighty squid">
   <x:alt href="http://squid.example.com/squid.gif" />
   <x:alt href="http://squid.example.org/squid.png" />
</link>

(That is, a <link> may contain subelements and these subelements,
if in something other than the "das" namespace, are free to
add variant meanings.)


	
					Andrew
					dalke at dalkescientific.com




More information about the DAS2 mailing list