Re: RIF: Comments on SKOS Primer

Dear Margherita,

Thanks for your answers on my proposals! (in 
http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0003.html)
Please find below my answers on the last points

> [...]
> -  section 3.2 page 14: to me this is valid only if the people that enrich
> the concept scheme are different from the ones who own the scheme, because if
> somebody owns the scheme that they can just create the missing skos:broader
> instead of the skos:broadMatch.
>   

True. That's why this section on mapping withing one scheme emphasizes 
on this situation.

> Does this make sense? But ok I see your point. But I propose another
> possibility, basically if somebody need to create a link that doesn't exist
> in the original thesaurus, would not be enough to add a "dc:creator" to the
> created relationships?
>   

That would make sense if RDF reification (considering a relationship as 
a resource) was commonly used.
the problem is that it is not used: or not enough for us to have used it 
as a solution for ISSUE-36 concept scheme containment 
(http://www.w3.org/2006/07/SWD/track/issues/36), while it would have 
been a trivial solution...

>  
> -  section 3.4 skos:subject: well here see above in my emails. I really wish
> not to create other tags other than the ones exists already. For me SKOS is
> for the KOS, if I need to use the skos:concepts for indexing, will be the
> standard used in my indexing system that identify how to express that an
> skos:concept is the subject for a document or another resource. Also because
> that system may allow me to decide to use the string or better the URI of the
> concept.
>   

Thanks again for your input. Note that for the moment the Primer follows 
your advice ;-)
> - section 4.1: page 17: rdf:nil -> seems more clear, but i need to go back
> and read the full document (the one modified by you) then i will let you know
> better.
>   

OK.
> [...]
>
> (end of Comments on SKOS Primer)

Thanks again for taking time to answer!

Antoine

>
> Dear Margherita,
>
> Thank you very much for the useful comments! Your effort is really 
> appreciated.
>
> 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 
> http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer
>
>>  
>> 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 http://www.w3.org/2006/07/SWD/track/issues/45)
>>  
>> - 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 
> raised http://www.w3.org/2006/07/SWD/track/issues/82
>
>>  
>> - 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 
> statement.
> ]]
>
>>  
>> - 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 
> http://www.w3.org/2006/07/SWD/track/issues/82 we'll update the 
> document accordingly.
>
>>  
>> - 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 http://www.w3.org/2006/07/SWD/track/issues/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 http://www.w3.org/2006/07/SWD/track/issues/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.
>
> So:
> - 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 
> resolution 
> (http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptualMapping/ProposalTwo) 
>
> I have tried to make it more understandable in the paragraph, which 
> now reads
> [[
> 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 sentence
> [[
> 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 
> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#collections
> 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,
>
> Antoine
>
>

Received on Monday, 4 February 2008 21:28:25 UTC