How to choose?

[Norman Gray]

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