Subject: Re: link relations and links in general

From: Erik Wilde <[email-masked]>
Date: Sun, 28 Jun 2009 23:07:54 +0200

hello.

Nikunj Mehta wrote:
> For the purposes of read-only usage, what we have with link relations is 
> good enough for identifying semantics. You follow a link and issue a GET 
> request and boom.. you get what you asked for.

but how do you find a link? for atom and atompub, the link can be 
identified because of the element/attribute, but links are only findable 
because of the fixed media type. what i was suggesting (and why i said 
it is a bit off-topic) was a generic way to discover links in resources, 
regardless of the media type (my current thinking is that this should 
work for all XML media types, or more specifically, probably just those 
XML media types which are namespace compliant).

http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html

> The IANA link registry is a good enough place to hold this information, 
> although it may be made even more easy to manage than to write to 
> iana-assign for a new assignment. Whether that is a Wiki or something 
> else, that could be discussed.

i agree that IANA is good for the link relations, if people want to 
standardize them (i would assume that the vast majority of RESTful 
services don't want to register their link relations, though, and they 
should not be required to do so).

> Oracle is certainly interested in putting together some kind of 
> adjectives on Atom resources so that we can better predict the kind of 
> operations that can be performed. For example, the edit and edit-media 
> relations actually mean something beyond other link relations because I 
> can actually manipulate those resources.

the above blog post is a very early draft. my current thinking is that 
LDX should allow link discovery, and discovered links should be 
described by an optional link relation, an optional URI template, an 
optional media type, and optional methods. this way, RESTful services 
could expose as much information as required about what to expect when 
traversing links.

> Likewise, the hierarchy-ID attempts to define a few new semantics for 
> Atom resources that are, for lack of a better word, highlighted as being 
> "master" or "detail" resources. The IETF RFC list is as good a place as 
> any for recording these adjectives and the meanings of these. If there 
> is a way to annotate link entries with such additional semantics so that 
> we can use them even when people create separate rel values, we would 
> love it.

that's not exactly what i was talking about; having link types and 
subtypes might get a bit complicated, i think.

> Of course, I am approaching this from the perspective of a general 
> library that wants to interpret standardized Atom extensions so that we 
> can play a role when we are disconnected from the server. My blog talks 
> a lot about this in the context of AtomDB [1].

again, this is a bit off-list because i am approaching this from the 
perspective of a general library that is supporting RESTful services. 
atom and atompub would be great candidates and good use cases, which is 
why i am interested in feedback from that community.

kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: Subbu Allamaraju <[email-masked]>
Date: Mon, 29 Jun 2009 20:29:54 -0700

>
> Nikunj Mehta wrote:
>> For the purposes of read-only usage, what we have with link  
>> relations is good enough for identifying semantics. You follow a  
>> link and issue a GET request and boom.. you get what you asked for.
>
> identified because of the element/attribute, but links are only  
> findable because of the fixed media type. what i was suggesting (and  
> why i said it is a bit off-topic) was a generic way to discover  
> links in resources, regardless of the media type (my current  
> thinking is that this should work for all XML media types, or more  
> specifically, probably just those XML media types which are  
> namespace compliant).
>

I suspect that this is heading towards XLink.

>
>> The IANA link registry is a good enough place to hold this  
>> information, although it may be made even more easy to manage than  
>> to write to iana-assign for a new assignment. Whether that is a  
>> Wiki or something else, that could be discussed.
>
> services don't want to register their link relations, though, and  
> they should not be required to do so).

And certainly they are not required to do so. People that do not want  
to standardize relations can use URIs.

>> adjectives on Atom resources so that we can better predict the kind  
>> of operations that can be performed. For example, the edit and edit- 
>> media relations actually mean something beyond other link relations  
>> because I can actually manipulate those resources.
>
> the above blog post is a very early draft. my current thinking is  
> that LDX should allow link discovery, and discovered links should be  
> optional media type, and optional methods. this way, RESTful  
> services could expose as much information as required about what to  
> expect when traversing links.

Of these, the media type is already part of the link element. List of  
methods can be described as part of the semantics of the link  
relation. There was a talk about link-templates in the past to address  
URI templates. But given that, URI template is still is not solid,  
links with URI templates may have to wait a bit longer.

Subbu

---

From: Erik Wilde <[email-masked]>
Date: Tue, 30 Jun 2009 11:56:29 -0700

hello subbu.

> I suspect that this is heading towards XLink.

not really. the important difference is that XLink links instances (it 
specifies links for concrete URIs), whereas LDX specifies how to 
discover links in media types. i think this is an important difference, 
and my post definitely failed to be very specific about this. the reason 
why i think it's important is that REST centers around media types and 
following links, and LDX should be a god match with that.

> And certainly they are not required to do so. People that do not want to 
> standardize relations can use URIs.

so is the namespace for link relations strings (standardized) and URIs? 
what about CURIEs? and how could i distinguish between a CURIE and a 
string with a colon? and do some link relation definitions use QNames? i 
am still wondering what "datatype" a link relation should have, or what 
people are already using somewhere.

cheers,

dret.

---

From: Subbu Allamaraju <[email-masked]>
Date: Tue, 30 Jun 2009 22:51:34 -0700

On Jun 30, 2009, at 11:56 AM, Erik Wilde wrote:

> not really. the important difference is that XLink links instances  
> (it specifies links for concrete URIs), whereas LDX specifies how to  
> discover links in media types. i think this is an important  
> difference, and my post definitely failed to be very specific about  
> this. the reason why i think it's important is that REST centers  
> around media types and following links, and LDX should be a god  
> match with that.

Ah I see. Just read your post again. I don't think link discovery on  
its own solves anything, unless the author of the  representation or  
the media type says something about a link appearing at any given  
position an an XML document.

Subbu