Re: RIF: Comments on SKOS Primer

Dear Margherita,

Thank you very much for the useful comments! Your effort is really 

Please find below my answers to these comments. These can be either 
actions on the document or further questions...
A new draft is available at

> Here my contribution for the revision of the SKOS Primer.
> - Section about "Alternative Lexical labels"
> In this example:
> ex:rocks rdf:type skos:Concept;
>   skos:prefLabel "rocks"@en;
>   skos:altLabel "basalt"@en;
>   skos:altLabel "granite"@en;
>   skos:altLabel "slate"@en.
> I was thinking if it is good to suggest a better representation of this
> example (as this solution is mentioned not to be recommended), for 
> example by
> suggesting to make "basalt", "granite", etc. NT of "rocks".

It's true that it would be a better way to represent this domain in a 
KOS. Yet, I'm feeling unconfortable since writing this in the document 
would be a way to say to a SKOS user "well, just go to the KOS designer 
and ask her to re-build the KOS". Currently, I have added a semi-formal 
specification of an ideal KOS, hoping that it will generally not be 
considered as a kind of "normative replacement rule" for these upward 
posting situations:
This last example, however, does not correspond to a recommended 
practice.  A KOS more appropriate for this domain would introduce an 
instance of skos:Concept for each kind of rocks considered (basalt, 
granite and slate) and assert it as a narrower concept of ex:rock.
Is it enough?

> - skos identify the prefLabel, altLabel and hiddenLabel. I suppose 
> that the
> altlabel and hiddenLabel are the ones that can be used in case of 
> USE/UsedFor
> relationship in a thesaurus.
> I would suggest to have a look to the USE/UsedFor+ relationship, 
> between a
> compound term and 2 terms, for example:
> (i have no good agrovoc examples now, lets use this)
> "mad cow disease symptoms" USE "mad cow disease" AND "symptomps"
> "mad cow disease" USEDFOR+ "mad cow disease symptoms"
> "symptomps" USEDFOR+ "mad cow disease symptoms"
> We have to check if this exists in the ISO2788, and in this case try 
> to solve
> it. If, instead, is only something used in the AGROVOC thesaurus, then 
> do not
> consider this as not standard.

