Revision of: SKOS Simple Knowledge Organization System - Reference - W3C Working Draft 9 June 2008

Hi there,

I remember I volunteered to revise the SKOS Simple Knowledge Organization
System - Reference - W3C Working Draft 9 June 2008.

Here below some comments.

Section: 1.1. Background and Motivation

I saw that you still need a ref for AGROVOC. I suggest to put:
[@@REF-AGROVOC] == http://www.fao.org/agrovoc

In the background and motivation, i would suggest to add a sentence that
mention that today no real unified or standardized way for representing
thesaurus exists: there are ISO standards to structure thesauri (with
specific well defined relationships), but no technical way of representing
those... Some are just in word files, some printed in hard copies, some in
any custom defined ms access forms... So This is one reason more why we need
SKOS.

Section: 1.2. What is SKOS?

Here it is mentioned:
<<<<These SKOS concept schemes and SKOS concepts are identified by URIs,
enabling anyone to refer to them unambiguously from any context, ...>>>>>
This sentence is very important as there is a very important distinction
between thesaurus (or other KOS) elements (somethimes called keywords or
terms) and concepts (which may be lexicalized with multiple keywords or
terms)... I think we need to make a little introduction making this
distincion clear. So basically multiple elements (somethimes called keywords
or terms) can then be linked to the same SKOS concept.

also 
<<<<One of these labels in any given language can be indicated as the
"preferred" label for that language, and the others as "alternate"
labels.>>>>


<<<<KOS concepts can be assigned one or more notations, which are lexical
codes used to uniquely identify the concept within the scope of a given
concept scheme (also known as classification codes). See Section 6. Notations
for more on notations.>>>>

I also propose for other future releases of SKOS that the WG could take in
consideration the notion of context of validity of concepts or relationships,
maybe later on adding the notion of "extent" or "validity"... E.g. a concept
or term (label) may be valid only in a specific geographical area or at a
given time, and a relationship may be valid for a specific culture only. ( I
can provide examples if needed, but as i said ... this may be for other
releases... if the group think is good to adapt this).

Section: 1.4. SKOS, RDF and OWL

I think there is a mistake here: <<<by the logical characteristics of and
interdependencies between those classes and properties>>>

In second paragraph you say <<<These structures, however, do not have any
formal semantics, and cannot be reliably interpreted as either formal axioms
or facts a>>> but then you say in the next paragraph <<<In other words, some
person has to do the work of transforming the structure and intellectual
content of a thesaurus or classification scheme into a set of formal axioms
and facts. >>> I suggest you change the second sentence into something like
"transforming the structure and intellectual content of a thesaurus or
classification scheme into a set of well defined concepts, labels, and
properties."

Next paragraph: instead of saying <<<<using the "concepts" of the thesaurus
as a starting point for creating classes, properties and individuals >>>> I
would say "using the "elements" of the thesaurus as a starting point for
creating classes, properties and individuals "  or "using the "main
descriptors" of the thesaurus as a starting point for creating classes and
individuals, the non-descriptors for labels and relationships for properties
"

In the sentence <<<The reason for this is that, because a thesaurus or
classification scheme has not been developed with formal semantics in mind,
but rather as an informal or semi-formal aid to navigation and information
retrieval, expressing a thesaurus hierarchy directly as a set of ontology
classes with subsumption axioms typically leads to a number of inappropriate
or nonsensical conclusions.>>> maybe you can even add an example in which
sometimes in a thesaurus we may have non-descriptors with refer to a maybe
more generic descriptor... The 2 are related by the USE/UsedFor relationships
but may not necessarily synonyms... so sometimes USE/UsedFor can be converted
into an alternative label for a concept, sometimes they can be converted in
actually 2 different concepts.

In the next paragraph: <<<Taking this approach, the "concepts" of a thesaurus
or classification scheme are modeled as individuals in the SKOS data model>>>
this means that skos:Concept  is in OWL an individual?

In last paragraphs of Section: 1.4, you are basically saying that
representing a thesaurus in SKOS+OWL i may have some thesaurus elements
("concepts") as owl:class and some others as skos:concepts???

Section: 2. ok

Section: 3.5.1. SKOS Concepts, OWL Classes and OWL Properties

It is not clear to me why here you say <<<This specification does not make
any statement about the formal relationship between the class of SKOS
concepts and the class of OWL classes. The decision not to make any such
statement has been made to allow applications the freedom to explore
different design patterns for working with SKOS in combination with OWL.>>>
but in section 3.3. Class & Property Definitions  you say <<<<skos:Concept is
an instance of owl:Class>>>>. Is not a contracdition?
So i do not see why in the section "Class & Property Definitions" you define
something, but then you leave 

Section: 4. ok

Section: 5.1. Preamble

Sentence <<<In particular, SKOS enables a distinction to be made between the
"preferred", "alternate" and "hidden" lexical labels for any given
resource.>>> i suggest to write instead "...for any given concept".  actually
now in section 5.6.1. i see why you have chosen "resource". Ok its fine to me
now.

Section: 6. ok

Section: 7. ok

Section: 8.1. Preamble

What about the proposal to change skos:broader  into skos:hasBroader? makes
much more clear the use of the rt...

Example 39 (consistent): are we really sure we do not want to set
skos:broader as anti-simmetric? in most of the cases when we use skos:broader
one concept is more generic than the other... so skos:broader is actually
used as non simmetric... do we have use cases for which should be not like
this?

Section: 9. ok

Section: 10. 

Example 64: Yes, i bdlieve is better to make skos:exactMatch as disjoint with
skos:broadMatch and disjoint with skos:relatedMatch. 
Example 68: yes i wish actually to chain  skos:exactMatch... it may be
useful.

Appendix A  ok

Appendix B and C  ok

Hope this helps
Margherita

Received on Sunday, 27 July 2008 12:03:10 UTC