RE: comment: WD 10 May 2005

John

Just a technical point, which might make your re-consider your argumentation

> 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 maybe right if you stick to OWL-DL, but is plainly wrong in RDF/OWL-Full, where
"Everything is a Thing" ... including your rdfs:Class which can be considered as an
individual if you wish, for example the following are consistent in OWL-Full

(1) 	a:Widget    	rdf:type		rdfs:Class

(2) 	a:Widget		skos:inScheme	a:MyScheme

(3)	a:Mydoc		skos:subject	a:Widget

(4)	a:MyWidget		rdf:type		a:Widget

Of course, this looks a bit confusing to begin with, since a:Widget is considered as a
Class in (1), and implicitly as an (Individual) skos:Concept in (2). But that's OK in
OWL-Full. Actually, (1) and (2) provide two orthogonal perspectives on the same resource,
which can therefore be used either in a SKOS framework to assert document-subject
relationships, like (3), or in a OWL framework, to assert class-instance relationships,
like (4). Everybody can live happily ever after with that, providing you know what kind of
framework or application you use those assertions in. Smart engines should even be able to
make sense of aggregate both kinds of information (indexed resources and instances) and
answer together or separately to user's queries like :

"Where can I find widgets?" and "Where can I find documentation about widgets?"

Of course one can be uneasy with such conflating definitions, and split the concept into
two resources, one rdfs:Class and one skos:Concept, in two different frameworks/namespaces

(1) 	a:Widget    	rdf:type		rdfs:Class

(2) 	b:Widget		skos:inScheme	b:MyScheme

(3)	b:Mydoc		skos:subject	b:Widget

(4)	a:MyWidget		rdf:type		a:Widget

In this case one is left with the tricky issue, discussed here a month ago, of the kind of
relationships you can assert between a:Widget and b:Widget. Followingr this discussion
I've been introducing the notion of "hubjects".
See http://www.mondeca.com/lab/bernard/hubjects.pdf

In any case, thanks to flexibility of RDF, SKOS is more open that you might think to begin
with. And there again, it's important to keep skos:Concept NOT disjoint with any class
defined by other vocabularies like RDFS or OWL, to keep this flexibility.

The bottom line of this, as I tried to express in the above quoted resource, is that we
should not attempt to provide universal definitions of those very generic notions of
"thing" "subject" "concept" "resource" "topic", ... nor try to come to an agreement on
what they "mean" really. Every other specification defines their own meaning, its specific
internal logic, and that's OK and we have to live with that. What we need is "hubs" to
connect different views and frameworks, not a meta-meta-model that would define once for
all and forever these generic notions.

Regards

Bernard

----------------------------------
Bernard Vatant
Mondeca Knowledge Engineering
bernard.vatant@mondeca.com
(+33) 0871 488 459

http://www.mondeca.com
http://universimmedia.blogspot.com
----------------------------------

> -----Message d'origine-----
> De : public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]De la part de John McClure
> Envoyé : vendredi 22 juillet 2005 04:55
> À : public-esw-thes@w3.org
> Objet : 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 08:06:32 UTC