Re: ISSUE-164 draft response

Hi Alistair, Sean

OK, I'll do that.
Note that I think I will also add something in the Primer to (partially) 
answer Dou'g comments on ownership. I'd propose this:

> Finally, about your request for saying "something on how KOS 
> developers might publish a vocabulary in SKOS, while asserting some 
> practical form of ownership". I it is about the possibility to 
> represent the provenance of statements that "compose" a KOS (e.g. the 
> skos:inScheme statements), we unfortunately cannot propose an easy way 
> for doing this for the moment. The resolution SKOS ISSUE-36 [3] gives 
> hints about how this has been left to future implementations, e.g. 
> using RDF named graphs. The Primer also touches the issue in section 
> 3.1 (in "Note—owl:imports and re-using KOSs") [4]. We could however be 
> more explicit, and propose to replace
> [
> If an application is concerned with provenance information, additional 
> steps may be required in order to maintain the provenance of the 
> imported triples. Such functionality is however currently outside the 
> scope of SKOS.
> ]
> by
> [
> If an application is concerned with practical provenance or ownership 
> information, additional steps may be required in order to maintain the 
> provenance of the imported triples, using for instance RDF named 
> graphs. Such functionality is however currently outside the scope of SKOS.
> ]

Not a big change, but at least the word "ownership" would appear in the 
Primer, and a first hint at a solution would be mentioned.

There is however a problem: when we decided on closing ISSUE-36, we had 
a piece of text that was refering to named graphs explicitly, and also 
SPARQL patterns. But now this does not appear any more in the Reference. 
Maybe I've missed a further resolution on that point, but I guess that 
closing an issue with a resolution that is not completely implemented in 
our docs is not really good, is it?

Antoine


