RE: SKOS Reference Review Response

Dear Sean and Alistar,
 
Thanks for this. I will leave in half and hour to go Hyderabad south-India,
where I will have a less reliable internet connection. I have saved the email
and the web page on my laptop so i can work on it hopefully tonight.
I will send you a reply hopefully tomorrow or in 2 days maximum.

Thanks
Margherita
 

 -----Original Message----- 
 From: Sean Bechhofer [mailto:sean.bechhofer@manchester.ac.uk] 
 Sent: Fri 8/22/2008 11:00 
 To: Sini, Margherita (KCEW) 
 Cc: SWD Working SWD 
 Subject: 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 Monday, 25 August 2008 07:58:08 UTC