- From: Ralph R. Swick <swick@w3.org>
- Date: Mon, 19 Sep 2005 15:58:49 -0400
- To: public-esw-thes@w3.org
- Cc: public-swbp-wg@w3.org
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