- From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
- Date: Mon, 11 Aug 2008 14:06:33 +0200
- To: public-swd-wg@w3.org
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