- From: Benjamin Nowack <bnowack@appmosphere.com>
- Date: Fri, 22 Jul 2005 11:08:17 +0200
- To: "John McClure" <jmcclure@hypergrove.com>
- Cc: public-esw-thes@w3.org
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