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

Re: Drilling into the LOD Cloud

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 29 Sep 2008 12:36:51 +0100
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-Id: <723E2DFB-7902-4BD5-82CB-68F166E9ADD2@cyganiak.de>
To: "Aldo Bucchi" <aldo.bucchi@gmail.com>


On 29 Sep 2008, at 05:16, Aldo Bucchi wrote:
> I think you're overlooking something....
> If you're using dc:author to state
>
> <http://dbpedia.org/resource/R%C3%B6yksopp> dc:author example:me
>
> ( which translates to: "I *created Royksopp*, the music band" )
>
> And then Umbel states that *they created* the music band ( I made this
> up for the example ).
>
> <http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp> dc:author  
> ex:someoneElse .
>
> you will indeed run into problems when equating the two IDs.
>
> <http://dbpedia.org/resource/R%C3%B6yksopp> owl:sameAs
> <http://umbel.org/umbel/ne/wikipedia/R%C3%B6yksopp>
>
> But, AFAIK, this is *incorrect usage of dc:author* and not a design
> flaw re. owl:sameAs.

Yes, this is incorrect usage of the property. (I presume you mean  
dc:creator.)

> Luckily, neither UMBEL nor  DBpedia seem to be using dc:author  
> incorrectly.
>
> Authorship metadata should not be attached to the ID for the concept,
> but to the vocabulary namespace or through other indirection.

What we usually do: We attach the metadata to the *document* that  
contains the *description* of the entity.

So, in the DBpedia case the authorship information would be attached  
to the URI of the RDF document describing the band:

<http://dbpedia.org/data/R%C3%B6yksopp>

and not to the band's identifier.

Multiple datasets can of course talk about the same band, but they  
will do so in different documents, and the different documents will  
have different metadata.

This is the Named Graph model of metadata management. It works very  
well with Linked Data, but it's less clear how to apply it best to  
SPARQL-accessible RDF data.

> Which brings up another point: how do you state that a URI belongs to
> a given vocabulary.

I'm not convinced that this is a useful thing to do. When defining  
RDFS/OWL terms, you can use rdfs:isDefinedBy to connect the class/ 
property to the defining RDFS/OWL document.

> - URI opaqueness plays against here
> - is this really something we want/need?
> - ...
>
> If what you intend to equate is a document ( which usually have dc:*
> metadata ) with another doc that has different metadata, stop and
> rethink it. You might be wanting to equate the concepts they
> reference.

Yes exactly, nicely put.

Yours,
Richard



>
>
> A
>
> On Sun, Sep 28, 2008 at 6:30 PM, Damian Steer  
> <d.steer@bristol.ac.uk> wrote:
>>
>>
>> On 28 Sep 2008, at 19:01, Kingsley Idehen wrote:
>>
>>>
>>> Dan Brickley wrote:
>>>>
>>>> Kingsley Idehen wrote:
>>>>>
>>>>> Then between UMBEL and OpenCyc:
>>>>>
>>>>> 1. owl:sameAs
>>>>> 2. owl:equivalentClass
>>>>
>>>> If these thingies are owl:sameAs, then presumably they have same
>>>> IP-related characteristics, owners, creation dates etc?
>>>>
>>>> Does that mean Cycorp owns UMBEL?
>>>
>>> Dan,
>>>
>>> No, it implies that in the UMBEL data space you have equivalence  
>>> between
>>> Classes used to define UMBEL subject concepts (subject matter  
>>> entities) and
>>> OpenCyc.
>>
>> I think Dan's point is that owl:sameAs is a very strong statement, as
>> illustrated by the ownership question. If opencyc:Motorcyle
>> owl:equivalentClass umbel:Motorcycle then they have the same  
>> extension.
>> Informally, any use you make of one as a class can be replaced by  
>> the other
>> without changing the meaning of the whole. However if the are  
>> owl:sameAs
>> they name the same thing, so dc:creationDate, dc:creator, cc:license,
>> rdfs:isDefinedBy etc etc are the same for each, which strike me as  
>> unhelpful
>> side effects. owl:equivalentClass is the vocabulary mappers'  
>> friend :-)
>>
>> Damian
>>
>>
>>
>
>
>
> -- 
> :::: Aldo Bucchi ::::
> +56 9 7623 8653
> skype:aldo.bucchi
> twitter:aldonline
> http://aldobucchi.com/
> http://univrz.com/
>
Received on Monday, 29 September 2008 11:37:33 UTC

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