W3C home > Mailing lists > Public > public-swd-wg@w3.org > October 2008

Re: ISSUE-164 draft response

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 14 Oct 2008 14:57:53 +0200
Message-ID: <48F49751.6050907@few.vu.nl>
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
CC: SWD WG <public-swd-wg@w3.org>

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?

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 Tuesday, 14 October 2008 12:58:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 October 2008 12:58:25 GMT