Re: [SKOS] Comments on SKOS Primer

Hi Tom,

Thanks for the extensive and high-quality review work!!
I will look at the detailed comments later. I prefer to first go to your more substantive issues, so that you can approve a number of changes to deal with them.

Ed, if you have time to read and approve or make suggestions, that would be welcome!

> 
> -- I could not review Figures 4.5.1 and 4.5.2, which did not
>    properly display in my browser.

That's because the links are relative, and that cannot be reproduced easily on the wiki. They are still at
http://www.w3.org/TR/skos-primer/broaderNonTransitive.jpg
http://www.w3.org/TR/skos-primer/broaderTransitive.jpg

> 
> -- The links for the ISO 2788 and ISO 5964 references are broken.

Fixed. But it's now a direct link to the ISO page where you can buy those :-(

> 
> -- I noted the stylistic use of "you" in addressing the reader in
>    several places, as in "it allows you to link...".  I have no
>    objections but wanted to check whether this is in accordance
>    with W3C style guidelines.  Ralph, do you happen to know?

Indeed, any input on that point is welcome...

> 
> -- The Primer uses the http://purl.org/dc/elements/1.1/
>    namespace and cites http://dublincore.org/documents/dces/.
>    I suggest using the http://purl.org/dc/terms/ namespace and
>    citing http://dublincore.org/documents/dcmi-terms/ (a large
>    Web document which also documents the /1.1/ namespace).
> 
>    This would mean either mapping dc: to /dc/terms/ (in Section
>    1.1) or introducing a second namespace, such as dct:, as in
>    dct:subject.  Note that dct:title and dct:date have literal
>    ranges, and dct:subject and dct:creator have non-literal
>    ranges, so all of the existing examples would still be
>    correct (e.g., X dc:subject ex1:platypus) except for one:
> 
>         X ex:madagascarFishEagle dc:creator "John smith".
> 
>    Using http://purl.org/dc/elements/1.1/creator, which has no
>    range, this example is not incorrect.  Indeed, it is not at
>    all incorrect to use /1.1/ terms for all of the examples,
>    as they currently are.  The point is that DCMI is gently
>    promoting the use of the dct: equivalents of the fifteen
>    elements because of their formal ranges.
> 
>    The example above could either be changed to use dct:creator
>    with a blank node and foaf:name, or it could remain as is
>    (dc:creator) with the addition of the /dc/terms/ namespace for
>    dct:subject, etc.  Or, of course, it would not be incorrect
>    to leave the examples as they are, using the /elements/1.1/
>    namespace throughout.

If you are gently promoting, I agree that we should do it ;-)

> 
> -- Section 4.2 uses the notion of a "structured RDF value".
>    I feel ambivalent as to whether the phrase "structured
>    value" is helpful.  I note that a Google search on the
>    exact phrase "structured RDF value" (in quotes) yields
>    only one hit -- the RDF Primer, and a search on RDF and
>    structured and value yields mostly material from 2004 or
>    before.  If we use it here, we would effectively resurrect
>    its use.  Do we really want to do this, or are there other
>    ways of expressing this that are more up-to-date?
> 
>    I note that use of the phrase "structured value" is
>    orthogonal to the question of whether or not to use
>    rdf:value.

Personally I cannot come with something else. "structured resource" is not ideal imho, as it can lead to many ambiguities. We could have "non-literal value", but that does not say much...

> 
> -- In section 4.3, it looks like a mistake to say:
> 
>         ex:FAO rdf:type skos:Concept;
>           skos:prefLabel ex:FAOlabel1; 
>           skos:altLabel ex:FAOlabel2.
>         ex:FAOlabel2 skos-xl:labelRelation ex:FAOlabel1.
> 
>     so I went ahead and changed this to use skos-xl:
> 
>         ex:FAO rdf:type skos:Concept;
>           skos-xl:prefLabel ex:FAOlabel1; 
>           skos-xl:altLabel ex:FAOlabel2.
>         ex:FAOlabel2 skos-xl:labelRelation ex:FAOlabel1.

It was indeed a mistake. Thanks for spotting it!

> 
> -- I am slightly uneasy with various references in the text
>    to "SKOS semantics" (e.g., 2.2.1) given that SKOS Reference
>    does not itself use this phrase.  SKOS Reference always
>    refers to the "SKOS data model", and SKOS does not have
>    its own "semantics" specification in the way that RDF has
>    "RDF Semantics".


We used semantics because it's really about the axioms, while the data model imo also refers to the vocabulary itself.
But that's nitpicking, let's just stay coherent with the Reference.


> 
> -- The wording of
> 
>     They have as their ranges [RDF-CONCEPTS] RDF plain literals,
>     which means that they link a skos:Concept to a character
>     string, not to another full-fledged RDF resource identified
>     with a URI.
> 
>    does not allow for the possibility of linking to a blank node.

I guess you meant that the sentence in fact *does not disallow* the use of labelling properties with blank nodes. I suggest to add "or a blank node" at the end of the last sentence. 

> 
> -- I was just wondering whether we have evidence that the following
>    use is really the "most common"...?
> 
>      The most common use of hidden labels is to
>      include misspelled variants of other lexical labels.

I propose to replace it by
[[Hidden labels may for instance be used to include misspelled variants of other lexical labels]]


> 
> -- With regard to notations (Section 4.6)
> 
>         These are language-independent symbols, designed to allow
>         an easy re-use of the whole vocabulary in different
>         languages. They are typically composed of digits,
>         complemented with punctuation signs and other characters,
>         as in the following UDC example:
> 
>    The wording seems to imply that notations are
>    "language-independent" by _definition_, not just
>    _typically_.  It seems a bit stronger than the SKOS Reference
>    formulation that notions are "not normally recognizable
>    as a word or sequence of words in any natural language" [*].
> 
>    [*] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#notations

