- From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
- Date: Tue, 20 Nov 2007 17:25:40 -0000
- To: "Bill Bug" <wbug@ncmir.ucsd.edu>, "Daniel Rubin" <rubin@smi.stanford.edu>
- Cc: <public-swd-wg@w3.org>, <public-esw-thes@w3.org>
Hi Bill, Daniel, I don't know if this helps, but on the question of what "broader" and "narrower" mean, if pressed for a formal definition, I always give a purely operational interpretation. I explain what broader and narrower mean in terms of the reasonable operations of an information retrieval system which uses broader, narrower and other types of link between the units of an indexing language to improve search precision and/or recall. There are in fact a number of different operational interpretations, all of which are reasonable to a first approximation. Under the most naive interpretation, A skos:broader B means that, if some item X is relevant to a query for A, then it is also relevant to a query for B. In other words, if you query for B, and X has been "indexed" with A, then you can improve recall by including X in your result set, without loss of precision. This is exactly the interpretation that e.g. blogging software like wordpress uses, when you click on some category, and you get all posts tagged with that category or any child category. There are, of course, more fine-grained interpretations, which give each type of semantic relationship a different "weight", and take into account the "distance" between two concepts when calculating some estimate of relevance in an expanded search. This was in fact the subject of my MSc dissertation last year: [1] http://purl.org/net/retrieval -- although I tried to construct a single, complete framework to cover all operational interpretations, which can be overly complex for the simpler cases (plus I had only just learnt to use formal notation at the time :) You might also be interested to know that "graph-based reasoning", which is analogous to one or other of these operational interpretations I describe at [1], has been used in several software systems, see e.g. the Corese search engine from INRIA <http://www-sop.inria.fr/edelweiss/wiki/wakka.php?wiki=CoreseApplications>. Cheers, Alistair. -- Alistair Miles Research Associate Science and Technology Facilities Council Rutherford Appleton Laboratory Harwell Science and Innovation Campus Didcot Oxfordshire OX11 0QX United Kingdom Web: http://purl.org/net/aliman Email: a.j.miles@rl.ac.uk Tel: +44 (0)1235 445440 > -----Original Message----- > From: public-swd-wg-request@w3.org > [mailto:public-swd-wg-request@w3.org] On Behalf Of Bill Bug > Sent: 20 November 2007 16:47 > To: Daniel Rubin > Cc: public-swd-wg@w3.org > Subject: Re: questions on SKOS > > Sorry for the duplicate post, but there a few typos I missed > that can make the message below a bit unclear. > > Cheers, > Bill > > On Nov 20, 2007, at 10:34 AM, Daniel Rubin wrote: > > > Hello everyone, > > An interesting thread related to SKOS on another list. > Bill Bug posted some questions to which people on this list > might want to respond. > > Daniel > > > I may be taking too simple a view of this issue, but my > sense is the only part of SKOS that can be useful without > creating an overly complex graph of entailments that will > require a lot of custom logic are the annotation properties > they put in the original SKOS OWL file. > > Though we do eventually want to be able to trace > provenance on a declared synonymies, my sense is what we need > NOW are shared annotation properties used across all OBO > ontologies for things like "synonym", "abbreviation", "scope > note", "history note", "definition", "OBO definition" - just > to avoid the babel of home-grown annotation properties that > will each necessitate creating and maintaining custom logic > (or annotation property maps) in order to process. This is > the simple objective I'd hoped SKOS would adopt first, before > leaping to the more complex objective of providing a shared > framework to support expressing logical entailments related > to "acts of speech". > > Am I'm being too facile in thinking such a shared set > of lexically-oriented annotation properties - opaque to the > DIG reasoners - would be of use to OBI and the broader > community. Should we not expect this to come from SKOS, or > should we all simply use (or extend) the annotation > properties that come with OBOinOWL? > > Cheers, > Bill > > On Nov 19, 2007, at 6:07 PM, Chris Mungall wrote: > > > > I think the broader/narrower/exact type > relations are potentially > useful for encoding the relation between a > universal and a linguistic > unit. e.g. synonyms in obo format. I'm not sure > to what extent this > is overloading SKOS. > > On Nov 19, 2007, at 12:37 PM, Alan Ruttenberg wrote: > > > I guess my basic question is, what does > the broader / narrower > relationships mean? "Broader concepts > are typically rendered as > parents in a concept hierarchy" Do you > have any better way to think > about them than "the relationship to > use instead of using superclass > properly, if you are in a rush"? > > -Alan > > > > > William Bug, M.S., M.Phil. > email: wbug@ncmir.ucsd.edu > Ontological Engineer (Programmer Analyst III) work: (610) > 457-0443 Biomedical Informatics Research Network (BIRN) and > National Center for Microscopy & Imaging Research (NCMIR) > Dept. of Neuroscience, School of Medicine University of > California, San Diego 9500 Gilman Drive La Jolla, CA 92093 > > Please note my email has recently changed > > >
Received on Tuesday, 20 November 2007 17:25:54 UTC