W3C home > Mailing lists > Public > public-lod@w3.org > January 2011

Re: URI Comparisons: RFC 2616 vs. RDF

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Thu, 20 Jan 2011 17:04:53 +0100
Cc: David Booth <david@dbooth.org>, Nathan Rixham <nathan@webr3.org>, Dave Reynolds <dave.e.reynolds@gmail.com>
Message-Id: <6A606AF9-E42F-49EC-8D30-B005DC7CDC2B@ebusiness-unibw.org>
To: "public-lod@w3.org" <public-lod@W3.ORG>
Hi:

On 20.01.2011, at 15:40, Nathan wrote:

> David Booth wrote:
>> On Thu, 2011-01-20 at 13:08 +0000, Dave Reynolds wrote:
>> [ . . . ]
>>>
>>> To make sure that dereference returns what I expect, independent of
>>> aliasing, then I should publish data with explicit base URIs (or  
>>> just
>>> absolute URIs). Publishing with relative URIs and no base is a  
>>> recipe
>>> for having your data look different from different places. Just  
>>> don't do
>>> it.
>> This advice sounds like an excellent candidate for publication in a  
>> best
>> practices document.  And if it is merely best practice guidance,  
>> perhaps
>> that *is* something that the new RDF working group could address.
>
> +1 from me, address at the publishing phase, allow at the consuming  
> phase, keep comparison simple.
>


I am not sure whether you are also talking of RDFa, but in case you  
do, I would like to add the following:

Our experiences with helping about 2,000 sites with adding  
GoodRelations via our form-based tools shows that

1. RDFa is in many cases the only viable way for people to publish RDF
2. They can often not control and not even predict the exact URI of  
the page that will contain the markup (imagine "uncool" URIs loaded  
with parameters etc.)

In those scenarios, relative URIs are essential.

We even recommend that people include an empty

    <div rel="foaf:page" resource=""></div>

at the proper position in the nesting so that there will be a link  
between the data entity and the page that contains it.

Martin
Received on Thursday, 20 January 2011 16:05:27 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:31 UTC