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