- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Mon, 28 Jan 2008 23:20:58 +0100
- To: "Reul, Q. H." <q.reul@abdn.ac.uk>
- CC: public-swd-wg@w3.org
Dear Quentin, > Dear Antoine, > > I can find below my answer to most of your comments that I needed to > reply to. Let me know if you have anymore questions. > Please find below some changes that will occur in the next version. I don't have any more questions! > Cheers, > > Quentin > > - Although it is mentioned in the Primer [1] is that it a companion to > the SKOS Reference [2], I sometimes had to go through the whole document > to find a link to the reference. Would it not be possible to make the > title of the section as a direct link to the appropriate section in the > Reference? Obviously, the link doesn't need to be explicitly stated > throughout the document. You could revise the introduction to make it > clear: > [[ > This document is a companion to the SKOS Reference, which gives the > normative reference on SKOS. The reader is able to consult the SKOS > Reference [SKOS-REFERENCE] by clicking on the property (e.g. > skos:Concept). > ]] > The intro will include: [[ For an in-depth account on all SKOS vocabulary elements, including their reference formal semantics, the reader should consult the normative SKOS Reference [SKOS-REFERENCE]. This can be done, at the level of classes and properties, by clicking on their occurrences in the text (e.g. skos:Concept). For an overview of the use cases for SKOS and the elicited requirements that guided its design, the reader should consult [SKOS-UCR]. ]] And I'll put some hyperlinks from entities to the Reference, e.g. http://www.w3.org/2006/07/SWD/SKOS/reference#Concept But not for all their occurrences, as it would make the text really horrible. Only the first occurrence, as a rule of thumb, was hyperlinked. > - The examples in the Primer [1] are similar to the example found in the > original SKOS Core document [3]. Would it not be possible to re-use > those examples to save you the time to have to create them? > That was planned, but because of ISSUE-41 (http://www.w3.org/2006/07/SWD/track/issues/41) they have to be re-drawn anyway > - I just thought that a single example would have tied up the different > construct better as we could have added a link to the generated SKOS > file for the user to have a look @ it, but I totally understand your > point. > Let's raise this issue during one of the telecons... > - Sorry about the grammar/vocabulary documents, my supervisor tends to > argue a lot about these things. The only I feel strongly about is to use > "machine-readable" instead of "machine-processable", as the former is > commonly used in the field. > I will change this one (And in doubt, you're still right to raise the issue I think :-) For the other changes I've made. Glad to hear that you're happy with them! Cheers, Antoine > - Your suggestion sounds appropriate to me. > >> but I really don't like the result. Would you think it is also OK to >> > keep > >> the paragraph where it was, but to create an appropriate subsection >> > for > >> the issues of labelling semantics? >> > > - "Use of Labels Outside SKOS": I think the addition of the new > paragraph with the OWL example better show the full power of combining > SKOS with other knowledge representation. > > - Semantic Relationships: I totally understand that we won't be able to > stop to use skos:broader to represent part-whole relationship, but as I > said before certain type of KOS would need this difference to be made > specific. The addition of the new paragraph is useful to refer people to > the right section in the Primer [1]. > > - I agree > >> I propose to replace in this section 2.5 [[ This property allows to >> > link a > >> concept scheme to the most general concepts ]] by [[ This property >> > allows > >> to link a concept scheme to the (possibly many) most general concepts >> > ]] > > > [1] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer > [2] http://www.w3.org/2006/07/SWD/SKOS/reference/20071223 > [3] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/ > > > -----Original Message----- > From: Antoine Isaac [mailto:aisaac@few.vu.nl] > Sent: 25 January 2008 11:24 > To: Reul, Q. H. > Cc: public-swd-wg@w3.org > Subject: [SKOS] Re: Review of the SKOS Primer > > Dear Quentin, > > First: thanks for the impressive reviewing work! The length of the > review if of course a very positive point, to answer your concern ;-) > > Please find below my answers to these comments. These can be either > actions on the document or further questions... > A new draft is available at > http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer that hopefully > solves some of the issues. > > >> I found the SKOS primer [1] rather interesting and I will organise my >> review in 2 sections. On the one hand, I will give general comments >> about the document. On the other hand, I will go in more details for >> certain section. I would like to apologise for the length of the >> > review. > >> General comments >> ================ >> I think that a clear mapping between the formal semantic available in >> the SKOS reference [2] with the different classes and properties in >> > the > >> SKOS primer [1] should be made throughout the document. This could be >> achieved by having a link to the reference [2]. >> > > Do you mean, for each property and class, having a link to the > Reference? Or just mentioning it more often in the Primer? > We thought citing it in the introduction (twice, as a reference to the > reader for complete info on SKOS) would be enough. > Also, we cited it each time we felt it was explicitly needed. But it can > > of course be improved. In the latest version, there are 8 citations > throughout the document. > To make the link between the Primer and the Reference clearer, I have > added in the abstract > [[ > This document is a companion to the SKOS Reference, which gives the > normative reference on SKOS > ]] > > Also, in the introduction, > [[ > the reader should consult the SKOS Reference [SKOS-REFERENCE] > ]] > has been replaced by > [[ > the reader should consult the normative SKOS Reference [SKOS-REFERENCE] > ]] > > >> I think it would be easier if we were using a concrete example >> throughout the document rather than different example depending on the >> property or class. The document is meant to show to use the SKOS >> vocabulary and as such using a use case would allow the user to fully >> understand how to create a KOS with SKOS. Furthermore, I think that in >> some cases the use of a graph or picture would facilitate the >> understanding of the property similar to the one available in SKOS >> > Core > >> [3]. This is particularly useful for representing inverse relation >> between skos:broader and skos:narrower and to display collections. >> > > If everyone agrees, I will try to create a version with graphs. But that > > requires time, and, and, also, a decision whether the current examples > are good. > Now, to answer your first comment, apart from the section on documentary > > notes, there are 5 clearly distinct examples (animals, rocks, FAO, > TimBL, milk) 3 of them are I think unavoidable (animals, FAO, TimBL). > Of course the sitation could be enhanced in documentary notes section, > but generally I find it is difficult to find or create a single use case > > that features all the elements that are needed. > Further, I would say that to me the variety of examples is also a hint > to the fact that SKOS can be applied to different situations. Do you > really think such a stance really harms the Primer? > > >> Once the acronym KOS has been defined, I think it should be used >> throughout the document instead of "knowledge organisation systems". >> > > I've changed this, but am not convinced of the elegance of sentences > like "Representing a KOS with SKOS". The price to pay for using > abbreviations, maybe. Your comment made of course sense. > > >> Specific comments >> ================= >> Abstract: >> - I would move "meaningfully" before "on the World Wide Web". >> - I use "character string" or simply "string" rather than "lexical >> strings" in the third paragraph. >> - In the last paragraph, I would refer to "concept labels" rather than >> "labels of concepts". >> >> Introduction: >> - I would use "machine-readable" rather than "machine-processable". >> - I would combine the last sentence from the second paragraph with the >> third paragraph as they seem to be related. >> > > Here I'll be a bit blunt: I do not see the differences in many of your > above suggestions, as I am not a native. And Ed had fixed a lot of > sentences before we released the draft you've read. > Now, this is surely not a reason for us to ignore your comments. Just to > > point out that Ed had not time to review these before I send out this > mail, and I therefore would like to postpone a bit our answering them > I trust you to remind us that this point is still a @@TODO! > > >> About this Primer: >> - "publish their concept schemes in SKOS" rather than "as SKOS" as we >> are defining SKOS as a vocabulary. >> - I would use "formal semantic" rather than "reference semantic". >> > > I propose to replace "in SKOS" by "as SKOS data" and "reference > semantics" by "reference formal semantics". > > >> SKOS Essential: >> - I would modify the ordering of this section as follow: >> 2.1 Concepts >> 2.2 Labels >> 2.3 Document Notes >> 2.4 Semantic Relationships >> 2.5 Concept Schemes >> This ordering first describes the main component of SKOS and describes >> the different properties relevant to it before introducing the >> organisation (i.e. skos:ConceptSchemes). >> > > I have followed here what seemed to me the order of importance for > characterizing a concept, semantic relationships come clearly before the > > documentation (and after labelling). > I agree that this is not the order in the reference. @@TODO If people > really think my argument does not make sense I will change the order... > > >> Furthermore, it might be useful >> to introduce numbering to the different sub section (e.g. 2.1.1 >> skos:prefLabel) to facilitate access from the content list. >> > > I have done it, and this seems indeed to be a useful addition (as long > as it does not double the length of the content list ;-) > > >> Labels: - I would move the paragraph in the introduction for the >> section rather >> than in hidden labels. >> "As specified in Section 5 of the SKOS Reference, the properties >> skos:prefLabel, skos:altLabel and skos:hiddenLabel are all >> sub-properties of rdfs:label. It is important to note that they are >> pairwise disjoint. A concept cannot have a same literal both as >> preferred label and alternative one at the same time, for instance." >> > > The introducing paragraphs of section 2 now read > [[ > The first characterization of concepts are the expressions that are used > > to refer to them in natural language-their labels. SKOS provides three > properties to attach labels to conceptual resources: skos:prefLabel, > skos:altLabel and skos:hiddenLabel. Each property implies a specific > status for the label it introduces, ranging from a strong, univocal > denotation relationship, to a string to aid in lookup. These properties > are pairwise disjoint. A concept cannot have a same literal both as > preferred label and alternative one at the same time, for instance. > > As specified in Section 5 of the SKOS Reference, the properties > skos:prefLabel, skos:altLabel and skos:hiddenLabel are considered as > simple labelling means. As a result, they are all sub-properties of > rdfs:label. Also, from a syntactic perspective, all these three > properties have RDF plain literals as a range [RDF-CONCEPTS]. In other > words they link a skos:Concept to a character string, not to another > full-fledged RDF resource identified with a URI. > ]] > but I really don't like the result. Would you think it is also OK to > keep the paragraph where it was, but to create an appropriate subsection > > for the issues of labelling semantics? > > >> - In the "Use of Labels Outside SKOS", I would use a OWL example >> describing what problem would be solved by using SKOS. "Human-readable >> > > >> annotations on classes, properties and individuals in >> OWL >> ontologies are normally expressed using the rdfs:label and >> > rdfs:comment > >> properties. Consider the following triples that describe animals: >> >> ex:animal rdf:type owl:Class; >> rdfs:labels "animal"@en; >> rdfs:labels "creatures"@en. >> >> An application would have difficulties to display the right label to >> > the > >> user as they both have the same weight. SKOS labels allow the >> implementer to explicitly define the labels for a given resource." >> > > I would propose to add your idea but also to keep the the previous > example > [[ > While it is somewhat outside the scope of this Primer, it is possible to > > use SKOS labelling properties to label resources that are not of type > skos:Concept. Consider these triples that describe Tim Berners-Lee: > <http://www.w3.org/People/Berners-Lee/card#i> a foaf:Person; > foaf:name "Timothy Berners-Lee"; > foaf:nick "timbl"; > rdfs:label "Tim Berners-Lee"; > skos:prefLabel "Tim Berners-Lee"@en. > An application that wishes to display a label for this resource is able > to identify "Tim Berners-Lee" as the preferred label instead of having > to choose between the equally compatible labels rdfs:label "Tim > Berners-Lee" or the foaf:name "Timothy Berners-Lee". These labels are > compatible because foaf:name is a sub-property of rdfs:label. > > Another example are human-readable labels on classes, properties and > individuals in OWL ontologies, which are normally expressed using > rdfs:label alone. Consider the following triples that describe humans: > ex:Human rdf:type owl:Class; > rdfs:label "human"@en; > rdfs:label "man"@en. > An application would have difficulties to display the right label to the > > user as they both have the same weight. The semantics of skos:prefLabel > allow implementors to explicitly define the label for a given resource. > In general the ability to mix-in vocabulary elements from SKOS and other > > RDF vocabularies at will like this is what gives RDF much of its > expressive power. > ]] > > >> Semantic Relationships: >> - I find it confusing to use "the one between one whole and its parts" >> as part of the definition of broader and narrower. These relationships >> are used to represent hierarchies and allowing composition to be >> > similar > >> to subsumption which might be correct in some KOS but would be totally >> wrong in other cases. I think that this COULD cause problems when >> integrating different concept schemes using different aspect (see >> > ISSUES > >> 44 [4] and 56 [5]). I think I would rather have certain >> > sub-properties, > >> as proposed in [6] and [7], to be added in the SKOS vocabulary to >> > ensure > >> interoperability. >> > > This issue has and will be extensively discussed elsewhere. > For the moment I propose to add a sentence that acknowledge the problem > and points to the possible specializations of Section 4.8: > [[ > Finally, an aspect left untouched here is the way one can distinguish > the situations that hierarchical relations cover. As said in the > preamble for this section, these can range from instance-class > relationhips to part-whole ones. The interested reader is referred to > Section 4.8, which presents a way to create specializations of semantic > relations so as to deal with this issue. > ]] > I would like to insist on the fact that it is however not possible to > generally discourage the use of skos:broader to represent part-whole > relationship, as it is very common in the KOS practice to use the > generic BT link for this as well > > >> - The last paragraph of this section refers to a graph but no graph is >> present in the document. If referring to the RDF graph instead, it >> > would > >> be useful to make it explicit. >> > > I have added "RDF" as you suggest > > >> - Finally, I would agree with Margherita [8] to use skos:hasBroader >> > and > >> skos:hasNarrower to remove any confusion about the intended meaning of >> the property. >> > > I'll do the same answer as I did for Margherita. As soon as there is a > resolution on http://www.w3.org/2006/07/SWD/track/issues/82 we'll update > > the Primer accordingly! > > >> Concept Schemes: >> - As far as I know, there is no restriction on the number of top >> concepts a given concept scheme can have and I think it would be >> important to reiterate this point as part of this section. >> > > I propose to replace in this section 2.5 > [[ > This property allows to link a concept scheme to the most general > concepts > ]] > by > [[ > This property allows to link a concept scheme to the (possibly many) > most general concepts > ]] > > >> Re-using and Extending Concept Schemes: >> - "This does not however replace the skos:inScheme statements between >> the imported concepts and the importing scheme. Using owl:imports >> indicates that all statements from ex1:referenceAnimalScheme are >> imported into ex2:thePlatypusScheme, but the original information >> > source > >> did not define its concepts as belonging to the new scheme." >> I'm not sure if you mean that ex2:thePlatypusScheme is not included in >> the imported concept scheme or if you need to explicitly define >> ex2:nicePlatypus skos:inScheme ex1:referenceAnimalScheme. >> > > This is indeed not 100% clear to the reader. > I propose to add > [[ > One has therefore to assert the ex1:platypus skos:inScheme > ex2:thePlatypusScheme statement emphasized above. > ]] > > >> Subject Indexing in SKOS: >> - From a reuse perspective, I think it would better to use dc:subject >> rather than create a new property within SKOS. >> > I hope the discussion on ISSUE-48 will soon provide more insight on this > > issue. Notice that your comment is per se very valueable, and rewards > well my letting this TODO in the draft ;-) > > >> SKOS Collections and semantic relations: >> - I understand the idea behind the addition of skos:Collection to the >> vocabulary, i.e. to represent arrays, etc. However, the current >> > semantic > >> make it redundant especially when using semantic relationships as >> collections can't be used as part of the BT, NT, RT triple. >> > > I think we can do nothing with this comment, it is not really the Primer > > to solve this :-( Perhaps you can raise this as a problem in a different > > mail about collections in general. We'll of course change the Primer if > there is a problem. > > >> Relationships between Labels: >> - I might totally misunderstand the reason for this issue. I would >> > have > >> thought that the following could have solved the problem easily. >> >> ex:acronym rdfs:subPropertyOf skos:altLabel >> This would be associated to a concept and therefore easily retrievable >> by an application, >> > > I would say that if you do this, you loose the information that "FAO" is > > *the* acronym of the label "Food and Agriculture Organization". If the > link is between the concept and the label, it is just *one* acronym for > the concept. > > >> On Specializing the SKOS Model: >> - I think that this section advocates for a SKOS extension to be >> > created > >> as per [7]. >> > > Well, this is not our work to as editors to solve this, I think. Hence > the > [[ > @@TODO: check this section, according to resolutions on ISSUE-56@@ > ]] > that is in this section, showing that we do not consider that it is > stable. > > Thanks again for these very helpful comments. I hope you will not mind > answering the questions that I have asked on some of them... > > Best, > > Antoine > > >> Quentin >> >> [1] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer >> [2] http://www.w3.org/2006/07/SWD/SKOS/reference/20071223 >> [3] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/ >> [4] http://www.w3.org/2006/07/SWD/track/issues/44 >> [5] http://www.w3.org/2006/07/SWD/track/issues/56 >> [6] >> http://www.w3.org/2001/sw/Europe/reports/thes/1.0/guide/20040504/#3.9 >> [7] http://www.w3.org/2004/02/skos/extensions/spec/ >> [8] >> > http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0075.html > >> ****************************************** >> * Quentin H. Reul * >> * PhD Research Student * >> * Department of Computing Science * >> * University of Aberdeen, King's College * >> * Room 238 in the Meston Building * >> * ABERDEEN AB24 3UE * >> * Phone: +44 (0)1224 27 4485 * >> * http://www.csd.abdn.ac.uk/~qreul * >> ****************************************** >> >> >> > >
Received on Monday, 28 January 2008 22:22:46 UTC