W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2009

Re: how to represent different kind of associative relationships with SKOS?

From: Christophe Dupriez <christophe.dupriez@destin.be>
Date: Fri, 18 Dec 2009 16:47:07 +0100
Message-ID: <4B2BA3FB.2000001@destin.be>
To: José Ramón Pérez Agüera <jose.aguera@gmail.com>
CC: Simon Spero <ses@unc.edu>, public-esw-thes@w3.org
Hi Jos!

Standard bodies and communities have difficulties to adapt their 
mindtrack to individual situations and understandings.
In a way, each of us is "exercizing" its mind with the diverse problems 
submitted. Then the reuse of ideas follows unexpected paths...

My suggestion would be "do not loose useful information" (code it in any 
precise way you need): from complete information,
it is always possible to derive an "adapted" (and less precise) version 
for whatever standard exists at the time you really export.

BUT, this being said, confront your ideas with the community to be sure 
you do not miss important concepts in your "private" design!

Have a nice w.e.

Christophe

Jos Ramn Prez Agera a crit :
> Hi Simon,
>
> I'm sorry for late reply and thank you very much for your very good
> answer. My problem is that I would like to avoid to extend SKOS to
> represent my thesaurus. I have seen similar solutions in the
> literature and I think that the main problem extending SKOS is that we
> lost interoperability, since we create new elements which are not
> represented in SKOS standards.
>
> My system is working with different kind of vocabularies so I need to
> be able to describe any vocabulary in the same way, in order to have a
> only way to search, browse in my bag of concepts. I would like to
> represent my thesaurus without any extension and without lost
> information, but I guess that this is not possible :-)
>
> Anyway, thank very much for your answer
>
> best
>
> jose
>
> 2009/12/14 Simon Spero <ses@unc.edu>:
>   
>> 2009/12/14 Jos Ramn Prez Agera <jose.aguera@gmail.com>
>>     
>>> Hi all,
>>> I have a thesaurus that I want export to SKOS format. However, this
>>> thesaurus defines following relationships between concepts: [see below]
>>>
>>> My first idea was to map all these relationships with skos:related,
>>> however my thesaurus is a geographical thesaurus, therefore relationships
>>> like capital of are important.
>>>
>>> My question is: Is SKOS Core expressive enough to represent these
>>> relations in some way or I should use OWL to represent this thesaurus like
>>> an Ontology?
>>>       
>> Hi Jos,
>>
>> There are a lot of issues that may nudge you one way or the other, but if
>> you're looking to use the thesaurus as a Knowledge Organizing System, rather
>> than a Knowledge Representation System, SKOS can be extended to represent
>> these relations in a way that will be backwards compatible with SKOS Core.
>> The downside is that you may have to do a lot of contorting if you want to
>> express more sophisticated constraints (e.g. a Country must have a capital;
>> the capital must be a city; the city must be contained within the country,
>> etc). [I am punning between Subject and Object for simplicity].
>>
>> Most of the properties are associative, and would thus be sub-properties of
>> skos:related.  Sub-properties of skos:related do not have to be symmetric
>> themselves, so you can use inverted properties to represent this so that a
>> reasoner can infer the appropriate inverse link.
>>
>> There is one relationship in the list that may be hierarchical rather than
>> associative; if it's a specialization of the partitive relationship
>> (BTP/NTP), then you can define it as a sub-property of broaderPartitive or
>> broader. Otherwise, you can just treat it as associative.
>>
>> Simon
>>
>> Symmetric Relationships
>>
>> related to
>>
>> ObjectProperty: relatedTo
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> ally of
>>
>> ObjectProperty: allyOf
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> historical connection
>>
>> ObjectProperty: historicalConnection
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> distinguished from
>>
>> ObjectProperty: distinguishedFrom
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> adjacent to
>>
>> ObjectProperty: adjacentTo
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> coextensive with
>>
>> ObjectProperty: coextensiveWith
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> possibly identified as
>>
>>  ObjectProperty: possiblyIdentifiedAs
>>     Characteristics:
>>         Symmetric
>>     SubPropertyOf:
>>         related
>>
>> Asymmetric Relationships
>>
>> capital of
>> capital is
>>
>> ObjectProperty: capitalOf
>>     InverseOf:
>>         capitalIs
>>     SubPropertyOf:
>>         related
>>
>> ObjectProperty: capitalIs
>>     InverseOf:
>>         capitalOf
>>     SubPropertyOf:
>>         related
>> moved from
>> moved to
>>
>> ObjectProperty: movedFrom
>>     InverseOf:
>>         movedTo
>>     SubPropertyOf:
>>         related
>>
>> ObjectProperty: movedTo
>>     InverseOf:
>>         movedFrom
>>     SubPropertyOf:
>>         related
>>
>>
>> successor of
>> predecessor of
>>
>> ObjectProperty: successorOf
>>     InverseOf:
>>         predecessorOf
>>     SubPropertyOf:
>>         related
>>
>> ObjectProperty: predecessorOf
>>     InverseOf:
>>         successorOf
>>     SubPropertyOf:
>>         related
>>
>> member of
>> member is
>>
>> ObjectProperty: memberOf
>>     InverseOf:
>>         memberIs
>>     SubPropertyOf:
>>         related
>>
>> ObjectProperty: memberIs
>>     InverseOf:
>>         memberOf
>>     SubPropertyOf:
>>         related
>>
>>
>>     
>
>
>
>   


Received on Friday, 18 December 2009 15:48:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:12 UTC