REVISION SKOS Simple Knowledge Organization System Reference

REVISION SKOS Simple Knowledge Organization System Reference
Editors' Draft 30 July 2008

Hi there, here below my revision (partially reused previous comments).

Abstract: OK

Status of This Document: OK

Changes: OK

1.1. Background and Motivation: 

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 other reason why we need
SKOS (if not alreaqdy covered by last 2 paragraphs).

1.2. What is SKOS?

I would suggest to change <<<Using SKOS, a knowledge organization system can
be expressed as data.>>> with "... as formalized data." or "... as
computer-processable data."

In the sentence <<<SKOS 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).>>> ... can we
mention something that identify that these "codes" (even if i would prefer to
call them differently... such as "specific alphanumeric or numeric values, or
symbols") are or may be  different from codes used to create/generate the
URI? why do we need to "uniquely identify the concept within the scope of a
given concept scheme"... is the URI not enough?

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).

1.3. SKOS, RDF and OWL: 

I think there is an editorial mistake here: <<<by the logical characteristics
of and interdependencies between those classes and properties>>>. Is it a
mistake "of and"?

Suggestion: 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 example, 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???

Last sentence <<<need to appreciate the distinction>>> means that users do
need to do the distinction or it is not mandatory to make the distinction
(between skos:Concept and owl:Class)?

1.4. Consistency and Integrity: OK

1.5. Inference, Dependency and the Open-World Assumption

Sentence <<<and for the possibility of then using thesauri>>> should maybe be
"and for the possibility of using thesauri" (editorial mistake)?

1.6. How to Read this Document

I am not a native english speaker so some of my comments may be not
appropriate... E.g. sentence <<<Integrity Conditions — if there are any
integrity conditions, those are given next.>>>  is "next" here to be
interpreted as "in this section"?

1.7. Conformance: OK

Section: 2. 

My comment about the URI would be that i suggest to keep alive and resolvable
the old URI for legacy system, but the new URi should be also published so
that new systems may show the new changes. It will be up to the user to
decide if they want to move to the new uri or not.

3.3. Class & Property Definitions

<<<skos:Concept is an instance of owl:Class>>>.   Means that skos:Concept its
an Individual in OWL? I was actually thinking that skos:Concept is an
owl:Class... 

3.5.1. SKOS Concepts, OWL Classes and OWL Properties 
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>>> But in section 3.3. Class & Property Definitions you just said
"skos:Concept is an instance of owl:Class"... so how could you not make
statement about their relationship if you say one is an instance of the
other.... It is not a contracdition?

From the examples and the text i understood that you do not want to specify
if skos:Concept is a class or an individual or any other element (e.g.
ObjectProperty)... But then why have you said that <<<skos:Concept is an
instance of owl:Class>>>?

Personally I can see that from a KOS we may have skos:Concept as owl:Class
(e.g. "cows" its a class). Or we may have instances (e.g. "Batissa violacea",
its a specific species of a mollusc).

4.2. Vocabulary

Why the <<skos:topConceptInScheme>> has been introduced? the
"skos:hasTopConcept" is enough to be able to represent in any system the top
level elements of a scheme... Do we really have to use
<<skos:topConceptInScheme>>? If i generate my skos file this new statement
will make my file bigger without introducing really a new information. In
fact I can infere this from the "skos:hasTopConcept"... 

4.6.1. Closed vs. Open Systems

I may have a problem with this <<<<MyConcept> takes part in two different
concept schemes>>>... in fact this its true.... BUT.... if we go to the
labels level... we may have to keep in kind that the same concept may be
lexicalized differently in different schemes... How this will be represented
in SKOS? there is no way yet (maybe?) to express that the labels attached to
an skos:Concept may be from different schemes.... And what about the URI of
the skos:Concept? will it be the one from one scheme (e.g. <skos:Concept
rdf:about="http://www.fao.org/aims/aos/agrovoc#c_1939">) or from the other
scheme (e.g. <skos:Concept
rdf:about="http://agclass.nal.usda.gov/nalt#cows">)?

<<<This flexibility is desirable because it allows, for example, new concept
schemes to be described by linking two or more existing concept schemes
together.>>> but if it is so.... why there are the mapping elements
exactMatch, narrowMatch, etc... which can be used to link two or more
existing concept schemes? This second solution infact, would resolve the
problem of keeping the 2 distinc URi, be able to lexicalized differently
concepts, but expressing that a concept may take part on 2 different schemes.

4.6.4. Top Concepts and Semantic Relations

How the example is consistent? as we are probably sure that
skos:hasTopConcept will be used for top concept which do not have any BT...
should we instead enforce this to be correct in SKOS? i mean enforce that a
top Concept cannot have BT....

5. Lexical Labels

I am still convinced that in future version of SKOS we do not need "A
resource has no more than one value of skos:prefLabel per language."
anymore.... because one day all indexing will be done using URIs... so we do
not need distinction between preferred and non preferred... we may represent
a concept with simply more labels per language.... E.g. which one is
preferred between "canotto"@IT and "gommone"@IT ? why we should prefer an
acronym to a full form or viceversa? why we force people to disambiguate into
a term for real synonyms such as "Argentina (fish)" and "Argentina" ?

6.5.3. Unique Notations in Concept Schemes

<<<By convention, no two concepts in the same concept scheme are given the
same notation. If they were, it would not be possible to use the notation to
uniquely refer to a concept (i.e. the notation would become ambiguous).>>>
I think that what should be really unique is the URI. This sentence is ok as
it only "By convention" notation unique.

6.5.4. Notations and Preferred Labels

Section 7: ok

Section: 8.1. Preamble

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

8.4. Integrity Conditions

<<<skos:related is disjoint with the property skos:broaderTransitive.>>>
Why it is not specified skos:related is disjoint with the property
skos:narrowerTransitive? 

I remember that skos:broader and skos:broaderTransitive were of very
difficult comprehension by some users especially for the hierarchical
relationships between them (myself I was thinking as should be
skos:broaderTransitive subclass of skos:broader instead of the opposite). In
order to make this more comprehensible, would it be possible to add an
examples such as "skos:broaderTransitive" may be the "ancestor" relationship.
This is transitive. A chidren relationships may be the "father" and also
"adoptive father". "adoptive father" is not transitive... This is a good
examples explaining the same situation as in SKOS. (maybe help?)

8.6.7. Reflexivity of skos:broader

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. 
yes i wish actually to chain  skos:exactMatch... it may be useful.

Appendix A  ok

Appendix B and C  ok


 
Another general comment would be: would not be better to have more meaningful
examples instead of "foo" and "bar" ?

Hope this helps
Margherita

Received on Monday, 11 August 2008 12:07:17 UTC