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

Re: ISSUE-164 draft response

From: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
Date: Wed, 15 Oct 2008 11:59:04 +0100
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: SWD WG <public-swd-wg@w3.org>
Message-ID: <20081015105904.GC22088@skiathos>

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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                   
>>>>>             
>>>>         
>>>
>>>     
>>
>>   
>
>

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993
Received on Wednesday, 15 October 2008 10:59:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 October 2008 10:59:43 GMT