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

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 Monday, 26 May 2008 22:28:26 UTC