- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Thu, 20 Mar 2008 16:36:41 -0400
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Phil Archer <parcher@icra.org>, Mark Nottingham <mnot@mnot.net>, www-tag@w3.org, Jonathan Rees <jar@creativecommons.org>
Jonathan, you may want to note the GRDDL WG's use-case [2]. Alan Ruttenberg wrote: [snip] > Isn't a "profile" just like any other document that defines a number > of relationships? The current name for such things are "ontologies", > and they generally live in RDF or OWL files. I guess I don't see why > we need to introduce a new name here when we have a mechanism that > works and is already part of the architecture. i.e. If a rel is a URI > that names a property, then we figure out what it means in the usual > way - by doing a GET of the URI and looking at what is returned. > > In the case you give, I would write this as: > > Link-Prefix: "a", "http://profile.namespace.com/relation#" > Link-Prefix: "", "http://www.iana.org/assignments/link-relations#" > Link: <file.ext1>; rel="a:rel-1" > Link: <file.ext2>; rel="a:rel-2" > Link: <my.css>; rel="stylesheet" > > Assuming that "stylesheet" means the property > <http://www.iana.org/assignments/link-relations#stylesheet> > and that <profile.namespace> is actually some URI such as > "http://profile.namespace.com/relation#" > > To my mind this maximally borrows from current SW practice > > BTW, I don't have any preference for the syntax of the Link-Prefix > header - could equally be any of > Link-Prefix: "a";"http://profile.namespace.com/relation#" > Link-Prefix: a=http://profile.namespace.com/relation# > Link-Prefix: a;"http://profile.namespace.com/relation#" 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. [1]http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-01.txt [2]http://www.w3.org/TR/grddl-scenarios/#header_use_case thanks, harry > Best, > > -Alan > >> >> Phil. >> >> >> >> >> [1] >> http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0468.html >> >> Alan Ruttenberg wrote: >>> Hi Mark, >>> Having the link types be URIs will be a great help in solving a >>> number of issues we've been dealing with around associating metadata >>> with resources. >>> I have one suggestion for the document - rather than having the >>> link-extensions, with the default (i.e. not necessarily stated in >>> the headers) base of >>> http://www.iana.org/assignments/link-relations.html I would instead >>> either leave that mechanism out, or add something like a >>> Link-Prefix: header that allows one to set a prefix in the way one >>> does for namespaces or RDF serializations. >>> Ideally the IANA registry would be served as RDF (perhaps by >>> conneg). In this way, resolution and discovery of relations could be >>> uniform. An agent wishing to discover what >>> Link-Prefix: "", "http://www.iana.org/assignments/link-relations#" >>> Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" >>> Would do exactly the same thing as working with: >>> Link-Prefix: "dc:", "http://purl.org/dc/terms/" >>> Link: <http://mumble.net/~alanr/ThePersonAlanRuttenberg>; >>> rel="dc:creator" >>> Regards, >>> Alan >>> On Mar 19, 2008, at 3:11 AM, Mark Nottingham wrote: >>>> >>>> See referenced I-D for a rough idea of what I've been kicking >>>> around WRT the Link header with a few people. >>>> >>>> Note that while it resolves the relation mess, it still has to get >>>> some buy-in by both the HTML and Atom communities, as it asks some >>>> non-trivial things of them. >>>> >>>> Also, this draft is still rough, with some outstanding issues >>>> already identified. See discussion on the ietf-http-wg list. >>>> >>>> Cheers, >>>> >>>> >>>> [ note: I've deleted the MIME attachment, because the last time I >>>> forwarded this message, it appeared to crash Mail.app instances >>>> that received it. Oops. ] >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: Internet-Drafts@ietf.org >>>>> Date: 18 March 2008 5:30:01 AM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D ACTION:draft-nottingham-http-link-header-01.txt >>>>> Reply-To: internet-drafts@ietf.org >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : HTTP Header Linking >>>>> Author(s) : M. Nottingham >>>>> Filename : draft-nottingham-http-link-header-01.txt >>>>> Pages : 13 >>>>> Date : 2008-3-17 >>>>> This document clarifies the status of the Link HTTP header and >>>>> attempts to consolidate link relations in a single registry. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-01.txt >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> ______________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> --Mark Nottingham http://www.mnot.net/ >>>> >>>> >> >> --Phil Archer >> Chief Technical Officer, >> Family Online Safety Institute >> w. http://www.fosi.org/people/philarcher/ >> >> >> > > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Thursday, 20 March 2008 20:37:20 UTC