W3C home > Mailing lists > Public > public-swbp-wg@w3.org > March 2006

RE: SKOS vocabulary as 'simplified view' of OWL ontology - use case : geographical entities

From: John McClure <jmcclure@hypergrove.com>
Date: Tue, 7 Mar 2006 14:56:33 -0800
To: "Bernard Vatant" <bernard.vatant@mondeca.com>, "SKOS" <public-esw-thes@w3.org>
Cc: "SWBPD" <public-swbp-wg@w3.org>
Message-ID: <MGEEIEEKKOMOLNHJAHMKGEHDEAAA.jmcclure@hypergrove.com>
Hi Bernard,

I brought aspects of this same issue up in
http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0067.html in
which I identified four types of topics:

... the name that is assigned to a topic is either (a) a plural-form of a
common noun
(b) a common noun meant in the 'generic' sense (c) a proper noun or (d) a
set of
instances of a proper noun. Examples: (a) Persons (b) Definition of a Person
Person X (d) Person X-types.

My view was that (a) is represented by the extent of a class; (b) is
represented by a class; (c) is represented by a Thing; and (d) is
represented by a Thing that has been "cast" as a Class (yes, in the sense of
the C language).... Now, my belief remains that

... the universe of topics consist of two sets of instances.
The first set are those defined in an ontology, and the second set are those
defined by a user, simply because they are not defined within any ontology
available to the user. This suggests that a topic is but a user-defined
and is thus a metaclass.

I suppose that because my view implies OWL-Full, no response was warranted.
Nevertheless, I am interested in how and whether a topic can be anything BUT
a definition of a class.
  -----Original Message-----
  From: public-swbp-wg-request@w3.org
[mailto:public-swbp-wg-request@w3.org]On Behalf Of Bernard Vatant
  Sent: Monday, March 06, 2006 2:20 AM
  To: SKOS
  Subject: SKOS vocabulary as 'simplified view' of OWL ontology - use case :
geographical entities

  Hi all

  SKOS concepts are likeky to somehow 'match' similar individuals in other
KOS, and singularly OWL ontologies. This question has already been discussed
with no clear answer on what should be a sound/recommended/best practice.
I'm currently working on a typical use case which will maybe help to
illustrate this difficult issue, namely geographical-administrative
entities. The project involves the French National Institute for Statistics
and Economic Studies (INSEE) [1], which is the official provider of facts
and figures concerning the country and its administrative subdivisions. The
project aims to define a RDF representation of the involved entities,
unformally but precisely defined by INSEE in its 'Code Officiel
Géographique' [2]. Administrative structure of France being quite complex
and multi-hierarchical, capturing it in a KOS is quite a challenge, and
seems to need all the expressive power of OWL. The ontology of those
entities relies on a backbone of 'administrative subdivision' relationships,
and a bunch of constraints over those, such as : A 'department' subdivision
is an instance of 'arrondissement', with a 'chef-lieu' (instance of 'city')
which is either the unique department 'prefecture' or a 'sous-prefecture'
etc ... The ontology has also to be extensible to similar entities in other
countries, supporting e.g. the European nomenclature of NUTS [3].
  Such constraints are useful to control ontology integrity, but many
'light-semantic' applications, such as search engines, will need actually
only a simplified view of this ontology, with thesaurus-like relationships
between entities, used for semantic expansion of search. For such uses, a
SKOS representation of geographical entities and their hierarchy would be
good enough, and such a representation could be proposed as a 'simplified
view' of the ontology.
  So the question is : what should be the (recommended) practices to provide
such a simplification? Two main options :

    1.. Don't do that! different uses, different semantics, different
represenations. Entities in the SKOS representation should be defined
independently of the entities in the OWL ontology, with different URIs
supporting different semantics. A city is not a concept, having an
individual both of type skos:Concept and a:Geo-entity is not a good idea.
    2.. Do it for semantic integration : same individual, one URI. The OWL
representation and the SKOS representation will not be used by the same
applications anyway, so there is no practical risk in having individuals
being declared of type skos:Concept in thesaurus-like vocabularies (SKOS),
and of type a:Geo-entity in ontology-like vocabularies (OWL). Having  a
single URI would be useful in an integrated environment using both indexing
and search of documents indexed on geo-entities, and semantic query and
inference on these entities.

  Option 1 is safer, but raises the issue of semantic integration. How will
I assert that this SKOS concept and that OWL entity are somehow representing
the 'same' individual, and what is the meaning of this 'same-ness'? I won't
push again 'hubjects' here, although I could ;-) . Option 2 is my favorite
those days, following the arguments pushed lately by Pat Hayes [4]. But what
I wonder is to which extent the 'simple' SKOS classes and properties should
be tied to the 'complex' OWL classes and properties, for instance should we

    a.. Declare a:Geo-entity as a subclass of skos:Concept ?

    b.. Declare a:subdivisionOf as a subproperty of skos:broader ?

    c.. Declare a:neighbor as a subproperty of skos:related ?

  Such declarations could be useful for OWL-to-SKOS migration, but are
likely, if included in the OWL framework, to bring unsuspected and weird
entailments ...

  Any ideas/suggestions on this are welcome.


  [1] http://www.insee.fr/
  [2] http://www.insee.fr/fr/nom_def_met/nomenclatures/cog/index.asp (in
  [4] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0139.html


  Bernard Vatant

  Knowledge Engineering

  3, cité Nollez 75018 Paris France

  Tel. +33 (0) 871 488 459

  Mail: bernard.vatant@mondeca.com

  Web: www.mondeca.com

  Blog : universimmedia.blogspot.com
Received on Tuesday, 7 March 2006 22:55:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:18 UTC