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

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é Ramón Pérez Agüera <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
>
>



-- 
Jose R. Pérez-Agüera

Clinical Assistant Professor
Metadata Research Center
School of Information and Library Science
University of North Carolina at Chapel Hill
email: jaguera@email.unc.edu
Web page: http://www.unc.edu/~jaguera/
MRC website: http://ils.unc.edu/mrc/

Received on Friday, 18 December 2009 15:30:11 UTC