Re: SKOS Reference Review Response

Sean Bechhofer wrote:
> 
> 
> Dear Guus
> 
> 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,

Thanks for the elaborate response. I'm happy with the changes and 
support publications as LC document.

Guus

> 
>      Sean & Alistair
> 
> ------------------------------------------------------------------
> 
> 
>  > GENERAL EDITING
> 
>  > Please change "foo/bar" examples.
> 
>    * Section 1.4 changed to dogs/cats. SKB
>    * Section 1.6.1 changed to Person/hasParent/hasMother. SKB
>    * Examples using foo/bar changed to love/adoration. SKB
> 
>  > "Integrity constraints/conditions": use one of these forms  consistently
> 
>    * Changed in 9.6.2. SKB
> 
>  > "data" variably used as singular or plural, e.g. "SKOS data are"  but 
> also "some given data conforms to "
> 
>    * Usage changed consistently to plural. SKB
> 
>  > SYNOPSIS
> 
>  > "documented with various types of note" note => notes
> 
> I believe this is ok as it stands, with the plural form of types. SKB
> 
>  > STATUS
> 
>  > The 2nd "feature at risk" is unclear. We have to state the options 
> and how the current choice might change (e.g. adding property-chaining 
> axioms).
> 
> Done. SKB
> 
>  > SEC. 1
> 
>  > Consider to add a note about the overall design rationale behind 
> SKOS, roughly covering the following issues:
>  > - wide coverage of KOSs required
>  > - therefore danger of SKOS schema overcommitment
>  > - WG rationale: if in doubt, don't include a formal constraint (least 
> commitment strategy), but suggest usage convention or specialization 
> instead => see Primer
> 
> The following has been added before Section 1.6 (How to Read this Document)
> 
> 1.5 Design Rationale
> 
> As discussed above, the notion of a Knowledge Organisation System
> encompasses a wide range of artefacts. There is thus a danger of
> overcommitment in the SKOS schema, which could preclude the use of
> SKOS for a particular application. In order to alleviate this, in
> situations where there is doubt about the inclusion of a formal
> constraint (for example, see discussion about
> <code>skos:hasTopConcept</code>), the constraint has not been stated
> formally. In such cases, usage conventions may be suggested, or
> specialisations of the SKOS vocabulary may be used in order to enforce
> constraints (see the SKOS PRIMER). SKB
> 
>  > 1.2: suggest to change section title to "SKOS Overview"
> 
> Done. SKB
> 
> 1.3
> 
>  > " ...I.e. SKOS is itself an OWL Full ontology."
> delete this part of the sentence as it is more or less a repetition of 
> the earlier part.
> 
> Removed. SKB
> 
>  > [[  I.e. it is appropriate (if one has the time, effort and need) to 
> manually re-engineer a thesaurus or classification scheme as a formal 
> OWL ontology, using the "concepts" of the thesaurus as a starting point 
> for creating classes, properties and individuals in the ontology, and 
> using the informal hierarchies and association networks of the thesaurus 
> as a starting point for creating the axioms and facts of the ontology. 
> However, OWL is a formal ontology language, and it does not by itself 
> provide a natural or suitable data model for expressing a thesaurus or 
> classification scheme. I.e. it is not appropriate to express the 
> "concepts" of a thesaurus or classification scheme directly as classes 
> of an ontology, nor to express the informal (broader/narrower) hierarchy 
> of a thesaurus directly as a set of class subsumption axioms. 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.]]
> 
>  > I suggest to delete this paragraph. I think the issue is made clear 
> enough in the rest of the text (also in 1.4), and this paragraph might 
> be perceived as too opinionated.
> 
> Removed. SKB
> 
>  > 1.4
> 
>  > Should we label this section explicitly as "Informative"?
> 
> Left as is. SKB
> 
>  > 1.5
> 
>  > [[  These statements are not integrity conditions. I.e. the graph 
> below is perfectly consistent with the SKOS data model, despite the fact 
> that <A> and <B> have not been explicitly declared as instances of 
> skos:Concept.]]
> 
>  > I find this unclear, in particular the "despite" part. I would 
> reverse the argument: OWL Full does not require that <A> and <B> are 
> explicitly defined as concepts, so the model is consistent. You could 
> also argue that it is till an integrity constraint, as it disallows, for 
> example, <A> to be a concept scheme. This is the only point in my review 
> where I would appreciate some discussion.
> 
> The section has been rewritten. SKB
> 
>  > 1.7
> 
>  > "an RDF graph" => "a RDF graph"
> 
> I believe that "an RDF Graph" is the correct usage. Adopting the wisdom 
> of the crowd, Google gives 36,000 hits for "an RDF graph" and 785 for "a 
> rdf graph". SKB
> 
> 
> SEC. 2:
> 
>  > I suggest to make the table ordering more logical:
> 
>  >   skos:Concept skos:ConceptScheme skos:inScheme skos:hasTopConcept 
> skos:topConceptInScheme skos:altLabel skos:hiddenLabel skos:prefLabel 
> skos:note  skos:notation   skos:changeNote   skos:definition  
> skos:editorialNote   skos:example   skos:historyNote   skos:scopeNote   
> skos:semanticRelation   skos:broaderTransitive   skos:broader   
> skos:narrowerTransitive   skos:narrower   skos:related   
> skos:Collection   skos:OrderedCollection   skos:member   
> skos:memberList     skos:mappingRelation   skos:closeMatch        
> skos:exactMatch        skos:broadMatch   skos:narrowMatch   
> skos:relatedMatch
> 
> The table is ordered according to document section. We suggest to leave 
> it as is. SKB
> 
>  > SEC. 4
> 
>  > Example 5:
> 
>  > [[  <MyConcept> skos:topConceptInScheme <MyScheme> .]]
> 
>  > This statement could have been derived from the inverse semantics. 
> Either remove or explicate in the text.
> 
> Triple removed. SKB
> 
>  > I find the name "skos:topConceptInScheme" too contrived. I prefer the 
> natural inverse of "skos:hasTopConcept", namely "skos:topConceptOf". 
> This is probably also eaier to understand and remember.
> 
> Changed to skos:topConceptOf. SKB
> 
>  > 4.6.3 named RDF graphs
> 
>  > Explain (or refer to Primer) the issue of schema containment and 
> potential use of SPARQL + named graphs
> 
> This section has been removed following discussion during the 19-08-08 
> telecon. SKB
> 
>  > SEC. 5
> 
>  > 5.6.2
> 
>  > [[  For an application that needs to identify labels using URIs, 
> consider using the SKOS eXtension for Labels defined in Appendix A. ]]
> 
>  > Instead of this single sentence I suggest to make a separate note 
> about XL (e.g. "5.6.3 Defining label relations"), explicating in a few 
> sentences why this is needed, just to point readers in the right direction.
> 
> New section added. SKB
> 
>  > 5.6.4
> 
>  > This note feels a bit redundant as the point about language tags is 
> already made at the end of 5.4
> 
> The note does provide illustrative examples, so I would suggest it 
> remain. SKB
> 
> 
>  > SEC. 7
> 
>  > "7" => "seven"
> 
> Done. SKB
> 
>  > Example 25: I suggest to refrain from using the construct "rdf:value" 
> as it is so rarely used. If you really need it, you have to add an 
> explanatory note + RDF ref.
> 
> Dealt with in the primer. See: 
> http://lists.w3.org/Archives/Public/public-swd-wg/2008Aug/0025.html. SKB
> 
>  > SEC. 8
> 
>  > [[  S26: skos:related is disjoint with the property 
> skos:broaderTransitive. ]]
> 
>  > Is skos:related also disjoint with skos:narrowerTransitive?
> 
> Yes, due to the fact that skos:related is symmetrical. Added explanatory 
> note. SKB
> 
>  > 8.6.4.
> 
>  > Explain briefly rationale why skos:related is not transitive.
> 
> Dealt with in the primer. See: 
> http://lists.w3.org/Archives/Public/public-swd-wg/2008Aug/0025.html. SKB
> 
>  > 8.6.6
> 
>  > "(e.g. simple query expansion algorithms)": delete "simple"
> 
> Done. SKB
> 
>  > 8.6.10
> 
>  > First par:
>  > ".. distinct in nature, and that therefore a ..."
>  > =>
>  > ".. distinct in nature. Therefore a ..."
> 
> Done. SKB
> 
> 
>  > SEC 9
> 
>  > 9.6
> 
>  > Suggest to explain briefly the use of "( .. )" notation in Turtle.
> 
> Done (in 9.5). SKB
> 
>  > SEC 10
> 
>  > S46: should skos:exactMatch not also be disjoint with skos:narrowMatch?
> 
> Symmetry of exactMatch will ensure this. Added explanatory note. SKB
> 
>  > 10.6.7:
> 
>  > "link to individuals"
>  > to => two
> 
> Done. SKB
> 
>  > [[  Generally speaking, using owl:sameAs in this way will lead to 
> inappropriate inferences, which may sometimes (but not always) be 
> detectable by checking consistency with the SKOS data model.]]
> 
>  > Obscure sentence. The point was already made above, suggest to delete 
> this sentence.
> 
> Done. SKB
> 
> APPENDIX
> 
>  > "A property xl:labelRelation is defined. "
>  > =>
>  > "The SKOS data model also defines the property xl:labelRelation."
> 
> Done. SKB
> 
>  > A1
> 
>  > I suggest to use "skos-xl:" in the examples instead of "xl". In this 
> document it is not ambiguous, but in actual usage it might lead to 
> reduced clarity. People will use the reference as a model.
> 
> Is this allowed? A hyphen in a namespace name? I have replaced with 
> skosxl. SKB
> 
>  > A2.1
> 
>  > "an RDF plain literal": an => a
> 
> See above comment. SKB
> 
>  > A2.2
> 
>  > Shouldn't there be a definition c.q. semantic condition to define the 
> cardinality of precisely 1 for xl:literalForm? BTW this would make the 
> FuctionalProperty definition superfluous.
> 
> Condition S52 has been changed to reflect this. SKB
> 
>  > A2.4.1
> 
>  > "As stated above ...": this has actually not been stated yet, see 
> previous comment.
> 
> See above response. SKB
> 
>  > [[  Second, the function is not surjective. In other words, there may 
> be no instances of xl:Label with a literal form  corresponding to a 
> given plain literal. ]]
> 
>  > I cannot parse this sentence (in particular the last part); please 
> reformulate.
> 
> Reworded as: In other words, for a given plain literal <code>l</code>, 
> there may <strong>not</strong> be an
> instance of <code>skosxl:Label</code> with <code>l</code> as a
> literal form. SKB
> 
> Reworded a bit more, to avoid possible misreading as a normative 
> statement, as: In other words, for a given plain literal <code>l</code>, 
> there might not be any instances of <code>skosxl:Label</code> with 
> literal form <code>l</code>. AJM
> 
>  > A3.4.2
> 
>  > "Note the two integrity conditions on the SKOS labeling properties 
> defined in Section 5."
>  > =>
>  > "In Section 5 two integrity conditions were defined on the basic SKOS 
> labeling properties."
> 
> Done. SKB
> 
> 
> -- 
> Sean Bechhofer
> School of Computer Science
> University of Manchester
> sean.bechhofer@manchester.ac.uk
> http://www.cs.manchester.ac.uk/people/bechhofer
> 
> 
> 
>