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!