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