repair unconventional convention: broaderTransitive should be subProperty of broader

Hi SKOS editors,

today I realized a IMHO severe naming issue in the SKOS schema w.r.t. 
skos:broader and skos:broaderTransitive.

My own understandig always was

Christophe Dupriez wrote:
 > +- skos:broader (N1)
 > |   |
 > |   +— skos:broaderTransitive

My translation of the N1 visualization into First Order Logic:

  skos:broaderTransitive(X,Z) <-
      skos:broaderTransitive(X,Y) AND skos:broaderTransitive (Y,Z).

and according to th RDF subproperty axioms:

  skos:broader(X,Y) <-
      skos:broaderTransitive(X,Y).


BUT
http://www.w3.org/TR/2008/WD-skos-reference-20080829/#L4160
suggests in fact:

Christophe Dupriez wrote:
 > +- skos:broaderTransitive
 > |   |
 > |   +— skos:broader


This visualization is coherent to your normal language explanation (c.f. 
WD-skos-reference-20080829/#L4160 )of skos:broaderTransitive.

*Both are pretty confusing* (if not wrong, see below), because IMO it is 
contrary to common naming policies in ontology engineering: You are 
mixing up the intension and extension of a property.

In detail: Concatenating a term (i.e. the string "transitive") to the 
name of a property (here: "has_broader") normally indicates that this 
term adds an additional characteristic (here: being transitive) to this 
property. It follows that the extension of the more restricted property 
is a proper subset of the extension of the less restricted property 
(which is the def of being a subproperty).

The implicit policy behind that naming convention is that a speaking 
object ID (like skos:class, skos:broader etc.) describes informally the 
respective object, here: the property skos:broaderTransitive. This means 
that a string like "Transitive" normally is understood being an informal 
description of an additional characteristics, i.e. the *intension* of 
the property.

This habitus of interpreting substrings of an ontology object ID also 
corresponds with other class naming conventiones, like

- horse
   + horseBlack (a horse which is black)
     . horseBlackMale (a horse which is black and male)
   + whiteHorse

According to this habitus an ontology engineer would expect to have

- broader
   + broaderTransitive (a broader relation which is transitive)
     + broaderTransitiveIrreflexive (... and irreflexive)

What you in SKOS are doing: You are identifying the name of the property 
skos:relatedTransitive with the *inferrable extension* of the property.

"Note especially that, by convention, skos:broader and skos:narrower are 
only used to assert immediate (i.e. direct) hierarchical links between 
two SKOS concepts. By convention, skos:broaderTransitive and 
skos:narrowerTransitive are not used to make assertions, but are instead 
used only to draw inferences."

This convention is strange; I'd not concede such a convention. What you 
have defined here:

- skos:relatedTransitive
   (pairs X,Y that are related by assertion *or* inference)
   - skos:related
     pairs X,Y that are related (only) by assertion

Transferred to the horse example above this would read as:

- horseBlackMale : Things that are horses or black or male
   - horseBlack : Things that are horses or black
     - horse : Things that are horses

Of course you are free to define such a semantics. But you should know 
that this definition IMHO is *very* error prone and will lead to severe 
misunderstandings and problems in the future.

... Hm, and looking up the  SPEC again:
http://www.w3.org/TR/2008/WD-skos-reference-20080829/skos.html#broaderTransitive
claims that skos:broaderTransitive should be transitive (which means 
that all subproperties are also transitive). Thus N1 holds, and the 
visualization plus the explanation in #L4160 is inconsistent with the 
schema.

?


yours
Johannes
-- 
Dr. Johannes Busse, Senior Researcher
An der RaumFabrik 29, D-76227 Karlsruhe
Reg. Office: Karlsruhe, Amtsger. Mannheim, HRB 109540
Managing Directors:    Prof.Dr.J.Angele,  H.P.Schnurr
http://www.ontoprise.de   | phone x49(721) 509 809-62
mailto:busse@ontoprise.de | mobile x49(163) 509 80-62

Received on Friday, 13 February 2009 15:09:04 UTC