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

On Nov 5, 2009, at 3:08 PM, Antoine Isaac wrote:

> Hi Kingsley,
>
>
>>> 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,
>
>
> Just to clarify it, in case the mails that came after have not done  
> it: using skos:exactMatch should *not* lead to attributing to the  
> two resouces that it relates the union of all data that is attached  
> to them.
>
> I don't understand why transitivity and symmetry alone would allow a  
> reasoner to infer such "smushing/union expansion". Let's consider a  
> ex:connectedByARoad property. I can perfectly make it transitive and  
> symmetric, and yet all the towns that this property relates are not  
> one and the same.

Correct. It is substitutivity that does the smushing.

Pat

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

------------------------------------------------------------
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 Friday, 6 November 2009 16:46:35 UTC