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

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.  For example, I could say that my URL is 
> referring to exactly the same concept as someone else's URN.
You mean: URIs referring to the same thing, from our vantage point, 
hence the owl:sameAs relation connecting the two Entity (Data Item or 
Object) Identifiers.
> So anything said about one concept now applies to the other, if sameAs 
> is used. 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.
Simple example of owl:sameAs between to Entities:

1.  http://tr.im/Eg85 -- holistic view of Entity: Kingsley Idehen in a 
Quad Store. Click on direct co-references tab to see the different 
identifiers for said entity, then use the settings tab to enable 
"owl:sameAs" context rule

2. With owl:sameAs context enabled, click on each Identifier in the 
direct co-reference tab, you will get a union expansion of all the data 
across the Identifiers in that tab. Basically, irrespective of choosen 
Identifier, you get a  union of all the data across all the entities in 
the relation

3. Go back to settings, and uncheck the "owl:sameAs" option, and repeat 
step #2, you will see specific data associated with the each of the 
Identifiers, so the data will vary on an Identifier basis

You can even repeat the above with custom rules, and see the effects of 
these assertions, albeit explicitly scoped to specific user context.
> 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.  Which suggests "owl:sameAs works better for Named 
> Entitites" is not a good practice to follow, doesn't it?
It works for People, Places, and other things that we subjectively deem 
to be "Named Entities".  Of course, the definition of skos:exactMatch 
would imply delivery of similar behavior when you assert an  
"skos:exactMatch" between Concepts, using via their URIs.

So back to my question re. the meaning of "smushing": I assume you do 
mean union expansion of the data exposed by the Entities referenced in 
the relation, in either case. But, the difference between owl:sameAs and 
skos:exactMatch, in this particular case, comes down to Entity Type in 
the relations i.e., Named Entities (owl:sameAs) or Concepts 
(skos:exactMatch).

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


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Thursday, 5 November 2009 20:02:56 UTC