W3C home > Mailing lists > Public > public-swd-wg@w3.org > August 2008

RE: SKOS Reference Review Response

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Mon, 25 Aug 2008 09:57:20 +0200
To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
Cc: SWD Working SWD <public-swd-wg@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DB3C9@hqgiex01.fao.org>

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.


	-----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
	Thank you for your review of the above document. We have made a
	of changes which we believe address the comments that you have
	raised. A revised version of the document is available at:
	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
	thesaurus exists: there are ISO standards to structure thesauri (with
	specific well defined relationships), but no technical way of 
	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
	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
	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 
	which are lexical codes used to uniquely identify the concept within
	scope of a given concept scheme. While URIs are the preferred means
	identifying SKOS concepts within computer systems, notations provide
	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 
	maybe later on adding the notion of "extent" or "validity"... E.g. a 
	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
	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 
	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 
	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.
	 > In the sentence <<<The reason for this is that, because a 
	thesaurus or
	classification scheme has not been developed with formal semantics in
	but rather as an informal or semi-formal aid to navigation and 
	retrieval, expressing a thesaurus hierarchy directly as a set of 
	classes with subsumption axioms typically leads to a number of 
	or nonsensical conclusions.>>> maybe you can even add an example in 
	sometimes in a thesaurus we may have non-descriptors with refer to a 
	more generic descriptor... The 2 are related by the USE/UsedFor 
	but may not necessarily synonyms... so sometimes USE/UsedFor can be 
	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.
	 > In the next paragraph: <<<Taking this approach, the "concepts" of 
	a thesaurus
	or classification scheme are modeled as individuals in the SKOS data 
	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 
	(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
	appropriate... E.g. sentence <<<Integrity Conditions - if there are
	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
	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
	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
	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 
	relationship between the class of SKOS concepts and the class of OWL
	classes>>> But in section 3.3. Class & Property Definitions you just 
	"skos:Concept is an instance of owl:Class"... so how could you not
	statement about their relationship if you say one is an instance of
	other.... It is not a contracdition?
	The statement here is intended to highlight the fact that there is no
	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
	ObjectProperty)... But then why have you said that <<<skos:Concept is
	instance of owl:Class>>>?
	See above. AJM.
	 > Personally I can see that from a KOS we may have skos:Concept as 
	(e.g. "cows" its a class). Or we may have instances (e.g. "Batissa 
	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 
	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 
	(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 
	concept schemes>>>... in fact this its true.... BUT.... if we go to
	labels level... we may have to keep in kind that the same concept may
	lexicalized differently in different schemes... How this will be 
	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.
	rdf:about="http://www.fao.org/aims/aos/agrovoc#c_1939">) or from the 
	scheme (e.g. <skos:Concept
	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
	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
	problem of keeping the 2 distinc URi, be able to lexicalized
	concepts, but expressing that a concept may take part on 2 different 
	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
	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
	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
	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 
	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 
	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."
	 > 8.4. Integrity Conditions
	 > <<<skos:related is disjoint with the property 
	Why it is not specified skos:related is disjoint with the property
	The assertion is not needed due to the fact that skos:related is 
	Added an explanatory noteSKB
	 > I remember that skos:broader and skos:broaderTransitive were of
	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
	examples such as "skos:broaderTransitive" may be the "ancestor" 
	This is transitive. A chidren relationships may be the "father" and
	"adoptive father". "adoptive father" is not transitive... This is a
	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 
	one concept is more generic than the other... so skos:broader is 
	used as non simmetric... do we have use cases for which should be not
	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
	examples instead of "foo" and "bar" ?
	Examples changed. SKB
	Sean Bechhofer
	School of Computer Science
	University of Manchester
Received on Monday, 25 August 2008 07:58:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:54 UTC