How to choose?

[Tony Linde]

Not sure why I want all this to hang together, but one more attempt...

Can we still define all this in an ontology structure (using Protege or
POWL) but keeping the hierarchies separate? So we have ontological classes
vont:acceleration and vont:kinematics which each has vont:definedBy
relationships to vocab:acceleration and vocab:kinematics and we then relate
vocab:acceleration is skos:narrowerThan vocab:kinematics but do not define
any such subclass on the classes.

We then have the concepts and terms having different URIs and existing
within their own hierarchies (with multiple ontology and vocab hierarchies
as Bernard has indicated) but accessible from the same structure so that
vocab-based and ontology-based lookups can happen with the same object (and
across structures where appropriate). And if some app only wants to do
vocab-based lookups and the combined structures prove too slow, the SKOS
structures could be extracted easily.

T.

> -----Original Message-----
> From: owner-semantics at eso.org [mailto:owner-semantics at eso.org] On
> Behalf Of Norman Gray
> Sent: 26 September 2007 12:29
> To: semantics
> Subject: Re: How to choose?
> 
> 
> On 2007 Sep 25, at 09:04, Rob Seaman wrote:
> 
> > On Sep 24, 2007, at 2:08 PM, Tony Linde wrote:
> >
> >> It seems that more people, of those who are knowledgeable and
> >> care, prefer the SKOS approach.
> 
> I think it's not a case of `prefer SKOS in all cases', but `feel SKOS
> is a closer match to what's required' (Bernard has emphasised this
> quite strongly).  owl:Class and skos:Concept are not replaceable for
> each other, because the SKOS broader/narrower relationships are not
> at all replaceable for RDFS/OWL super-/sub-class relations.
> 
> For example, in the IAU Thesaurus, `acceleration' is a narrower term
> for `kinematics', but it makes no sense to say that `acceleration' is
> a subclass of `kinematics', in the sense that every instance of
> `acceleration' is also a `kinematics'.  Thesauri are originally
> `finding aids', and the relationship between a term and a narrower
> term is that everything retrieved by the narrower term would also be
> retrieved by the broader one.
> 
> Classification tasks (broadly interpreted) and finding tasks are
> rather different things, and different tools might be appropriate for
> them.
> 
> In the case of VOEvent (though we should remember that although this
> discussion is presently being driven by the VOEvent needs, it's not
> restricted to that), the place where the vocabulary term would be
> used is in the <why> element, indicating what the producer of the
> VOEvent packet thinks the relevant object may be.  What's supposed to
> happen next?  That's Rob's use-case, and will determine what tools
> will work best (see below).
> 
> > - What happens when the ontology evolves?  After all, we're talking
> > about methods for discovering and characterizing brand new phenomena.
> 
> People do care and write stuff about ontology maintainance, and while
> I don't believe there are any cast-iron best practices, there are a
> number of suggestions.
> 
> If I say that urn:myont-v2.0#concept1 is a subclass of urn:myont-
> v1.0#concept1, then you need only very lightweight reasoning to allow
> me to label something as v2.0#concept1, and you to discover that
> that's also a v1.0#concept1, which is the thing you understand.
> 
> > - How efficient are the tools of different kinds for applications
> > with split second timing requirements?
> 
> RDFS reasoners (limited to subClassOf, subPropertyOf, domain and
> range) are very fast.  OWL reasoners are slower, but it depends
> heavily on the implementation and on just what reasoning you
> require.  It might be possible to do reasoning off-line, and
> 'compile' material into something an application can use very rapidly
> indeed.
> 
> Using broader/narrower relationships I think you'd probably walk up
> and down the tree of concepts using your own code -- you wouldn't
> need to use a reasoner for this.
> 
> > - How robust are they against network or server outages?
> 
> There's no intrinsic need to have anything on the network.  Having
> things named by URIs doesn't mean that you have to dereference
> anything (was that what you had in mind?).
> 
> > - What can SKOS and OWL do for simple use cases?  For example:
> >
> > 	1) A high signal-to-noise optical transient is detected.
> >
> > 	2) A VOEvent packet is generated.
> >
> > 	3) Its discovery "signature" is compatible with a wide range of
> > possible underlying phenomena.
> >
> > 	4) Its brightness, location, rarity, etc., make it of interest to
> > several subscribers.
> >
> > 	5a) How do semantic technologies aid in the efficient and
> reliable
> > characterization of the phenomenon?  (http://
> > oaei.ontologymatching.org/2007)
> >
> > 	5b) What strategy is best used by the several subscribers to work
> > together compiling follow-up observations for the common good?
> 
> There are multiple things you could do here.  Two fairly well-
> separated examples:
> 
> * You could decide that you wanted to be sent any packets that appear
> which are relevant to 'b stars', and you might be sent everything
> labelled with one of 'b stars' narrower terms, or its broader terms,
> too.  This is a sort of finding application.
> 
> * If the event packet were to include information on brightness,
> location and so on, then you could ask 'is this deducible to be a
> member of the class X?', where that class might be defined as the set
> of things which have properties A and B, intersected with the
> complement of the set of things which have property C.  That's quite
> hard work, partly because that requires more reasoning, but mostly
> because defining and labelling concepts with that much precision
> takes a fair amount of people effort.  The CDS folk have done a lot
> of work on this with their astro ontology <http://www.ivoa.net/
> Documents/latest/AstrObjectOntology.html>, and Ed's astronmy ontology
> would I imagine be able to do similar work.
> 
> One of the features of RDF is that a triple store doesn't necessarily
> care where its triples come from, or what format they were converted
> from.  This has a number of implications, but amongst them that you
> can have one individual define a concept, another map it to second
> vocabulary, a third relate it to other terms, and so on.  You could
> potentially have a vocabulary defined or refined collaboratively,
> wiki-style, though whether this is a good idea is a separate question.
> 
> > - If this is not a well posed use case for differentiating between
> > our semantic software choices, then what would be?
> 
> It sounds well-posed to me.  Most of the uses of SKOS-type
> vocabularies are for finding things, broadly conceived (ie, including
> the filtering use described above), and would include browsing the
> registry and data sources.
> 
> 
> --
> ------------------------------------------------------------
> Norman Gray  :  http://nxg.me.uk
> eurovotech.org  :  University of Leicester, UK