Re: [SKOS] Comments on SKOS Primer - other points

On Tue, Jan 06, 2009 at 12:42:48PM +0100, Antoine Isaac wrote:
> 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]]

+1

> >-- 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?

Ah, I hadn't understood that, perhaps because it is not
entirely clear that "the whole vocabulary" refers to the set
of notations.  Maybe the sentence could use the formulation
from SKOS Reference and say

    Notations are symbols which are typically
    language-independent (i.e., not normally recognizable as
    words or sequences of words in any natural language).

Or, to emphasize usability in different language contexts:

    Notations are symbols which are not normally recognizable
    as words or sequences of words in any natural language and
    are thus usable independently of natural-language contexts.

> >-- 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".

I see the point in being vague, but "processing rules" is okay.
What do others think?

> >-- 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.

Okay.

> >-- 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.]]

Okay.  Maybe "s/a new meaning/new meanings/".

> >-- 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@@

That's much better but could perhaps be further improved; I'll 
think about it too.

> >-- 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?

I'll think about this too.

> >-- 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".

Okay.

> >-- 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'll take a closer look at this point too...

Tom

-- 
Tom Baker <tbaker@tbaker.de>

Received on Wednesday, 7 January 2009 17:29:16 UTC