Re: [SKOS] comments on SKOS Primer 2008-02-12

Sorry I forgot the link to the draft: it is available at
http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer, May 27 draft

Antoine
>
> Dear Alistair,
>
>> Dear Antoine, Ed,
>>
>> I've finally had a chance to go through the SKOS Primer in detail, 
>> apologies for not doing so sooner. Here are a few comments on the 
>> 2008-02-12 edition of the SKOS Primer, I hope these are useful for 
>> subsequent revisions.
>
> Thank you very much for these comments. I've taken quite some times to 
> answer them, sorry. But they were in fact very useful!
>
>>
>> In a nutshell, I really like this document. I think it is just the 
>> right length, style, tone and level of detail, and I enthusiastically 
>> support its publication as-is.
>
> This was not formally answered at the time, but thank you very much ;-)
>
>>
>> The only two sections I think need further discussion are sections 
>> 3.1 and 3.2.
>>
>> Section 3.1 (re-using and extending concept schemes) is an important 
>> section, I like the way it's written and I think we should say as 
>> much as we can on this subject. One difficulty, however, is that the 
>> pattern described in the first half of the section, where 
>> skos:inScheme is used to "include" individual concepts from another 
>> scheme, relies upon a particular URI dereference behaviour for 
>> resources of type skos:Concept. As yet, we have not defined any best 
>> practice or minimum required URI dereference behaviour for resources 
>> of type skos:Concept, so there is a potential issue here. I've 
>> created an issue in the SWD tracker as a placeholder for this: 
>> http://www.w3.org/2006/07/SWD/track/issues/86 . I'm not sure what 
>> priority we should give this, I'd be happy to take advice from the WG.
>
> I'm not sure we can change anything on this specific aspect right now, 
> can't we?
>
>>
>> Section 3.2 (mapping concept schemes) is also an important section, 
>> and again I think we should say as much as we can. The only part of 
>> this section that is potentially problematic is the final paragraph, 
>> which recommends the use of SKOS mapping properties to "overlay" 
>> additional structure on "someone else's" concept scheme (my quotes). 
>> I'll talk about this more in relation to issue 74, but for now I just 
>> wanted to flag this up as an idea I've not seen before reading the 
>> SKOS Primer.
>
> Following the resolutions we made in the F2F, I have reworked a bit 
> this section in the new editor's draft. Comments are welcome.
>
>>
>> The rest of my comments are editorial and mostly nit-picks.
>>
>> In the SKOS Reference, we opted to talk about the "SKOS data model" 
>> in place of the "SKOS semantics".
>>
>> Section 2.1
>>
>> "Concepts denote ideas or meanings..." -- as I understand the term 
>> "denotation", symbols (e.g. URIs) denote, concepts do not.
>
> [
> Concepts denote ideas or meanings that are the units of thought 
> [Willpower Glossary] which underly the KOSs used in a number of 
> applications
> ]
> ->
> [
> Concepts are the units of thought [Willpower Glossary] -- e.g. ideas, 
> meanings, or even (categories of) objects and events -- which underly 
> the KOSs used in a number of applications
> ]
>
>>
>> "...introduces the skos:Concept RDFS clss..." -- remove "RDFS"
>
> done
>
>>
>> Section 2.2.2
>>
>> Maybe add a note at the end of the section that guidance on the 
>> construction of KOS is generally beyond the scope of SKOS, with 
>> reference to ISO 2788, BS 8723 etc.
>
> I thought it difficult to add at the end as a note (we would just have 
> notes now)
> I propose to replace
> [
> This last example, however, does not correspond to a recommended practice
> ]
> by
> [
> However, and even though SKOS is clearly not intended as a guide for 
> KOS design replacing existing standards [ISO-2788, BS8723-2], the 
> reader should be aware that this last example does not correspond to a 
> recommended practice.
> ]
>
>>
>> Section 2.3
>>
>> (First bullet) Maybe add a caveat that not all part-whole 
>> relationships are suitable as hierarchical relationships, with link 
>> to relevant section(s) of ISO 2788, BS 8723 etc.
>
> I'm afraid we make already too many mention of them, while they are 
> not freely available.
> I'd just propose
> [
> - skos:broader and skos:narrower enable the representation of 
> hierarchical links, such as the relationship between one genre and its 
> more specific species, or, depending on interpretations, the one 
> between one whole and its parts;
> - skos:related enables the representation of associative 
> (non-hierarchical) links, such as the relationship between one type of 
> event and a category of entities which typically participate in it. 
> Another use for skos:related is between two categories where neither 
> is more general or more specific -- note that, as the previous point 
> hints at, it can also be sometimes used to represent part-whole 
> relationships that are not represented as hierarchical links.
> ]
> (and ISO2788 is cited just before anyway)
>
>>
>> Section 3.1
>>
>> We should probably come up with a more concrete example than 
>> "nicePlatypus" and "badPlatypus" :)
>
> Oh, I'm really disappointed :-)
> For the moment I'll flag it as a potential TODO: would you be happier 
> with big and small platypus?
>
>>
>> Section 3.3
>>
>> Maybe ex:painter or something similar, instead of ex:title, as an 
>> example of defining a property on the class?
>
> I'd propose ex:support
>>
>> Section 4.1
>>
>> "SKOS Core" -- the only time "Core" is added to "SKOS".
>
> removed
>
>>
>> Section 4.1.3
>>
>> s/concepts place/concept's place/
>
> Hmm actually given that the first part of the sentences mentions 
> conceptS I'd propose "concepts' place" for this:
> [
> In other words, grouping concepts into collections does not replace 
> assertions about the concepts' place in a concept scheme.
> ]
>>
>> Section 4.7
>>
>> transitiveBroader, raised already.
>
> I think it was already done, also.
>
> Thanks again!
>
> Antoine
>
>

Received on Tuesday, 27 May 2008 08:01:52 UTC