Re: Migrating from slash to fragment

On 2010/05/18, at 19:52, Nathan wrote:

> 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 <> 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 and  
>> has
>> """
>> tim:i con:preferredURI "".
>> """
>> in his FOAF.
> I thought the use of 
>  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: <> .
> ?
> 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?

Yes I meant an "identical" property. The rdfs:comment of  
con:preferredURI says

"A string which is the URI a person, organization, etc, prefers that  
people use for them"

so it doesn't apply to general situations, such as ontology migration.  
(or maybe etc. includes everything? Notice this ontology is for  
contact information)

The link: namespace ( ) was something  
TimBL created. There's link:Document in it, which is probably  
equivalent to foaf:Document.

link:Document is a fundamental principle in Linked Data, so should  
this link:preferredURI be, I think.

(I am totally against to having something as fundamental as  
"Information Resource" in the FOAF ontology)

>> 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.

Notice that in the example below I used the namespace for *DC terms*.  
To justify what I did, notice that if you look up 'dc' in 
  the first his is "" not " 
". You should never identify things without complete URIs :)

Or is there a third namespace? Then I completely misunderstood all  

I don't want to argue whether foaf:maker is equivalent to  
dcterms:creator or not. This is out of topic. But FYI,
"foaf:maker owl:equivalentProperty dcterms:creator" is in the FOAF  
spec already. But again, for an authoring agent or myself, which one  
to use is still very confusing.
>> """foaf:maker link:preferredURI "".  
>> """
>> 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?

Well, I think if you are doing this, you are not deprecating the  
feature. You are simply saying "If you want to use this feature, I  
prefer using this URI...."

I thought about your idea. But generally,

"<A> link:preferredURI B."  implies "<A> owl:sameAs <B>. "

so similarly if dcterms:isRelacedBy is used for URI migrating

"<A> dcterms:isReplacedBy <B>" should imply "<A> owl:sameAs <B>".

So we can infer that "<A> dcterms:isRelacedBy <A> . "
This sounds weird in human language. But I am not totally against  
this. We shouldn't rely on human language too much anyway.


Received on Tuesday, 18 May 2010 11:41:12 UTC