RE: comment: WD 10 May 2005

(Long reply)

Folks,
I agree and understand your goals, and I'm hopeful that you're taking my
comments as constructive towards a standard that serves the needs of not only
its immediate community but also a wider community to whom W3C standards are
normally addressed. Anyway, it's easy to see that lots of good thought has
already gone into the first WD.

Regards,
John McClure

1. My "Use Case" was apparently not said well, judging by Mark's reaction. By
way of analogy, the Best Practices paper "Simple Part-Whole Relations in OWL
Ontologies" correctly notes that three of its four design patterns are
disadvantageous in that they duplicate portions of one's ontology. I am trying
to communicate that the current SKOS implementation also implies similar
duplication.

The problem begins with skos:subject whose range is a skos:Concept. From what
I've learned, a skos:Concept when instantiated is an owl:Thing. This means
skos:subject cannot reference an rdfs:Class. This means that regardless of how
comprehensive an ontology bound to a document is, none of its classes can be
referenced as indicative of the subject of a text unit. I am uncomfortable with
this outcome because my definition of a "subject" is definitely made with
reference to a set of generic instances, or to a set of specific instances, or
to a specific instance; rdfs:Class objects are certainly representative of a set
of generic instances, which seem to be the most frequent type of 'subject' bound
to a text unit. In short, the definition of skos:subject prevents me from
adopting SKOS, feedback that is important for the group to hear because of your
interoperability goals.

My suggested 'fix' is three-fold. First, change the range of skos:subject to
rdfs:Class, allowing ontology entries to be referenced as a subject of a text
unit, and change the domain for skos:isSubjectOf to rdfs:Class, allowing
resources cataloged by an ontology class to be listed within that class. Second,
change the superclass of skos:Concept to owl:Class, allowing categorical entries
to be referenced as a subject of a text unit. Third, sharpen the definition of a
skos:Concept to emphasize its specific relevance to document authors rather than
ontology authors.

2. Several responded that representing a concept scheme using rdfs:subClassOf is
inappropriate. Frankly this confuses me, because I am unable to detect any
difference whatsoever between NT/BT and subclass/superclass relations.
Incidentally, I didn't suggest eliminating skos:broader in favor of
rdfs:subClassOf, but rather to indicate (in OWL) that the two are equivalent or
at least that skos:broader is a sub-property of rdfs:subClassOf .

But more to the point is that, if Concept is a subclass of owl:Class, it
inherits the properties of owl:Class. I am suggesting several actions in this
regard. First, evaluate whether Concept's naming-related properties are better
associated with owl:Class -- heaven knows more is better when the options
available today are rdfs:label and dc:title. Second, consider the use of the
owl:unionOf property to indicate narrower concepts. Third, identify the semantic
(if any) for a concept defined within a concept (as classes can be defined
within classes). Fourth, determine if owl:Restriction (or a subclass) is useful
for documenting what type of resource (text unit) may be subject-indexed by a
concept. Fifth, examine what semantics are suggested by an intersection of
concepts.

Specifically, I very strongly suspect that the most efficient and correct
representation of narrower concepts is owl:unionOf, because this would provide
direct support to concept schemes (topic maps) that reference ontology classes
(and it would be consistent with said concern about concept schemes 'properly'
setting up subclass relations). If 'unionOf' is too technical, I suggest to
subproperty it (or better, equivalence it) with a name more communicative to
SKOS stakeholders.

A Simple Concept
================
<Concept rdf:ID='Level1Concept'>
   <owl:unionOf rdf:parseType='Collection'>
      <owl:Class rdf:about='anOntologyClass'/>
      <Concept rdf:ID='Level2Concept'/>
   </owl:unionOf>
</Concept>

Now, this approach also relates to SKOS collection-related classes and
properties.

A Concept with Collections
========================
<Concept rdf:ID='Level1Concept'>
   <rdfs:subClassOf rdf:parseType='Collection'>
      <owl:Class>
         <rdfs:label>Collection 1</rdfs:label>
         <owl:unionOf rdf:parseType='Collection'>
             <owl:Class rdf:about='anOntologyClass1'/>
             <Concept rdf:ID='Level2AConcept'/>
         </owl:unionOf>
      </owl:Class>
      <owl:Class>
         <rdfs:label>Collection 2</rdfs:label>
         <owl:unionOf rdf:parseType='OrderedCollection'>
            <owl:Class rdf:about='anOntologyClass2'/>
            <Concept rdf:ID='Level2BConcept'/>
         </owl:unionOf>
      </owl:Class>
   </rdfs:subClassOf>
