Re: SKOS Comment (various)

Dear Jeremy

Thanks for your comments and suggestions. We are pleased to note your  
overall approval of the document.

With the exception of numbers 1, 4, 5 and 10 (which are essentially  
comments requiring no change or minor typos) your comments have been  
raised as the following issues: ISSUE-165, ISSUE-166, ISSUE-167,  
ISSUE-168, ISSUE-169, ISSUE-170, ISSUE-171, ISSUE-172, ISSUE-173,  
ISSUE-174, ISSUE-175, ISSUE-176. The Working
Group's issue tracker system is online at:

   http://www.w3.org/2006/07/SWD/track/

We hope to provide an initial response by Friday 10th October.

Yours,

	Sean Bechhofer
	Alistair Miles

On 6 Oct 2008, at 08:09, Jeremy Carroll wrote:

>
> This is a comment on:
> http://www.w3.org/TR/2008/WD-skos-reference-20080829/
> made on behalf of TopQuadrant.
>
> I am sorry this is a couple of days late.
>
> I did not read the appendices. I skipped over many examples.
>
> I found the document well-written, section 1.3 in particular is  
> brilliant.
> This document is in my opinion, essentially ready to advance,  
> however I have a few comments which could lead to substantive  
> change (particularly comment 14 below, also 6, 11, 12) depending on  
> WG disposition (although these may be changes that can go in under  
> the radar).
> I am not asking for substantive changes, and will accept "no  
> change" as adequately addressing such comments.
>
> 1) labeling normative material (editorial - suggest no or little  
> change)
>
> I assume this issue has been considered before, however I think I  
> like it how it is.
> My immediate reaction on seeing an LC Rec track doc that does not  
> clearly label either normative material or informative material or  
> both, is to request such labeling, since it is usually a good  
> practice.
> Once I had finished the ToC I had determined that this would be one  
> of my comments.
> However, by the time I had finished 1.3 I was having second  
> thoughts on this, and overall, I think the document gives subtle  
> gradations of normativity to its various constraints and  
> recommendations, which quite possibly actually works, and such  
> subtly cannot be achieved with the hammer of "1. Introduction  
> (Informative)". In general it is not a good practice to omit such  
> labeling because it relies on having editors who can write well. I  
> believe this to be the case in this instance.
>
> Perhaps the references should be split into normative references  
> and informative ones ...
>
> 2) reference to RDF concepts (editorial)
>
> Perhaps after first mention of RDF triples in section 1.2.
> Never one to not suggest a reference to something my me!
> It's there in the transitive closure of the references, but I  
> suspect this is an important enough normative reference that it  
> should have been included. The reliance on the RDF Primer and the  
> OWL Guide as the major refs to these technologies seems at odds  
> with the target readership.
>
> 3) Suggest forward ref to 1.7.3 from 1.3 immediately before the  
> example. (editorial)
> e.g.
> "For example, the RDF graph below (in [TURTLE] syntax, see 1.7.3)  
> expresses ..."
>
> 4) section 1.7.1 either such a slight muddle (suggest no change)
>
> I think the repeated word "means" is slightly disingenuous.
>
> I guess you mean "is intended to have the same formal meaning as"
>
> 5) very pleasing wording (suggest no change)
>
> "This definition is, however, meant to be suggestive rather than  
> restrictive, and there is some flexibility in the formal data model  
> stated below."
>
> 6) editorial clarification (?)
>
> The last sentence in section 4.6.3 I read as:
>
> "An application may reject such data but is not required to."
>
> which I think is a clearer wording if that is the intent. If that  
> isn't the intent then further wordsmithing may be necessary.
>
> 7) 5.4 s/N.B/Note/ (editorial)
>
> It was a bit surprising that this was an N.B. rather than a "Note:".
> Particularly since the note is somewhat naïve vis-à-vis RFC 4647 on  
> language ranges, I didn't feel it merited being well-noted as  
> opposed to merely noted.
>
> In fact I would prefer somewhat different text along the lines of:
>
> Note: BCP47 defines tags for identifying languages, but does not  
> define the concept of "language".
> e.g. "en", "en-GB", "en-US" are three different language tags, used  
> with English, British English and US English respectively.  
> Similarly, "ja" ...
> The condition S14 concerns language tags and hence does not  
> conflate any of these.
>
> Such wording avoids minefields like what is a language, and words  
> like denote
>
> 8) BCP reference is wrong. (editorial)
>
> 9) Suggest rephrasing S14 as "per language tag" rather than "per  
> language": this appears to be the operational intent, and "per  
> language" depends on a more thorough appreciation of the subtleties  
> of 4646/4647 than is realistic in SemWeb systems.   (clarification  
> of normative text)
>
> 10) 6.5.4 first sentence contains "a the"  (typo)
>
> 11) range of skos:member (editorial?)
>
> I take it as deliberate that no range was specified, although the  
> examples are consistent with a range being the union of  
> skos:Concept with skos:Collection.
> A discussion of the (lack of) range probably should be added to the  
> notes section.
>
> 12) 9.6.2 well formed lists (slightly substantive, change suggested  
> but not required)
>
> You could invoke:
> http://www.w3.org/TR/rdf-mt/#collections penultimate para
> [[
> Semantic extensions MAY place extra syntactic well-formedness  
> restrictions on the use of this vocabulary in order to rule out  
> such graphs. They MAY exclude interpretations of the collection  
> vocabulary which violate the convention that the subject of a  
> 'linked' collection of two-triple items of the form described  
> above, ending with an item ending with rdf:nil, denotes a totally  
> ordered sequence whose members are the denotations of the rdf:first  
> values of the items, in the order got by tracing the rdf:rest  
> properties from the subject to rdf:nil. This permits sequences  
> which contain other sequences.
> ]]
>
> which I think would be cleaner.
> Since condition S35 requires special processing of RDF collections,  
> this is not imposing much extra burden on implementators. (In fact  
> it is making it easier: S35 is particularly irksome in the face of  
> forked lists).
>
> 13) 9.6.4 (clarification of substantive material)
>
> Unlike similar paras, this one introduces a normative requirement  
> (in the first sentence).
> I suggest this should be added as S35a.
>
> 14) 10.6.5A missing discussion of Cycles involving skos:closeMatch.  
> (editorial or perhaps larger substantive)
> Possible text:
> [[
> Since
> <A> skos:exactMatch <B>
> entails
> <A> skos:closeMatch <A> (via S45, S46 and S42).
> implementations must be able to cope with cycles in skos:closeMatch.
> ]]
>
> This perhaps calls into question the stance in other sections where  
> reflexivity of other properties is left open as an implementation  
> variability.
>
> ===========
>
> My opinion on "at risk" features:
>
>     *  The URI of the SKOS namespace. The current draft introduces  
> a new namespace for the SKOS vocabulary. Comments have been made  
> that this may cause difficulty for existing SKOS implementations or  
> vocabularies. As a result, the choice of SKOS namespace should be  
> considered "at risk of change".
>
> Any implementators using a namespace URI in a WD have been warned  
> of possible change before Rec.
> Conventionally this means that the terms in the namespace or their  
> meaning might change, and the namespace URI remains unchanged. So  
> if I had been part of the WG when the namespace URI changed, I  
> would have been opposed, however that's water under the bridge and  
> the argument cuts both ways!
>
>
>     * Relationship between skos:exactMatch, skos:broadMatch and  
> skos:narrowMatch. The Working group consider that there is  
> insufficient implementation experience or evidence to be able to  
> make a firm decision (see resolution of ISSUE 75). The current  
> situation is that there are no axioms stating relationships between  
> skos:exactMatch, skos:broadMatch and skos:narrowMatch. Axioms could  
> be stated, for example, asserting that the composition of  
> skos:broadMatch and skos:exactMatch is a subproperty of  
> skos:broadMatch. Note that this would, however, require OWL 2  
> features which are not present in OWL.
>
> Since several constraints that cannot be expressed in OWL1 have  
> already been included, I see no harm in including further  
> constraints that cannot be expressed in OWL1. These should be  
> expressed in plain text, like for example, S14, and any reference  
> to OWL2 should be clearly informative and not normative.
>
>     * The naming of the property skos:topConceptOf may change.
>
> No opinion.
>
> Jeremy
>
>
>
>

--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@manchester.ac.uk
http://www.cs.manchester.ac.uk/people/bechhofer

Received on Monday, 6 October 2008 15:12:13 UTC