- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 14 Oct 2008 14:57:53 +0200
- 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 UTC