</Concept>

Some believe that establishing a relationship between skos:Concept and owl:Class
(or equivalently, between skos:broader and rdfs:subClassOf) is believed
inappropriate due to concern that certain concept schemes aren't "proper"
ontologies. I say this: because no instance of a Concept may ever be
instantiated, then there is no impact from publishing a 'poor' ontology. Can
anyone identify any impact? It's the job of a SKOS-aware Reasoner to ensure that
no Concept instances are ever instantiated. The significant benefits
(semantically and functionally) had by making a Concept a metaclass outweigh the
cost of Reasoners tripping an error if any resource ever has an <rdf:type
rdf:resource='someConcept'/> element.

3. There appears to be some consensus that overlap exists between a Concept and
a Topic. My suggestion is to stop beating around the bush, talk it through with
the TMI crew, and come to a resolution about the proper definitions and roles of
each. In this vein, let me remark that what noone needs is another standard that
is "agnostic about what its base class represents".... when standards are meant
to be interoperable.... for this reason I am quite opposed to a Concept defined
as an "abstract idea or notion; a unit of thought" [SKOS Core Vocabulary] or as
one that is consciously "not strict" or "informal" .... this contradicts the
notion of what a standard is all about, to me.

Personally I'm quite comfortable with a TopicMap being the equivalent of a
ConceptScheme, and with a Concept being the equivalent of a Topic. I imagine
there are a few Topic Map related properties that need to be added, but you all
know far better than I do about this.

4. Subject indexing raised a question.

>Because the skos:Concepts shouldn't be interpreted as being classes I
>think the rdf:type is not how a skos:Concept should be used in
>indexing a document. BTW if it were, then how would we distinguish
>between instances of a class/skos:Concept Person in the "normal sense"
>(i.e. instances of real people) and documents that have an rdf:type
>relation to this same class/skos:Concept Person?

Right, using rdf:type rather than skos:subject is downright wrong. It came from
my previous misconceptualization that a concept,  as a subclass of owl:Class,
could thus have concrete instances. Now I see that a concept *never ever* has
any instances, a rule that must be enforced by a SKOS-aware Reasoner.

5. Miscellaneous

I received a negative vote that a concept is not a category; an explanation
would have been useful to me. My position relies on the WordNet definition for a
category, the relationship of a 'category' to 'class' or 'topic' or 'concept' to
plurals v singular nouns, and so on.... Note the dc:title of one of the SKOS
examples, hehe:

<skos:ConceptScheme rdf:about="http://my.example.org/theGCL/version2.1">
  <dc:title xml:lang="en">Government Category List Version 2.1</dc:title>
   ...
</skos:ConceptScheme>

I am also a bit mystified -- sorry, even after 20 minutes with the OASIS
document -- what precisely is meant by a subject indicator..... and the SKOS
example is poor.... I suspect though that its function can be handled by an
owl:Restriction as described above (my understanding of a subject indicator is
that it marks those concepts that *may* be used as subjects, that is, concepts
meant to be categorical would not have a subject indicator -- now, I suggest
instead to identify those concepts that may NOT be subjects of a given type of
document resource or text unit, where categorical concepts would specify that no
document resource of any type may have the categorical concept as a subject).

Mark asked about modifying the SKOS Guide to make it clearer for non-SMEs like
me. What would be helpful would be a garden-variety data model that shows the
relationships between the key terms that remain after consultations with the TMI
team. FWIW the directed graphs, though interesting, are not as communicative to
me. Last, more RDF examples and complete examples!

Can dc:title be mapped to one of the SKOS labels?

One last thought. My own ontology defines a metaclass called "Noun" which has a
property 'hasPlural'.... as part of a design pattern disambiguating a Predicate
into a PredicateVerb and PredicateNoun (that is, a DirectObject).... my
intention is to make that property equivalent to one of your label properties.

Received on Friday, 22 July 2005 02:54:25 UTC