Re: [SKOS] Re: Review of the SKOS Primer

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