W3C home > Mailing lists > Public > public-swd-wg@w3.org > October 2008

SKOS Comment (various)

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Mon, 6 Oct 2008 00:09:45 -0700
To: <public-swd-wg@w3.org>
Message-ID: <001b01c92782$84c3dc70$8e4b9550$@com>

This is a comment on:
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)
"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:
<A> skos:exactMatch <B>
<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.

Received on Monday, 6 October 2008 07:10:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:54 UTC