Re: Side question : mapping OWL classes to SKOS concepts Re: SKOS Guide and owl:sameAs

Bernard Vatant wrote:

> Of course I agree with whatever you write below,  but there is a side
> and still open issue, on which I'm currently dealing internally. How do
> you map (a hierarchy of) classes in an RDFS/OWL ontology to (a hierarchy
> of) SKOS concepts. The rationale of that is that you can model the same
> domain using some OWL ontology for a knowledge base application, and
> using a SKOS taxonomy (so-called) for indexing-retrieval-navigation
> purposes. 

Ok, this is probably a common use case. It's similar to creating SKOS
out of any database no matter if based on RDFS/OWL, SQL or Excel sheets.

> For example in a Tourism agency back-office ontology, I have a
> "Hotel" class  with subclasses "OneStar" to "FiveStar",  but in the
> end-user Web interface I have this simple hierarchy of (SKOS) concepts.
> 
> Accomodation
>    Cheap_Accomodation
>    Standard_Accomodation
>    Luxury_Accomodation
> 
> In the back office ontology, "Hotel du Parc" is an instance of the (OWL)
> class "ThreeStar", with an attached description (document). In the
> end-user interface, the description is indexed by the concept "Standard
> Accomodation". I would like to express in a mapping that any instance of
> "ThreeStar" in the back-office ontology will result in an indexation of
> its description by the concept "Standard Accomodation" in the end-user
> navigation. 
>
> Waht is needed here is a one-way mapping from a OWL class
> hierarchy to a SKOS concept hierarchy. The SKOS concept hierarchy is
> here a sort of "simplified view" of the OWL class hierarchy.

This one-way mapping is not a real semantic "mapping" like the Mappings
in skos mapping vocabulary but it's a transformation. You create an SKOS
Scheme and indexing relations out of data that happens to be RDFS/OWL.

> Seems to me this will be a frequent use case if both OWL ontologies and
> SKOS concept schemes are used in integrated environments. And there is
> no provision, AFAIK, neither from OWL side, nor from SKOS side, for the
> expression of such a mapping. Of course I can use a plain "rdfs:seeAlso"
> 
> a:ThreeStar      rdfs:seeAlso      b:Standard_Accomodation
>
> But this is too weak semantics for the purpose at hand.

There is no semantics in the relation between a:ThreeStar and
b:Standard_Accomodation but the translation. What you want to express is
an inference rule:

In words:

"If a Hotel is a ThreeStar in the back-office ontology then it should be
indexed as Standard_Accomodation in the Concept Scheme that is used for
the end-user interface"

In SPARQL:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX a:    <back-office-ontology>
PREFIX b:    <end-user-concept-scheme>
CONSTRUCT    { ?x skos:subject b:Standard_Accomodation }
WHERE        { ?x rdf:type a:ThreeStar }


Of course you can manage your translation rules with RFC-statements, for
instance:

a:OneStar    my:createSKOS  b:Cheap_Accomodation
a:ThreeStar  my:createSKOS  b:Standard_Accomodation
a:FiveStar   my:createSKOS  b:Luxury_Accomodation

and use this private property for your translation:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX a:    <back-office-ontology>
PREFIX b:    <end-user-concept-scheme>
PREFIX my:   <my-translation-scheme>
CONSTRUCT    { ?x skos:subject ?b }
WHERE        { ?x rdf:type ?a. ?a my:createSKOS ?b }


> Since we need that right now for Mondeca applications, we are developing
> our own vocabulary for it, but of course would be happy to see this
> issue put on the standardisation track.

I don't think so. Well, it could be an independent module, a "Creating
SKOS data out of OWL data"-vocabulary, but you will soon reach special
cases that you better directly treat with SPARQL instead of putting
everything in yet another layer. Think of hotels that are ThreeStar but
have very low rankings in other properties - then you can just create a
special rule in SPARQL to index this hotels with b:Cheap_Accomodation
instead of b:Standard_Accomodation - yet another standard would not be
flexible enough.

Greetings,
Jakob

Received on Thursday, 2 November 2006 13:27:10 UTC