SKOS Core Second Review

Sincere apologies for delaying on this for so long.  I hope that some
of the enclosed remarks are useful enough to partially compensate.

Re: http://www.w3.org/2004/02/skos/core/review-2

Summary: all four changes appear to be adequately discussed and
sufficiently motivated, with no recorded dissension.  I find
nothing that should prevent the TF from proceeding with submitting
a revised editor's draft to the WG containing these changes.

Kudos for the level of detail in the proposal review document
http://www.w3.org/2004/02/skos/core/review-2


Detailed comments:

--
[1]subjectIndicatorUse-1
  drop usage of the skos:subjectIndicator property within the
  SKOS Core Vocabulary itself.

The intent within the SKOS Core namespace document [2] appears to
have been simply to help locate a human-readable definition of the
Class or Property.  While having such a triple may be useful, the
function can be performed (with looser semantics) by rdfs:seeAlso.

I question whether it should be considered good practice to use
a URI with an HTML fragment identifier as a subject indicator.
As subject indicators must define exactly one subject, it is
left to the (human) reader to decide how much of the document
fragment identified by the URI comprises this subject indicator.
The HTML fragment identifier _could_ denote a section (e.g. div,
paragraph, or span) of the document but in the particular case
of the SKOS core spec the fragment identifiers appear within
short targets; e.g. [3] without clear markup to denote (to a
machine) the totality of the intended definition.

Bernard Vatant noted in [4] that this triple in the SKOS Core
namespace might lead to confusion in Topic Maps environments
so it seems wise to remove it from the SKOS namespace document
now and reconsider the broader implications.

I don't see any objections raised to this proposal.

   [1] http://www.w3.org/2004/02/skos/core/review-2#subjectIndicatorUse-1
   [2] http://www.w3.org/2004/02/skos/core
   [3] http://www.w3.org/TR/swbp-skos-core-spec/#hasTopConcept
   [4] http://lists.w3.org/Archives/Public/public-esw-thes/2005May/0002.html

--
[5]notes-2
  deprecate skos:privateNote and skos:publicNote and replace with
  new property skos:note.

Rationale is clear.  Do you intend to add examples to the specification,
similar to that in [6]?  I expect this will be a FAQ.  (You did write
in a followup to that thread that you would add those examples, though
the change proposal doesn't make that clear.)  Perhaps that is what is
meant by the sub-proposal to add dcterms:audience example.  I suspect
that it would be wise to circulate that example to the mailing list
for comment.

I observe that there is useful clarifying material in the thread
about the semantics of editorialNote [7].  I found Stella's
citation in [8] informative.  (The [BS8723] reference [9] in the
SKOS Core Guide does not give a non-practitioner enough information
to locate this document without the aid of, e.g. Google.  I doubt,
for example, that many readers would know to what organization "BSI"
refers.  Please expand that reference some more.)

I worry a bit about the vocabulary management side effects of making
such a change to the property hierarchy, but I observe that implementors
were given notice that this area could change as both publicNote and
privateNote have status [10] 'unstable' in the 10 May specification.
Of necessity, that status should be understood to propagate to
subProperties so I think implementers have been given appropriate
caution.

   [5] http://www.w3.org/2004/02/skos/core/review-2#notes-2
   [6] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jul/0000.html
   [7] http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0000.html
   [8] http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0007.html
   [9] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#refBS8723
   [10] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20050510/#secChange

--
[11]symbolicLabelsRange-3
  refactor symbolic labelling properties and change range
  to DCMI type Image.

The semantics of altSymbol and prefSymbol feel under-specified to me.
I cannot, for example, decide whether the use case would be adequately
(or perhaps better) handled through additional to UNICODE such that
the desired symbol(s) can be conveyed as text.  It is not clear
whether symbols used as "preferred symbolic labels" should have
glyph-like semantics.  The BLISS example and reference would
support such a presumption.  I suggest there exists here an
opportunity to add clarity.

I appreciate the utility of moving the grounding from FOAF to DCMI
but the comment that raised this issue noted that there were other
FOAF dependencies.  I wonder why the remaining one (subjectIndicator)
is not being addressed?

Any objection based on the semantics of DCMI:Image are apparently
made moot by the stated intention [12] to modify the FOAF
specification.  Clearly, if FOAF:Image becomes a subclass of
DCMI:Image the net result is the same for applications.

   [11] http://www.w3.org/2004/02/skos/core/review-2#symbolicLabelsRange-3
   [12] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jun/0057.html

--
[13]seeAlsoTranslations-4
  add rdfs:seeAlso statements to fr and de labels/definitions/comments.

(I guess the full proposal is to add French and German translations
of the namespace document and to add the seeAlso properties to
the primary namespace document.)

Sounds good.  Each of the language variants should also be related
by rdfs:seeAlso back to the primary namespace document (but not
to the other translations -- that C(n,2) problem is too big a
maintenance burden.)

I like the clever use of xml:base, however this usage brings
a need to take extra care in, for example, citing a modification
date for the translation.  I suggest that each translation include
a triple such as

  <rdf:Description rdf:about="http://lists.w3.org/Archives/Public/public-esw-thes/2005Jul/att-0036/core_de.rdf">
     <dct:modified>2005-07-11</dct:modified>
  </rdf:Description>

(i.e. use the full URI of the variant in the subject,
overriding the xml:base)

The German translation [14] has triples that are untranslated from
the primary namespace document and should be removed (e.g.
dc:creator, dc:contributor) and some that are duplicate
(foaf:homepage).  Those should be removed from that variant.

   [13] http://www.w3.org/2004/02/skos/core/review-2#seeAlsoTranslations-4
   [14] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jul/att-0036/core_de.rdf

[end]

Received on Monday, 19 September 2005 19:59:35 UTC