> Hi Antoine,
>
> On Tue, Oct 14, 2008 at 02:57:53PM +0200, Antoine Isaac wrote:
>   
>> Hi Alistair,
>>
>> OK, I had not really thought about the possibility to postpone things  
>> for next future...
>> I think your mail would be actually a good answer to (this part of)  
>> Doug's comments.
>>
>> If I sum up, the answer to Doug's original mail would be for the moment:
>> - the points that you approved in [1]
>> - something that I'd derive from your mail below
>>
>> Does this sound OK?
>>     
>
> That sounds great.
>
> Cheers,
>
> Alistair.
>
>   
>> Antoine
>>
>> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0135.html
>>
>>     
>>> Hi Antoine,
>>>
>>> I'd rather not say anything at all. If we do, I think we're
>>> overstretching. I suggest we niether encourage nor discourage this
>>> practice. We really have no experience here, so better to say nothing
>>> and let the community define best practice in response to
>>> implementation experience.
>>>
>>> If Doug believes this practice is potentially harmful, I encourage him
>>> to publish a brief best practice note and inform the SKOS community
>>> via the mailing list. I'd also be more than happy to set up a "SKOS
>>> community best practices" wiki page to collect links to such
>>> statements.
>>>
>>> Practices for KOS linking would also be the subject of a very
>>> interesting research paper :)
>>>
>>> Cheers,
>>>
>>> Alistair.
>>>
>>> On Mon, Oct 13, 2008 at 08:20:09AM +0200, Antoine Isaac wrote:
>>>   
>>>       
>>>> Hi Alistair,
>>>>
>>>> Thanks for your comments!
>>>> About the part of my answer you find debatable:
>>>>
>>>>     
>>>>         
>>>>>> Regarding your last comment on the potential problems raised by   
>>>>>> extension and inclusion of concepts in different schemes, I'd 
>>>>>> propose  the following note:
>>>>>> [
>>>>>> Note -- messing with existing KOSs. RDF provenance mechanisms may 
>>>>>> be  used to track additions to a KOS that are not done by its 
>>>>>> original   designers. However, such functionality is currently 
>>>>>> outside the scope of  SKOS. Accordingly, this document encourages 
>>>>>> publishers of new SKOS  concepts not to include them via 
>>>>>> skos:inScheme statements into existing  KOSs that they do not not 
>>>>>> "own". In the above example, one should  therefore not assert 
>>>>>> that ex2:abyssinian belongs to   ex1:referenceAnimalScheme.
>>>>>> ]
>>>>>>             
>>>>>>             
>>>>> I'm not sure about this. Just because SKOS does not deal with RDF
>>>>> provenance, does not mean there aren't good solutions elsewhere. I
>>>>> suggest not to include the last two sentences.
>>>>>
>>>>>         
>>>>>           
>>>>>> Notice that this last note also adresses your request for saying  
>>>>>>  "something on how KOS developers might publish a vocabulary in 
>>>>>> SKOS,  while asserting some practical form of ownership". For the 
>>>>>> moment, we  unfortunately cannot propose an easy way for doing 
>>>>>> this.
>>>>>>             
>>>>>>             
>>>>> ...but we encourage the community of practice to develop
>>>>> solutions. SKOS can only go so far, the rest is up to the community.
>>>>>         
>>>>>           
>>>> I guess you're right, that people could one day use cool provenance   
>>>> mechanisms. However, Doug's comment was making much sense, and even 
>>>> with  appropriate provenance mechanisms I do not think it is very 
>>>> good  practice to include one's own concepts in someone else's 
>>>> concept scheme,  when this someone else is likely not to have 
>>>> anticipated such an  addition. Otherwise I'd feel it would be 
>>>> encouraging some cuckoo  behaviour ;-)
>>>>
>>>> As a compromise we could soften the end of the note:
>>>> [
>>>> Note -- messing with existing KOSs. RDF provenance mechanisms may be  
>>>> used to track additions to a KOS that are not done by its original   
>>>> designers. However, such functionality is currently outside the scope 
>>>> of  SKOS. Generally, this document thus encourages publishers of new 
>>>> SKOS  concepts not to include them via skos:inScheme statements into 
>>>> existing  KOSs that they do not not "own", unless they do so using 
>>>> mechanisms that  allow distinguishing clearly the information they 
>>>> publish. In the above  example, one should therefore not assert that 
>>>> ex2:abyssinian belongs to  ex1:referenceAnimalScheme using a bare, 
>>>> provenance-neutral skos:inScheme  triple.
>>>> ]
>>>>
>>>> Would that be ok?
>>>>
>>>> Cheers,
>>>>
>>>> Antoine
>>>>
>>>>     
>>>>         
>>>>> Cheers,
>>>>>
>>>>> Alistair.
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>>>> I hope these modifications seem appropriate to you. Please do not 
>>>>>>   hesitate to send further comments, your experience is really  
>>>>>> precious!
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0062.html
>>>>>> [2] http://www.w3.org/TR/skos-ucr/#Accepted
>>>>>>
>>>>>>             
>>>>>>             
>>>>>>> ISSUE-164: Extension vs mapping (SKOS Primer)
>>>>>>>
>>>>>>> http://www.w3.org/2006/07/SWD/track/issues/164
>>>>>>>
>>>>>>> Raised by: Antoine Isaac
>>>>>>> On product: SKOS
>>>>>>>
>>>>>>> Raised by Doug Tudhope in [1]
>>>>>>>
>>>>>>> Open world discussion and extension vs mapping in 3.1 and 3.2
>>>>>>>
>>>>>>> I’m a little concerned about the relative emphasis apparently given to extension
>>>>>>> vs mapping. The primer might be read as suggesting that the default way of
>>>>>>> connecting two KOS is via extension or direct linking, which I think would be
>>>>>>> inappropriate. While there are good cases for (third party) extending a KOS (eg
>>>>>>> by including local extensions), the wording in the intro to section 3 is perhaps
>>>>>>> a little enthusiastic and might run the risk of not sufficiently recognizing the
>>>>>>> potential problems of linking two different KOS. LIS experience has recognised
>>>>>>> that any major KOS represents a particular world view and that joining two
>>>>>>> different KOS in an effective manner is not necessarily straight forward. Hence
>>>>>>> the emphasis on distinct mapping relationships.
>>>>>>>
>>>>>>> Perhaps the editorial team could consider the appropriate order of the linking
>>>>>>> and mapping sections, whether more discussion on the rationale for mapping could
>>>>>>> be included, and whether some more guidance might be given on when to link and
>>>>>>> when to map.
>>>>>>>
>>>>>>> The linking example in section 3.1 brings up a currently somewhat problematic issue.
>>>>>>>   A new concept scheme can re-use existing concepts using the   
>>>>>>> skos:inScheme
>>>>>>> property. Consider the example below, where a reference concept scheme for
>>>>>>> animals defines a concept for "cats":
>>>>>>>   
>>>>>>>
>>>>>>> However there is nothing to prevent a new developer attaching their own new
>>>>>>> concept to someone else's existing SKOS scheme and thus changing the scheme (if
>>>>>>> the links are followed). It would be bad practice but as far as I understand is
>>>>>>> possible. (A slight modification of the example in 3.1 illustrates the point below.)
>>>>>>>
>>>>>>> I appreciate this is integral to the open world model and in the long run, it
>>>>>>> might be addressed by mechanisms of assigning provenance to RDF (sets of)
>>>>>>> statements, development of trusted vocabulary registries, caution when importing
>>>>>>> a SKOS vocabulary, etc. In the near future, I believe that the majority of
>>>>>>> applications will be effectively closed world, in that they will create an
>>>>>>> in-house index or database based on selected resources from the Web (including
>>>>>>> linked data publications). Perhaps the SKOS primer might also address more
>>>>>>> immediate concerns of how a vocabulary provider might make their vocabulary
>>>>>>> available. Is it possible to say something on how KOS developers might publish a
>>>>>>> vocabulary in SKOS, while asserting some practical form of ownership?
>>>>>>>
>>>>>>> Apdx
>>>>>>>
>>>>>>> Eg A slight modification of the example in 3.1 if I understand it correctly
>>>>>>> ============= alt example (undesirable?)
>>>>>>> ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
>>>>>>>    dc:title "Reference list of animals"@en.
>>>>>>> ex1:cats rdf:type skos:Concept;
>>>>>>>    skos:prefLabel "cats"@en;
>>>>>>>    skos:inScheme ex1:referenceAnimalScheme.
>>>>>>>
>>>>>>> The creator of another concept scheme devoted to cat descriptions can freely
>>>>>>> include the reference ex2:abyssinian concept in AN EXISTING scheme, and then
>>>>>>> reference it as follows:
>>>>>>>
>>>>>>> ex2:catScheme rdf:type skos:ConceptScheme;
>>>>>>>    dc:title "The Complete Cat Thesaurus"@en.
>>>>>>>
>>>>>>> ex1:cats skos:inScheme ex2:catScheme.
>>>>>>>
>>>>>>> ex2:abyssinian rdf:type skos:Concept;
>>>>>>>    skos:prefLabel "Abyssinian Cats"@en;
>>>>>>>    skos:broader ex1:cats;
>>>>>>>    skos:inScheme ex1:referenceAnimalScheme.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                   
>>>>>>>               
>>>>>>             
>>>>>>             
>>>>>         
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>   

Received on Thursday, 16 October 2008 10:30:25 UTC