I have added
@@TODO: add a paragraph when ISSUE-45 
NaryLinksBetweenDescriptorsAndNonDescriptors is resolved@@
(ISSUE-45 is at
> - in section 2.3 for all relationships as already mentioned I suggest 
> to make
> them more clear by adding the verb. For example:
>  - skos:hasNarrowerConcept
>  - skos:hasBroaderConcept
>  - skos:hasRelatedConcept
> etc.

I think there is nothing here for the Primer at the moment. But I have 

> - in section "Broader/Narrower Relationships"
> We should think if it is needed to have both these examples:
> ex:animals rdf:type skos:Concept;
>   skos:prefLabel "animals"@en;
>   skos:narrower ex:mammals.
> ex:mammals rdf:type skos:Concept;
>   skos:prefLabel "mammals"@en;
>   skos:broader ex:animals.
> As the two relationships are inverse each other, the second examples 
> can be
> automatically inferred. I was thinking that, because when i created 
> the SKOS
> version of AGROVOC, I created both relationships but the file resulted 
> to be
> very big. In was thinking in this case if we could give users 
> suggestion in
> order to make the skos representation more efficient by limiting the
> information to represent and leave all what can be inferred out. Do 
> you think
> is possible?

In the paragraph that follows this example I propose to add
This can be of use for making SKOS representations more efficient by 
limiting the information they contain. In the above example, for 
instance, the statement ex:mammals skos:broader ex:animals can be left 
out if, before exploiting the concept scheme data, one uses an OWL 
reasoner to infer it from the ex:animals skos:narrower ex:mammals 

> - Section 2.4: also for this relationship i would suggest to have
> skos:hasNote, skos:hasScopeNote, etc.

Again, I'm afraid there is nothing here for the Primer at the moment. 
But as soon as there is a resolution on we'll update the document 

> - section 2.5: considering the skos:inScheme tag. I personally not 
> used it in
> the agrovoc skos version, because i preferred to make use of the
> skos:hasTopConcept to associate concepts to the ConceptSchemes. Using 
> this i
> define the full hierarchy of the scheme, because i consider all the
> skos:hasTopConcept plus all the skos:narrower to build the full 
> hierarchy of
> the classification scheme.
> Therefore I do not use the skos:inScheme for every concept in the 
> thesaurus
> because this information again can be inferred.
> Here i would like also to point out another problem: if i have multiple
> schemes, i can define the skos:hasTopConcept for both schemes. But 
> then, i
> would like to create the hierarchy of the two schemes differently from 
> the
> thesaurus hierarchy. is this possible?
> For example I have scheme SA and scheme SB, and I have the following skos
> concepts:
>   skos:concept activities
>  skos:hasNarrower forest activities
>   skos:hasNarrower logging
>   skos:hasNarrower fire protection
>   skos:concept enviroment protection
>  skos:hasNarrower water pollution prevention
> Maybe I would like in SA this situation:
>  - forest activities
>   - logging
>  - enviroment protection
>   - fire protection
>   - water pollution prevention
> And in SB this situation:  - forest activities
>  - enviroment protection
> (sorry could not find good examples but i hope this gives you a good 
> idea of
> what i mean. Basically i would like to customize the hierarchies based on
> schemes).

I don't know if this is for the Primer.
I've raised ISSUE-83 for 
the first part (inferring skos:inScheme statements from 
skos:hasTopConcept and skos:narrower ones).
The problem is that the current SKOS semantics (see the Reference) do 
not allow for this for the moment...
I've aso added in section 2.5
@@TODO: add a paragraph when ISSUE-85 
SemanticsOfSchemeContainmentProperties is resolved@@

For the second part. Indeed I have some trouble understanding what you 
mean. The point is that SKOS is concerned with the expression of 
information at the conceptual level, and not at the display one
As Alistair once pointed out during the discussion on grouping 
constructs ISSUE-84

> I believe it should be out of scope for SKOS to convey presentational 
> information. This means that, in order to fully convey a systematic 
> presentation of a thesaurus or classification scheme, you might need 
> something other than SKOS.

- either you want to express hierarchies that are conceptually 
different, and in this case you should create two concept schemes. And 
have them "containing" using the pattern introduced in the Reference the 
different skos:broader assertions that you need for each scheme.
- either you want to display different scheme from a same hierarchy, and 
in this case you've got to implement your own algorithm. For instance 
displaying the hierarchy until a given level.
Does this address your concern?

> - in 2.5 at page 11 is written "no two concepts in the same concept 
> scheme be
> given the same preferred lexical label in a given language"... But 
> prefLabel
> are in general assigned to skos:concept indipendently if they belongs 
> to a
> scheme or another scheme, so i suppose this sentence is valid also in the
> entire skos representation...?

No, because even if SKOS concepts have labels independently of concept 
schemes, the semantic constraint applies just when they are included in 
concept schemes.
I propose to rewrite the above sentence to make it clearer
As mentioned in Section 2.2, it is for example recommended that no two 
concepts have the same preferred lexical label in a given language when 
they belong to a same concept scheme.

> - section 3.2 page 14: is it really possible to create mapping within the
> same concept scheme? why not to use skos:broader instead skos:broadMatch?

Yes, it is possible, as was written in the wiki page supporting the 

I have tried to make it more understandable in the paragraph, which now 
Note that it is also possible to create mapping links within a single 
concept scheme. This may happen for instance when a given application 
needs to enrich a concept scheme which lacks desired semantic structure. 
In the above example, ex2:eggLayingAnimals can be mapped to ex2:animals 
using skos:broadMatch, to compensate for the lack of skos:broader link 
between the two in the original concept scheme. Such an approach has the 
benefit of not requiring the creators of the original scheme to modify 
it, nor forcing its users to coin a new semantic definition of the 
considered concepts, which the assertion of a paradigmatic skos:broader 
relationship would practically amount to.

> - section 3.4: what is the need to define skos:subject instead of using
> dc:subject? i probably need to refer to the emails for issue48... i 
> will have
> a look as soon as possible.

I guess this is not a formal request for the Primer, is it?

> - section 4: i think this includes some comments i have done above, 
> e.g. here
> we can include the idea of having  different hierarchies for different
> classification schemes and the compount terms.

I also point to what I've written above then :-)

> - section 4.1: page 17
>  _:b0 rdf:type skos:Collection;
>     skos:prefLabel "people by age"@en;
>     skos:memberList _:b1.
>  _:b1 rdf:first ex:infants;
>     rdf:rest _:b2.
>  _:b2 rdf:first ex:children;
>     rdf:rest _:b3.
>  _:b3 rdf:first ex:adults;
>     rdf:rest rdf:nil.
> It is not clear here the "rdf:nil".

The paragraph that was above this example in the Primer now includes the 
This property links an instance of skos:OrderedCollection to a (possibly 
blank) node of type rdf:List, following the pattern that enables the 
definition of RDF collections [RDF-PRIMER]
which delegates the explanation of this pattern to
Is it OK this way? The pattern of the RDF Primer fits quite well the 
example in this section of the Primer, and I'm afraid of puting too much 
text on this (very technical) issue...

> - 4.2: i read in the skos reference about symbolic labels... (ISSUE-76) I
> think these may be useful information to be represented. In AGROVOC we 
> have
> chemical elements which can be represemted with formulas for exmample.

But would you think such a requirement is generic enough to be deal with 
by the SKOS standard? It was not captured in the Agrovoc use case, 
actually. The editors of the use case and requirements docs should have 
anticipated it ;-)

> - section 4.4: i agree very much on the relationships between labels. 
> I was
> just wondering if it is possible to refer to label also with a uri and 
> not by
> repeating the label (as one time is written when defining the label 
> and one
> time when doing the relationship).

If we keep to current resolution on ISSUE-26, this is not possible.

> Hope this helps.

It does! A lot of things were rather targetted at SKOS than the Primer 
document, but that's still very useful feedback to get. And you made 
some crucial comments about the understandability of some of our 
decisions, a Primer should certainly address them.

> I would like to mention that I am sick at home, therefore I will not 
> be able
> to participate at the teleconference tonight.

I hope you'll feel better soon.

Thanks again,


Received on Friday, 25 January 2008 10:01:05 UTC