How to choose?

[Rob Seaman]

Hi Norman,

Thanks for the cogent reply.

> 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.

I have no horse in this race, but it sounds like they are circling  
the track at a respectable pace.

>> - 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.

I think it's the worst practices we're trying to avoid :-)

> 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.

For about half of the VOEvent community, notable speed is a  
significant requirement.  Since we don't know which packets will  
matter to which users in advance, this means that the servers and  
transport have to permit speedy handling, although purpose-built  
brokers, subscribers and components down stream might well have more  
intensive reasoning requirements.  What this says to me is that  
nothing about the VOEvent packet format can require intrinsically  
expensive timing overhead.

> It might be possible to do reasoning off-line, and 'compile'  
> material into something an application can use very rapidly indeed.

An interesting thought that might apply to our notion of per- 
subscriber filtering, for instance.

> 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.

Is this significantly different than how folks were hoping to use the  
SV?

>> - 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?).

Well, the VO uses services.  The services are often hosted by other  
institutions.  This brings great benefits, of course, that I won't  
belabor.  Presumably, the art and science of computer reasoning would  
also benefit from network services.  I'm not adverse to using such  
services, but they can't be allowed to block, for instance, and would  
benefit from failover and other such niceties.

> * 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.

Ok.  We just rolled in on the train, so an example isn't springing to  
mind, but this sounds helpful, i.e., some might subscribe to "give me  
all SN" and others to "give me all SN-Ia".  Of course, a lot of folks  
will really be subscribing to "give me all potential SN-Ia".

> * 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.

Classification is a great part of what our users will be doing.  The  
question is whether this needs to be built into the VOEvent brokers  
themselves.  And also, of course, whether our users want to use  
ontologies or rather their own custom algorithms, etc.

> 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.

This also sounds helpful in the sense that VOEvent can be regarded as  
a conversation among colleagues who are using a variety of  
collaborative/competitive strategies to discern the "truthiness" of  
the phenomena.  Tossing assertions back-and-forth to test them out is  
very much something we'll want to be doing in a few years.

Thanks!

- Rob