Re: Use Cases [Was Re: I-D ACTION:draft-nottingham-http-link-header-01.txt]

Hi Harry,

Technically, it doesn't add anything. But as I believe you note in  
other posts, technical isn't the whole story. I suggested not having  
a default link prefix because I want to set the stage for good  
practices that will lead to seeing the document and semantic web as  
an integrated whole.

In work with SW representations of content, we take as a given that  
there will be many providers of terms. We also try not to have there  
be implicit information, since computational agents don't always deal  
well with implicit.

I'm also think that a fair amount of practice around this will evolve  
from people actually learning from reading the headers, rather than  
reading from the spec.  So having them be complete will help them  
learn the right thing. Here's the scenario I want to avoid:

    "Hmm, I see they have used Link: <http....>; rel="next".  I'm  
serving calendar information. I'll just use Link: <http...>;  
rel="next-week" to let my clients know how to navigate to next week's  
calendar.

Hopefully, having the Link and Link Prefix together will make this  
happen less often than otherwise, and that the curious will follow  
the link to the IANA registry, for example, and learn how to  
effectively create new relations.

Finally I'm not sure that it makes sense to have a single "special"   
registry of relations, which is what the defaulting does. The web is  
decentralized - I'd encourage the atom people, for instance, to  
manage their own relations, publish them in the same way other  
projects publish a set of relations, and use their own namespace for  
them.

Regards,
Alan

On Mar 20, 2008, at 4:36 PM, Harry Halpin wrote:

> I don't see how this gives us any advantage over just going with  
> what is
> in Mark Nottingham's latest draft [1], which is to just use  
> rel=URI, as in:
>
> Link: <file.ext1>; rel="http://profile.namespace.com/relation#rel-1"
> Link: <file.ext2>; rel="http://profile.namespace.com/relation#rel-2"
> Link: <my.css>; rel="stylesheet"
>
> So "stylesheet" would resolve to
> "http://www.iana.org/assignments/link-relations#stylesheet"
>
> This solves the "profile" and "link" headers not matching up and
> remaining ambiguous, is backwards compatible with non-URI link  
> headers,
> and solves our GRDDL use case [2] for using GRDDL. We'd have to do  
> some
> minor changes to our implementations and maybe a minor update to the
> errata of spec and informative test-cases to make this work, but it
> would work.
>
> I think it wins because it does not introduce any new HTTP headers,  
> and
> so is parsimonious, while solving the problem. by relying on a very
> minor change to Link's definition in HTTP. If it does not or  
> creates new
> problems, please explain.