Hmm. The language-independant here really meant, as explained in the rest of the sentence, that the notation does not change from one natural language to the other. Would you have a better term for this?

> 
> -- I wasn't sure about the word "treatments" in the following:
> 
>     This approach can be especially useful if a KOS publisher
>     wants to provide users with treatments that are specific to
>     the KOS's notation scheme.
>    
>    Does this mean specifications? interpretations? processing rules?

It was meant to avoid any commitment, actually :-)
But as it seems we have to chose, I propose to replace it by "processing rules".

> 
> -- The Example in section 5.1 says:
> 
>     <http://www.w3.org/People/Berners-Lee/card#i> rdf:type foaf:Person;
>       foaf:name "Timothy Berners-Lee";
>       rdfs:label "Tim Berners-Lee";
>       skos:prefLabel "Tim Berners-Lee"@en.</code></pre>
> 
>    While not incorrect, the example seems redundant because
>    rdfs:label is a superproperty both of skos:prefLabel and
>    (as the text says) foaf:name - which as a reader I find 
>    slightly confusing.

I'd propose to replace the value of the rdfs:label statement by "TBL".
Right now I cannot think of a better way to avoid the redundancy feeling while *not* removing the rdfs:label statement, which is useful for to boost the example's value.

> 
> -- I'm not sure the following is phrased quite right (Section 3.1):
> 
>         Had the concepts been assigned other information, such
>         as semantic relationships to other concepts, or notes,
>         these would be merged as well, resulting in completely
>         new conceptual entities.
> 
>    The idea is not that some new entity would be _created_
>    by merging asserted semantic relationships from multiple
>    sources (which is implied by "resulting in new... entities")
>    but that the _existing_ entity would in effect be overlaid
>    with different associations and thus would acquire
>    conceptually new meanings.  Maybe there's a better way to
>    put this?

True. I propose to replace the above sentence by 
[[Had the concepts been assigned other information, such as semantic relationships to other concepts, or notes, these would be merged as well, causing these concepts to acquire a new meaning.]]

> 
> -- I find the following sentence in Section 3.2 to be unclear:
> 
>     For example, a SKOS publisher can choose to locally extend
>     an existing concept scheme, and then publish the extension
>     with the linkages intact.
>   
>    What does "publish the extension" mean, and what "linkages"
>    are remaining intact?

We had a different formulation before, but it was even worse :-( I'd propose to replace by 
[[
For example, a SKOS publisher can choose to locally extend an existing concept scheme. In that case, the set of new concepts can just be published alone, linking to the concepts in the already existing scheme rather than re-defining them.
]]
@@TODO@@

> 
> -- With regard to mapping properties, instead of
> 
>     Instead, their motivation is expected to be tightly related
>     to a specific application that requires them to cope,
>     say, with conceptual redundancy resulting from several
>     KOSs coexisting.
> 
>    I suggest:
> 
>     Mapping properties are expected to be useful in applications
>     that use multiple, conceptually overlapping KOSs.

OK.

> 
> -- The second sentence in the following is not very clear (and is not
>    a complete sentence):
> 
>         By convention, mapping relationships are also expected
>         to be asserted between concepts that belong to
>         different concept schemes. Although specific scenarios
>         (such as enriching a concept scheme that lacks desired
>         semantic structure) may sometimes necessitate create
>         mappings within a scheme.
> 
>    If mappings within a scheme were needed, one would normally use semantic
>    relation properties.  Is the point here that one might want to enrich
>    _somebody else's_ concept scheme?

Yes. Would you want that to be explicitly written?


> -- In Section 3.2, referring to the first example concept scheme as a
>    "reference concept scheme" needlessly introduces a potential source
>    of confusion (what is a "reference concept scheme"?) -- especially 
>    when it talks about "referencing" the "reference ex1:cats concept".
>    Calling them something like Concept Schemes A and B might be clearer.

OK. I'd prefer not to use A and B, though, as this might conflict with the ex1 and ex2 prefixes which are clearer, I think. I'd propose to just replace "reference" by "first".

> 
> -- The final sentence in the following is unclear:
> 
>     Finally, the reader should be aware that according to SKOS semantics, the
>     mapping properties that "mirror" a given semantic relation property are also
>     sub-properties of it in the RDFS sense. For instance,
>     <code>skos:broadMatch</code> is a sub-property of <code>skos:broader</code>.
>     Consequently, every assertion of <code>skos:broadMatch</code> between two
>     concepts leads by inference to asserting a <code>skos:broader</code> between
>     these concepts. With concept scheme extension discussed in the previous
>     section, this is one of the situations where the SKOS basic semantic
>     relationships defined in Section 2.2 can hold across different concept
>     schemes.
> 
>    Looking back at the "previous section" I was unsure what this
>    sentence is actually saying and suggest that it be reworded to
>    make this explicit.

This is because the order of the sections 3.1 and 3.2 was changed resulting from Doug Tudhope's comment.
I will replace "previous" by "following".


> 
> I note that the following still would need to be edited before
> publication:
> 
> -- "Status of this Document"
> -- "Acknowledgments"
> -- A few in-line comments (<!-- ... -->).
> -- Updated reference to SKOS Reference, when available
> -- Remove @@ regarding exactMatch, etc.

I note that as well. But should it be before publication right now, or in March? 

Antoine


> 
> Detailed changes (starting with the more significant and ending with the 
> minor edits) follow below.
> 
> Tom
> 
> [1] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer?action=AttachFile&do=get&target=SKOSPrimer-081216.html
> [2] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer?action=AttachFile&do=get&target=SKOSPrimer-090105.html
> [3] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/
>

Received on Tuesday, 6 January 2009 11:43:37 UTC