RE: comment: WD 10 May 2005

Hi John,

*If* you can specify your your scheme/model/whatever with owl alone,
you can of course go for that and benefit from existing reasoners.
If all you need are relations which can be mapped to rdfs or owl
axioms, you probably don't need SKOS at all. SKOS is created due
to practical needs which indeed serve "a wider community to whom
W3C standards are normally addressed". Very basic use cases from
e.g. the blogging world can easily demonstrate the demand for
something less restrictive than owl. There has also been quite
some discussion about how to map SKOS concepts to ontologies, so
this isn't neccessarily an "either xor" thing. I haven't looked
too closely at the newer drafts, but I'll try to address some of
your comments:


>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.
are you sure? If you plan to use classes as individuals as in your
example, you're in OWL Full space anyway, so it should theoretically
be possible to relate resources via skos:subject to rdfs:Class individuals.
Of course, this may have some unwanted semantic consequences such as the
class "becoming" a skos:Concept etc.


>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.
Concepts are not neccessarily classes, they *may* have characteristics
of classes but they may also be individuals. The notion of a concept is
needed to "unify" the things which are meant to be organised. Using
classes would feel strange in many cases, e.g.:
[[
   <#rdfToolkit> skos:narrowerInstantive <#redland> .
   <#redland> skos:narrower <#raptor> .
   <#raptor> skos:narrower <#raptorFeature> .
]]
The first triple could be replaced with simple RDF:
[[
   <#rdfToolkit> rdf:type rdfs:Class .
   <#redland> rdf:type <#rdfToolkit> .
]]
<#raptorFeature> could also be represented as a class,
but for the rest, rdfs and owl don't seem appropriate.


>Second, change the superclass of skos:Concept to owl:Class, allowing
>categorical entries to be referenced as a subject of a text unit.
similar comment to the one above, changing the superclass will turn
every concept into a class which may not be desired in many cases.
I'd even argue that a class should rather be a subclass of skos:Concept
than the other way round.


>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 .
NT/BT is only a subset of skos relations. there's also skos:related which
can't easily be mapped to owl terms, and there are also extended skos
properties such as narrowerInstantive etc. As had been said before, some
parts of SKOS could be aligned with ontology axioms, but the general
purpose is, well, broader ;)

>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.
Well, skos concepts *are* already individuals. They are all individuals of
the same type: "skos:Concept". That's why it becomes possible to relate any
of them using the skos vocabulary without causing any reasoning problems at
all. Taking the rdfs:Class approach "activates" inference in situations
where it may not be wanted. It would also be rather confusing to create
a taxonomy of classes but then not being encouraged to generate individuals,
or, even worse, to create individuals but then seeing reasoners conclude
unintended stuff. (such as <#raptor> becoming a ex:Redland, or a feature
becoming at toolkit etc.) Using individuals as classes is another can
of worms for people who would like to use RDF without the need to study
OWL too intensively.


>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:
I personally am considering skos:Concepts as being quite unrestricted.
It should be fine to use concepts for category entries, topics, or
whatever thing might appear in a collection of things someone is trying
to organise. Once SKOS hits the blogosphere or the wider web developer
audience, there won't be much interest in the subtle differences anyway.
But that's also SKOS' main advantage, it shouldn't break even when used
by non-expert knowledge-modelers.

SKOS can have a great effect on the large-scale deployment of RDF.
A chance which can only be seized if the vocabulary and its use are
easy to grok. Stepping too far into OWL-land will surely interfere
with that goal.


hth a little bit,
benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.bnode.org/

Received on Friday, 22 July 2005 09:09:27 UTC