SKOS Reference Review Response

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

------------------------------------------------------------------


 > 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

Received on Friday, 22 August 2008 09:00:44 UTC