How to choose?

[Ed Shaya]

Tony,
	I think you want two OWL ontologies.  One is full-OWL with skos 
annotations and the other is just SKOS.  The URI of the terms would 
differ only by a slight alteration in the namespace 
(http://www.ivoa.net/semantics/ontology/Astronomy.owl#Star and 
http://www.ivoa.net/semantics/skos/Astronomy.owl#Star).

	I also think that extracting the SKOS ontology from the full-OWL would 
work fine.  The full-OWL can be primary and, when it changes, one 
autogenerates the SKOS to keep them in sync. Within the full-OWL, I 
would suggest using subClassOf when approriate and narrowerThan when 
not, and one simply substitutes narrowerThan for subClassOf when one 
extracts for SKOS.    While you are at it, you can take any other 
relation between Classes and substitute skos:relatedTo.  If there is a 
pure skos tool that one wants to use, then one may need to do a final 
substitution of Concept for Class, at which point it is no longer OWL. 
Personally, I think this is throwing out the baby to drink the bath water.

The big payoffs here are an automated way to keep SKOS and OWL in sync 
and the ability to use OWL tools on both.  Also, I suspect the the 
SKOS-OWL committee that is ongoing at the W3C will find a way to make 
the final conversion out of OWL unnecessary.

Ed

Tony Linde wrote:
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eshaya.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20070927/2275b732/attachment-0001.vcf>