Re: Using DBpedia resources as skos:Concepts?

Dear All,


I believe that we are running into a problem if we interpret SKOS:Concept too widely, and allow
persons and other particulars be regarded as SKOS:Concept.
SKOS:Concept clearly has been designed initially to cover universals, i.e., concepts in
the narrower sense, which have "instances" in the real world. This is why SKOS:Concept
has properties broader/narrower:

"The word "broader" should read here as "has broader concept"; the subject of a skos:broader statement is the more specific concept involved
in the assertion and its object is the more generic one. "

This clearly does not apply to persons, events and generally not to all "particulars".

In the semantic Web, we seek clarity by formal ontologies. If we let creep in the
bad practices of decades of abuse of database schemata, because in later use they do not fit what we
initially anticipated, we render the whole idea of ontologies and unambiguous
communication useless.

If we nevertheless introduce a person as a "SKOS:Concept", and regard that we ignore
not applicable properties, i.e., the broader/narrower, we have a schema that deliberately
describes "unintented models".

Nicola Guarino and others regard as one of the most important tasks of a formal ontology
to avoid as much as possible unintended models.
(GUARINO, N. 1998. Formal Ontology and Information Systems. In Formal Ontology in Information Systems. In Proceedings of the 1st 
International Conference, Trento, Italy, 6-8 June 1998, N. GUARINO Ed. IOS Press, 3-15)

We invite, for instance, abuse of "broader" of a person as a group it belongs to, or as
its parents. This would obviously be quite counterproductive. No interoperability is served,
if a KOS is declared as SKOS compatible, but does not use it in an unambiguous sense. Even if
SKOS would declare one kind of use as preferred, it would blur semantics and confuse future reasoning
systems. Persons do not behave like classes of things.

In library classification, persons, such as Shakespeare, may appear as subjects. At least the library of congress
describes clearly such concepts as books talking about "Shakespeare", and not as the person itself.
In this case, the concept "books about Shakespeare" clearly qualifies as SKOS:Concept. Narrower concepts
may be "books about Shakespeare's comedies" or "Shakespeare biographies". The example demonstrates,
that a person as literary subject is distinct from identifying the person.
There is no contradiction to classify a URI for "Shakespeare" as both a literary subject(SKOS:Concept)
and a real person (foaf:person)). However, that does not make every person a subject, and persons behave like a subject!

Leaving the definition of concepts deliberately open, such as SKOS:Concept between universals and particulars, is highly
counterproductive in the general Semantic Web framework.

a) A too wide definition that must be withdrawn later causes backwards incompatibility.
b) A narrower definition can be broadened at a later time, if the impact is well understood

c) RDF is designed so that different ontologies can be freely combined. This requires some foresight
     at which levels of specialization/generalization other ontologies my fit in:
     SKOS Concept currently combines all properties of labelling (preferred etc.) and defining vocabulary with the semantic
         properties that hold only for universals.
     If the concepts of labelling are regarded to be useful for KOS about persons, objects, places, periods and events,
     no other adequate ontology for the latter can make use of these obviously applicable SKOS properties, without
     buying in the unintended semantic properties.

RDF does not foresee to partially reuse properties of a class. Therefore the intended mixing of ontolgies does only
work if no ontology concentrates more properties in a class than are applicable to this class only.

Therefore I strongly recommend:
     Either, SKOS to take a clear position and state that it is only about universals, or better,

==> split SKOS:Concept into two levels, for instance: "SKOS:Concept IsA SKOS:Entity", such that
     SKOS:Entity would describe labeling and Vocabularies a term belongs to, and SKOS:Concept would
     specialize SKOS:Entity to universals. This splitting is obviously backwards compatible with all current
     SKOS applications.

     Then, foaf:person or VIAF:person??? or ULAN:person could be declared as IsA "SKOS:Entity", without interfering
     with the semantics of universals, and everybody can reuse the management of multiple vocabularies proposed by SKOS.



As a practical example, the CIDOC CRM (ISO21127) was deliberately designed to be SKOS compatible from the very conception
of SKOS on, i.e., crm:E55_Type same_as SKOS:Concept, so that a clear interface between factual metadata and terminology
represented as data (SKOS approach) can be guaranteed. If now SKOS takes a fuzzy stance to how particulars fit into it,
SKOS becomes not only incompatible with the CRM, because there is no reasonable class it could fit to, but also with many
other ontologies, and any other dedicated KOS scheme of particulars.


Best,

Martin
-- 

--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Principle Researcher          |  Fax:+30(2810)391638        |
                                |  Email: martin@ics.forth.gr |
                                                              |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                                                              |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                              |
          Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------

Received on Friday, 27 November 2009 19:28:01 UTC