W3C home > Mailing lists > Public > public-lod@w3.org > July 2008

Re: ConNegging on Description Pages (was RE: Southampton Pub data as linked open data)

From: Peter Ansell <ansell.peter@gmail.com>
Date: Thu, 31 Jul 2008 07:51:43 +1000 (EST)
To: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Cc: public-lod@w3.org, semantic-web@w3.org
Message-ID: <7937974.371217454701013.JavaMail.peter@Macintosh-2.local>


----- "Ted Thibodeau Jr" <tthibodeau@openlinksw.com> wrote:

> From: "Ted Thibodeau Jr" <tthibodeau@openlinksw.com>
> To: "Richard Cyganiak" <richard@cyganiak.de>
> Cc: "Tom Heath" <Tom.Heath@talis.com>, "Kingsley Idehen" <kidehen@openlinksw.com>, "John Goodwin"
> <John.Goodwin@ordnancesurvey.co.uk>, public-lod@w3.org, semantic-web@w3.org
> Sent: Thursday, 31 July, 2008 2:58:29 AM GMT +10:00 Brisbane
> Subject: Re: ConNegging on Description Pages (was RE: Southampton Pub data   as linked open data)
>
> Hi, Richard --
> 
> * Richard Cyganiak [7/30/08 3:52 PM +0100] wrote:
> > Again: The TAG disagrees.
> 
> Actually, I think what I said earlier is in complete agreement with
> the TAG.  See section 2.1.1 --
> 
>    2. *If no content negotiation is in place,* serve a canonical
>       representation (generic resource) of the content at
>       http://example.com/ubiquity/resource
> 
> (I've added the first-clause emphasis.)
> 
> (Yes, this was nominally written about "Desktop" and "Mobile"
>  versions of the same page, but what better analogy is there for
>  different formats of the same information?  I don't think the
>  later language variant discussion applies...)
> 
> 
> > http://www.w3.org/2001/tag/doc/alternatives-discovery.html
> >
> > Content negotiation is for selecting between different variants of
> a
> > *single* resource. It's not for redirecting you all over the place.
> 
> Yes.  But what resource did you request?
> 
> Do you think that requesting http://revyu.com/people/tom/about
> with "Accept: application/rdf+xml" is the same as requesting
> http://revyu.com/people/tom/about/rdf with "Accept: text/html"?
> Or that either of these is the same as requesting either resource
> with *no* Accept: header?
> 
> I don't.
> 
> I think that when I request http://revyu.com/people/tom/about/rdf
> with "Accept: text/html", I should get an HTML representation of
> the resource at that address (which may not be an HTML representation
> of RDF/XML, as this URL does not say rdfxml -- so there are many
> possible ways it could be serialized by default).
> 
> When I request it with "Accept: application/rdf+xml", I should
> get an RDF/XML serialization, again, of the resource at that
> location -- which is not the same as the resource of that name!
> 
> If I just want the canonical resource with the name
> http://revyu.com/people/tom/about/rdf ?  I should not use *any*
> Accept: header -- I should just take what the server gives --
> which I believe in this case would be the RDF/XML serialization
> of http://revyu.com/people/tom/about -- the same as I would get
> if I requested http://revyu.com/people/tom/about with
> "Accept: application/rdf+xml".
> 
> Be seeing you,
> 
> Ted

I guess it kind of depends on whether you think content negotiation, or direct URI's are more authoritative. I think you can have a consistent world just by looking at the Content-type of the result, and if you can't process it then you can't process it. Talking about doing content negotiation on the /rdf and /html resources is a red herring, as someone should never have attempted to resolve these because they should never be used in RDF documents, and therefore, to get there you either got redirected there by the server, or you found the link in another representation of that very resource. I don't like a best-practice/standard that eliminates the possibility of showing a typical web browser RDF even if they go directly to the URL of the RDF format. 

It is really suspicious that there is a text/ MIME type on rdf+n3 IMO, as it should clearly be application if the other RDF formats are application. There is more chance of RDF/XML being human understandable with an attached XSLT stylesheet then there is of N3 being human understandable as there is no standard for transforming N3 into human understandable form. 

Don't even get me started on a recommendation to use the utterly generic (read that as "no real information") MIME type, text/plain, for NTriples ;-) With all those angle brackets in NTriples it could never be human readable!

Cheers,

Peter
Received on Wednesday, 30 July 2008 21:52:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:41 UTC