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

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.

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

Received on Thursday, 5 November 2009 21:08:48 UTC