Re: Reviving HTTP Header Linking: Some code and use-cases

Julian Reschke wrote:
> Harry Halpin wrote:
>> ...
>>> So when defining new link relations, I think it's wise to do so in a
>>> way that doesn't rely on profiles.
>> That's a very good point. What our code currently does is, if it sees a
>> single GRDDL Profile header, then it assumes all the Links might be to
>> GRDDL transforms. Ditto with multiple Profiles. If it does not see a
>> GRDDL Profile header, we don't follow the Link header URIs.  While it's
>> not exact disambiguation (which would be better, but I cannot see how
>> that would be accomplished without demanding a 1:1 relationship between
>> Profiles and Headers, which would disturb some other use-cases), it
>> gives one a smaller space of possible URIs to "follow-our-nose", and
>> does disambiguate if only one Profile URI or one Link URI is given.
>>
>> In essence, a GRDDL Profile URI is about the best message one can give
>> that the author intends the page to be GRDDL'ed. A Link with a GRDDL
>> transform is also by itself a pretty good message, but not great, since
>> the author may just be using something like microformats but does not
>> want their page to have a RDF version. In our spec, we call it author
>> "licensing" the GRDDL transform.
>> e say it is possible for non-licensed transforms to be followed, but
>> they may not preserve the meaning that the author of the document
>> intends and thus are inherently not safe.
>> ...
>
> Hm.
>
> So as far as I understand you have two sorts of GRDDL transforms, a
> "licensed" one, and another one.
>
> Why don't you just define two separate link relations then, avoiding
> the Profile stuff?
The links are to the GRDDL transform URIs themselves. And a non-licensed
GRDDL transformation is not technically a GRDDL transformation. That's
why we use Profile in our definition.

>> Since Link is already approved in an earlier RFC and could be used for
>> all sorts of things (i.e. currently there is large discussion of using
>> it to distinguish between different types of SemWeb resources in
>> www-tag, etc.), we don't "follow the link" looking for a GRDDL unless it
>> has the GRDDL Profile URI specified in the HTTP Header.
>>> BR, Julian
>>>
>>> PS: I'm really trying to understand whether Profile is going to help
>>> here.
>> Thanks for your time and patience. I'm just trying to describe what we
>> currently do. We can change if it necessary, but we thought HTTP folks
>> would at least want to know. We thought Profile and Link were a good
>> combo together.
>
> Of course this kind of input is extremely useful, in particular given
> the fact that the WHATWG crowds has removed profile (which I think is
> a problem).
>
> So, let's rephrase this: if a link relation could be a URI (or IRI),
> would we need Profile?
Explain precisely how this would work. I'm not sure what document I
should be looking at to explain "link relations" to me. If there's
another header that can do it, that might work.

I can see how there might be conflict if HTML drops Profile and HTTP
re-instates it. It would be better for it to be either re-instated
uniformly or not. But I think Profile does have a pretty good URI-based
extensibility case going for it.
> BR, Julian


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 11 March 2008 11:42:17 UTC