- From: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
- Date: Tue, 2 Dec 2008 10:04:08 +0000
- To: public-swd-wg@w3.org
I Have this response from Margie Hlava on ISSUE-146 but don't see her email in the public-swd-wg@w3.org archives, so am forwarding it there: ----- Forwarded message from Margie Hlava <mhlava@accessinn.com> ----- Date: Thu, 06 Nov 2008 09:28:23 -0700 To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>, Margie Hlava <mhlava@accessinn.com> From: Margie Hlava <mhlava@accessinn.com> Subject: Re: ISSUE-146: Last Call Comment: broadMatch and skos:narrowMatch ?should be used only when there are no exact or close matches for ?the term elsewhere? Cc: public-swd-wg@w3.org Dear Alistair, This is probably and appropriately a matter of semantics ;-) and emphasis Both of these comments reflect the same concern. In the thesaurus / taxonomy world the broader term narrower term relationship is key to creating a browse able classification, categorization or taxonomy. It seems like to say - "elsewhere" was not a serious bow to this feature and perhaps lead to other standards development to truly accommodate this need. I can certainly live with it. The question is should we and thereby encourage other groups to take the lead on this area? Margie Hlava At 02:24 AM 11/6/2008, Alistair Miles wrote: > Dear Margie, > > Thank you for you support and your helpful comments. In response to > your comment below: > > On Tue, Sep 30, 2008 at 12:00:44PM +0000, SWD Issue Tracker wrote: > > > > > > ISSUE-146: Last Call Comment: broadMatch and skos:narrowMatch should > be used only when there are no exact or close matches for the term > elsewhere? > > > > http://www.w3.org/2006/07/SWD/track/issues/146 > > > > Raised by: Alistair Miles > > On product: SKOS > > > > Raised by Margie Hlava in [1]: > > > > """ > > This is excellent work and generally a map can be made from a ANSI/NISO or > > a BSI or even and ISO thesaurus or controlled vocabulary standard to > SKOS. > > However there are still a few confusions which prevent one from insuring > > complete interoperability from one to another. This is represented by the > > section 10. Mapping Properties > > > > skos: broadMatch and skos:narrowMatch should be used only when there are > > no exact or close matches for the term elsewhere? > > Questions of best practice such as this are deemed out of scope for > the SKOS Reference. We hope that answers to questions such as this > will emerge in the future within the community of practice, in > response to implementation experience. We propose to make no change to > the SKOS Reference, can you live with this? > > > A taxonomic view of a thesaurus depends on the broader term narrower term > > relationships. To SKOS this is not as important as the synonym (also > known > > as equivalence) relationships. The parent child, genus species, broader > > narrower term designations allows browse-able or navigational search. > This > > technique has taken much of the information industry by storm for the > last > > couple of years. To allow this only as an after thought in SKOS is to > > marginalize an important area in findability. > > We believe the SKOS Reference makes no judgment as to the relative > importance of the different types of relationship. Can you live with > the document as-is? > > Kind regards, > > Alistair > Sean > > [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0055.html > > -- > 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 ----- End forwarded message ----- -- 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 Tuesday, 2 December 2008 10:04:47 UTC