Re: Migrating from slash to fragment

KangHao Lu (Kenny) wrote:
> 
> On 2010/05/16, at 5:00, Nathan wrote:
> 
>> Toby Inkster wrote:
>>> On Fri, 14 May 2010 17:53:50 +0100
>>> Nathan <nathan@webr3.org> wrote:
>>>> I'm wondering if there are any recommended paths for migrating RDF 
>>>> or specifically an ontology from slash to fragment URIs (?)
>>> Cool URIs don't change.
> 
> Indeed. But several reasons we might want a canonical way to change URIs:
> - Slash URI requires more HTTP round trips
> - For documents we have 301
> - I personally don't like this owl:sameAs culture. Try to use only one 
> URI for each thing could encourage cross domain links
> 
> TimBL uses the term http://www.w3.org/2000/10/swap/pim/contact# and has
> 
> """
> tim:i con:preferredURI "http://www.w3.org/People/Berners-Lee/card#i".
> """
> in his FOAF.

I thought the use of 
http://www.w3.org/2000/10/swap/pim/contact#preferredURI was a rather 
nice touch tbh, noted it yesterday and have just implemented on a client 
site (because it makes a new foaf for them if they don't yet have one, 
but in the future they may get a foaf, thus i want to point to their 
preferred webid when they make their own).

> I think this can be generalized and it shouldn't be con:preferredURI but 
> something like link:preferredURI.

@prefix link: <http://www.w3.org/2000/10/swap/pim/contact#> .

?

can't see what difference changing the prefix makes when it'd still 
point to the same property; and if you mean make another identical 
property, then why?

> For example, foaf:maker and dc:creator are considered equivalent in the 
> FOAF spec. So in the RDF ontology of FOAF, maybe there should be

they're quite different, dc:creator is typically used with a string 
term, dcterms:creator is pushing towards uri's rather than literals but 
it's still a grey area, whereas foaf:maker is always a uri of a Person.

> """foaf:maker link:preferredURI "http://purl.org/dc/terms/creator". """
> in the ontology.

could be something, but ontology wise I get a feeling you'd only do this 
if you'd deprecated a feature, and in that scenario possible 
dcterms:isReplacedBy would be a more suitable property?

Best,

Nathan

Received on Tuesday, 18 May 2010 11:00:01 UTC