RE: SKOS Comment (various)

I wonder about the first comment concerning normative/informative distinction.
While my opinion is that the document works well without it, this is a standard comment (from my list of comments to make at last call!), and if the group has not already considered it, then consideration should be given - even if that results in no change (as I would find acceptable).

A quick glance at the issue list suggests that this has not been formally considered.

Jeremy




> -----Original Message-----
> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
> Behalf Of Sean Bechhofer
> Sent: Monday, October 06, 2008 8:08 AM
> To: Jeremy Carroll
> Cc: public-swd-wg@w3.org
> Subject: 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 Tuesday, 7 October 2008 14:26:02 UTC