SKOS Reference Review Response

Dear Margherita

SKOS Simple Knowledge Organisation Systems Reference Draft 30 July 2008

Thank you for your review of the above document. We have made a number
of changes which we believe address the comments that you have
raised. A revised version of the document is available at:

http://www.w3.org/2006/07/SWD/SKOS/reference/20080820/

Below, please find in-line responses to your review comments
identifying either changes made, explanations or rationale for making
no change. Can you please confirm that you are now in agreement that
this document is ready for Last Call?

      Sean & Alistair

------------------------------------------------------------------


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

Amended as: "...The important point for SKOS is that, in addition to  
their unique features, each of these families shares much in common,  
and can often be used in similar ways. However, there is currently no  
widely deployed standard for representing these knowledge  
organization systems as data and exchanging them between computer  
systems." AJM

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

Inserted "...machine readable data...". SKB

 > 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?

Amended as: "SKOS concepts can be assigned one or more  
<strong>notations</strong>,
which are lexical codes used to uniquely identify the concept within the
scope of a given concept scheme. While URIs are the preferred means of
identifying SKOS concepts within computer systems, notations provide a
bridge to other systems of identification already in use such as
classification codes used in library catalogues." AJM

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

This is a new requirement and we don't think this can be addressed in  
the current draft. AJM

 > 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"?

by the logical characteristics of, and interdependencies between,  
those classes and properties. SKB

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

This paragraph has been removed in response to a comment from Guus. AJM

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

This paragraph has been removed in response to a comment from Guus. AJM

 > 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?

No. skos:Concept is an owl:Class. The particular instances of  
skos:Concept, e.g.
ex:Cat or ex:Dog are individuals (with rdf:type skos:Concept). SKB

 > 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???

The example illustrates that owl:Classes and skos:Concepts may be  
mixed arbitrarily. There is nothing in the
SKOS Recommendation to prevent this.

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

Ideally, users should be aware of the distinction, as different  
inferences may arise, depending on whether skos:Concepts or  
owl:Classes are defined. If applications are to respect the  
underlying semantics of the languages (OWL and RDF), then they would  
need to make the distinction. It may be that we can make this  
clearer. SKB

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

"then" removed. SKB

 > 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"?

The integrity conditions are given in the appropriate context. The  
word "next" is unnecessary here and possibly confusing, so it has  
been removed. SKB

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

No response needed. AJM

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

You are right in your thinking. skos:Concept is an owl:Class. This is  
exactly what the
text says. Recall that owl:Class is a "meta-class", in that instances  
of owl:Class
are classes. SKB

 > 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?

The statement here is intended to highlight the fact that there is no  
expectation
or requirement for a particular skos:Concept to be interpreted as an  
owl:Class or to have
an associated owl:Class. This has been made clearer through the  
following text

Other than the assertion that <code>skos:Concept</code> is an  
instance of <code>owl:Class</code>,
this specification does <strong>not</strong> make any additional  
statement about the
formal relationship between the class of SKOS concepts and the class  
of OWL
classes. SKB

 > 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>>>?

See above. AJM.

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

skos:Concept is the class of SKOS concepts, thus is defined as an  
instance of
owl:Class. Sections 1.2 and 1.3 are intended to explain this. SKB

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

skos:topConceptInScheme was introduced in order to address ISSUE 83  
and to
allow the statement of the relationship between skos:inScheme and  
skos:hasTopConcept
(without resorting to the use of an anonymous property which is known  
to be
problematic). There is no need to assert skos:topConceptInScheme for  
any concept
that is the subject of a skos:hasTopConcept assertion. The fact that  
the two properties
are inverses will allow such an inference to be made. SKB

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

This is, in principle, already possible using SKOS XL, because an  
instance of xl:Label can have a skos:inScheme property. However a  
discussion of design patterns such as this is beyond the scope of the  
SKOS Reference, and probably needs further exploration within the  
community of practice. AJM

 > 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">)?

There are a number of possible design patterns here, however a  
discussion of these design patterns is beyond the scope of the SKOS  
Reference, and probably needs further exploration within the  
community of practice. AJM

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

There are a number of possible design patterns for working with  
multiple concept schemes in SKOS, and these need further  
investigation. Many of these design patterns remain to be explored or  
well documented, therefore we feel a discussion of these issues is  
beyond the scope of the SKOS Reference (but would make a great  
subject for a follow-up note). AJM

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

The example is intended to highlight precisely the fact that the  
constraint that you
mention (top concept cannot have BT) is 'not' explicitly represented in
the SKOS data model and thus there is no inconsistency in the  
example. SKB

We felt it was adequate to handle this situation by a usage  
convention, which applications can check if they need to, rather than  
add a formal constraint in the data model. AJM

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" ?

This issue is out of scope for the current draft. AJM

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.

No action. SKB

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

The WG formally resolved ISSUE-82 by adding editorial changes to the  
documents highlighting the intended interpretation of broader and  
narrower. Hence the SKOS Reference now contains passages such as "The  
properties skos:broader and skos:narrower are used to assert a direct  
hierarchical link between two SKOS concepts. A triple <A>  
skos:broader <B> asserts that <B>, the object of the triple, is a  
broader concept than <A>, the subject of the triple. Similarly, a  
triple <C> skos:narrower <D> asserts that <D>, the object of the  
triple, is a narrower concept than <C>, the subject of the triple." AJM

 > 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?

The assertion is not needed due to the fact that skos:related is  
symmetrical.
Added an explanatory noteSKB

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

We feel this is out of scope for the SKOS Reference, but may be  
appropriate in the SKOS Primer. AJM

 >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?

Note that reflexivity and symmetry are two different qualities.  
Section 8.6.7 is about the reflexivity of skos:broader, and does not  
discuss symmetry. The WG formally resolved ISSUE-69 such that  
skos:broader should be not normatively irreflexive, to leave open the  
exploration of various design patterns for working with SKOS and OWL  
in combination. AJM


 > Section: 9. ok

 > Section: 10.

 > yes i wish actually to chain  skos:exactMatch... it may be useful.

Is this an explicit request for property chain axioms relating to the
mapping properties? No action taken. SKB

The WG formally resolved ISSUE-75 such that no property chain axioms  
shall be stated in the SKOS data model involving skos:exactMatch,  
because this is an area for further research. This does not prevent  
applications asserting their own property chain axioms and drawing  
their own conclusions. AJM

 > 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" ?

Examples changed. SKB


--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@manchester.ac.uk
http://www.cs.manchester.ac.uk/people/bechhofer

Received on Friday, 22 August 2008 09:01:06 UTC