W3C home > Mailing lists > Public > public-lod@w3.org > March 2010

Re: Conneg representation equivalence

From: Nathan <nathan@webr3.org>
Date: Thu, 11 Mar 2010 22:55:10 +0000
Message-ID: <4B9974CE.7000104@webr3.org>
To: Pierre-Antoine Champin <swlists-040405@champin.net>
CC: Toby Inkster <tai@g5n.co.uk>, Linked Data community <public-lod@w3.org>
Pierre-Antoine Champin wrote:
> On 11/03/2010 11:04, Toby Inkster wrote:
>> On Thu, 2010-03-11 at 02:24 +0000, Nathan wrote:
>>> If I have multiple representations of a resource which I consider
>>> equal, let's say one of each of the following: RDF+XML, RDF+N3, SVG
>>> Then should all three representations be considered equivalent?
>> They certainly *could* all represent the same thing. Whether they *do*
>> represent the same thing is a judgement call.
> Well, if they are accessible via the same URI, using content
> negociation, then my reading of the HTTP specification is that they
> *must be* representations of the same resource.
> Not sure what Nathan means by "equivalent"...

that I consider them semantically equal representations of a resource.
for instance "the same" RDF encoded as N3 and RDF+XML.

>>> Is it correct that all representations must have consistent fragment
>>> identifiers in order to be considered equivalent? 
>> A fragment identifier should not identify different things in different
>> representations. (Though it may be unrepresented in some or all of the
>> representations.)
> Is that so?
> If I recall correctly the URI RFC (no internet when writing the mail,
> sorry), the semantics of fragments identifiers depends on the retrieved
> content-type. So why would they *have* to identify the same thing?
> That being said, I agree it sounds like a good practice. Especially if
> you consider an RDF/XML and a Turtle representation of the same RDF
> graph... If their fragment identifier were not consistent, that would be
> a serious headache... But is this rule written somewhere?

yeah in awww http://www.w3.org/TR/webarch/#fragid
Received on Thursday, 11 March 2010 22:55:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:03 UTC