Re: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

On Nov 5, 2009, at 1:25 PM, John Graybeal wrote:

>> Thus, far I've simply assumed that skos:exactMatch and owl:sameAs  
>> have similar implementation mechanics re. union expansion, but  
>> their use targets vary i.e. skos:exactMatch works better for  
>> Concept Schemes (where the world view assumes Named Entities e.g.,  
>> "People" aren't Concepts) while owl:sameAs works better for Named  
>> Entities (people, places, and other typical real more things, so to  
>> speak).
>
> I'm sorry, but my understanding of the semantics of owl:sameAs seems  
> to be different than is being implied here -- can someone address  
> this explicitly?
>
> I have always understood owl:sameAs to link (very tightly!) one on- 
> line resource to another.

Strictly, it relates a resource to itself, and to nothing else. Its  
use is to say that two URIs refer to the same resource. If AAA sameAs  
BBB, then there is one resource being talked about, and the two names  
'AAA' and 'BBB' both refer to it. NOte that this is entirely to do  
with what the names refer to, not about things like which name is  
'best' for a given purpose, who 'owns' the name, etc..

>  For example, I could say that my URL is referring to exactly the  
> same concept as someone else's URN.

Right, but...

> So anything said about one concept now applies to the other, if  
> sameAs is used.

Not exactly. Because if the sameAs is true, then these are the SAME  
concept. Its not that they are two doppelgangers which can be switched  
for one another. There really is only one thing, which happens to have  
two names. So PatHayes sameAs PatrickJohnHayes does not say that there  
are two of me that are interchangeable, it says that there is one me  
with two different names.

> Maybe what's confusing me in this exchange is that I could imagine  
> several different URLs that refer to an individual person (for  
> example), but present that individual in different contexts, and the  
> things they say are relative to the context.

Exactly, and the whole basis for the OWL language model is that there  
is just one (global) context within which RDF/OWL reasoning is done.  
If we were to introduce contexts explicitly, then the sameAs  
substitutivity would be blocked, but so would just about all the rest  
of OWL/RDF inferencing. A can be a subclass of B in one context but  
not in another, etc..

> Even though the individuals at http://mywork.com/staff/joebob, http://joebobfamily.name/joebob 
> , and foaf:person=joebob are the same person, that does not mean  
> that owl:sameAs is an acceptable linkage of those 3 resources.

But all that owl:sameAs says is that they are indeed the same (person,  
in this case.) And they are, right? So why is this a problem?  
(Apparently because people read more into sameAs than it was designed  
to carry.)

>  Which suggests "owl:sameAs works better for Named Entitites" is not  
> a good practice to follow, doesn't it?

Agree, this dictum makes no sense at all.

Pat Hayes

>
> John
>
>
>
> On Nov 5, 2009, at 1029, Kingsley Idehen wrote:
>
>> Neubert Joachim wrote:
>>> Hi Simon,
>>> Sorry for causing some misunderstanding: My point was not that you  
>>> SHOULD use skos:Concept. What I rather wanted to say is that it  
>>> does no harm and that it's already in use for named entites.  This  
>>> point arises from the suggestion to use skos:exactMatch/ 
>>> closeMatch. These properties are sub-sub-properties of  
>>> skos:semanticRelation, which entails that subject and object of  
>>> these properties are instances of skos:Concept (since skos:Concept  
>>> are domain and range for skos:semanticRelation).
>>> The great advantage of skos:exactMatch/closeMatch (over  
>>> owl:sameAs) is that their semantic doesn't smush the resources  
>>> with all their properties (like the administrative properties you  
>>> mentioned).
>> Joachim,
>>
>> What do you mean by "smush" are you referring to the union  
>> expansion that results from combing data from all the data sources  
>> in the owl:sameAs relation? I pose my question with the  
>> skos:exactMatch description page URL [1] for context. I see  
>> Transitivity and Symmetry, which are factors re. decision making by  
>> reasoners re: union expansion based on participants in the  
>> relation. Note, by "union expansion" I mean the union of all data  
>> associated with the data items in the relation.
>>
>> Primarily, I just want clarification about "smushing",  relative to  
>> the property definition exposed by the skos:exactMatch URI,  more  
>> than anything else. Thus, far I've simply assumed that  
>> skos:exactMatch and owl:sameAs have similar implementation  
>> mechanics re. union expansion, but their use targets vary i.e.  
>> skos:exactMatch works better for Concept Schemes (where the world  
>> view assumes Named Entities e.g., "People" aren't Concepts) while  
>> owl:sameAs works better for Named Entities (people, places, and  
>> other typical real more things, so to speak).
>>
>>
>> Links:
>>
>> 1. http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch
>>
>> Kingsley
>>> [SNIP]
>>> ..
>>> Cheers, Joachim
>>>
>>> ------------------------------------------------------------------------
>>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@koeln.de]
>>> *Gesendet:* Do 05.11.2009 17:35
>>> *An:* Neubert Joachim
>>> *Cc:* Richard Cyganiak; dbpedia-discussion@lists.sourceforge.net;  
>>> SKOS; Pat Hayes
>>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as  
>>> skos:Concepts?
>>>
>>> Hi
>>>
>>> Neubert Joachim wrote:
>>> > In my eyes, it's completely ok to use skos:exactMatch or  
>>> skos:closeMatch
>>> > in a situation like this (I did it myself for the STW Thesaurus  
>>> for
>>> > Economics mapping to dbpedia).
>>> > > Thesauri and classifications are not restricted to abstract  
>>> concepts.
>>> > Some thesauri deal explicitly with individual things, e.g. the  
>>> widely
>>> > used Getty "Thesaurus of Geographic Names" or "Union List of  
>>> Artist
>>> > Names". Other thesauri (like STW) have sections (or facets, as  
>>> Leonard
>>> > put it) on geografic names along with others containing "pure"  
>>> concepts.
>>> > SKOS, as I understand it, is intended to cover all this and to  
>>> be used
>>> > beyond strict class hierarchies or class/individual dichotomies.
>>>
>>> While I agree that using real-world entities for classification is  
>>> ok I don't think this means you have to declare them to be  
>>> (skos:)concepts. The "has subject" relationship in FRBR [1] for  
>>> example can link a work to a concept but also to places, people,  
>>> events, other works, etc. So in this case you can use real-world  
>>> entities to classify the work (to state what its subjects are) but  
>>> that doesn't mean you declare all those entities to be conceptual.
>>>
>>> So in my eyes there's still value in keeping (skos:)concepts and  
>>> other things apart. Concepts to me are closer to classes than to  
>>> individuals. And as Dan pointed out concepts have administrative  
>>> data attached - they get created and changed etc. so they're  
>>> basically units of organisation.
>>>
>>> I'd therefore prefer using the UMBEL terms or something else for  
>>> aligning real-world entities and concepts.
>>>
>>> > By the way, some of the SKOS properties (especially the
>>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a  
>>> broad range
>>> > of applications. Eg. dbpedia itself could be used as a great  
>>> source for
>>> > synonym candidates by mapping the resources to skos:Concept and  
>>> the
>>> > labels for dbpedia:redirect resources to skos:altLabel.
>>>
>>> Yup, it has a lot of useful annotation terms. They are all  
>>> declared to be annotation properties and deliberately don't have  
>>> skos:Concept in their domain. So you can use them on anything  
>>> which is great!
>>>
>>> Regards,
>>> Simon
>>>
>>>
>>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 -  
>>> scroll down to "5.2.3 Subject Relationships"
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports  
>>> 2008 30-Day trial. Simplify your report design, integration and  
>>> deployment - and focus on what you do best, core application  
>>> coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Dbpedia-discussion mailing list
>>> Dbpedia-discussion@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>>
>>
>>
>> -- 
>>
>>
>> Regards,
>>
>> Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
>> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>>
>>
>>
>>
>>
>
>
> --------------
> I have my new work email address: jgraybeal@ucsd.edu
> --------------
>
> John Graybeal   <mailto:jgraybeal@ucsd.edu>
> phone: 858-534-2162
> Development Manager
> Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 5 November 2009 20:05:35 UTC