IAU thesaurus in RDF (an update)

[Frederic V. Hessman]

Andrew Drake wrote:
> I don't know much about we are supposed to use UCDs with VOEvents
> but you seem to be missing all of the lensing ontology.
>
> lensing
> lensing_weak
> lensing_strong
> microlensing
> microlensing_caustic_crossing
> microlensing_cusp_crossing
> quasars_lensing

You're right - the IAU Thesaurus just had the generic terms  
"gravitational_lenses" and "microlensing".  "Gravitational_lensing"  
would be a better term since it's the process rather than an object  
which is important and the look-and-feel and "findability" of the  
tokens is similar (the SV hierarchical organization of our origianl  
proposal was a lot easier to deal with, as we expected, but.....)    
I'll change/add the following:

	"gravitational_lenses"	->	"gravitational_lensing"
	"microlensing"	->	"gravitational_microlensing"
	(NEW)	->	"planetary_microlensing"
	(NEW)	->	"quasar_microlensing"
	(NEW)	->	"strong_gravitational_lensing"
	(NEW)	->	"weak_gravitational_lensing"

Since terms like "cautic crossing" are generic to gravitational  
lensing, I'll add

	(NEW)	->	"caustics"
	(NEW)	->	"caustic_crossing"
	(NEW)	->	"cusps"
	(NEW)	->	"cusp_crossing"

> microlensing_binary_source
> microlensing_binary_lens
> microlensing_multiple_source
> microlensing_multiple_lenses
> microlensing_anomalous

Ugh - this is getting pretty detailed (see discussion of complexity  
later).  How about at least

	(NEW)	->	"gravitationally_lensed_sources"
	(NEW)	->	"gravitational_lenses"

The former is a good new broader term for things already present like  
"luminous_arcs" and "Einstein_rings".  While we're at it....

	(NEW)	->	"gravitational_lensing_shear"

The IAU thesaurus already has "anomalies" for generic unexpectedness.

> variable_stars_periodic

	Oops : there's "multi-periodic_variable_stars" but not  
"periodic_variable_stars".  Even Shobbrook^2 didn't think of  
everything classical.

> variable_stars_aperiodic

	There's "irregular_variable_stars" : is this "aperiodic" enough?  Is  
"semi-regular" to regular for "aperiodic"?

> asteroid_occultation

	(NEW)	->	"asteroid_occultations"
	(NEW)	->	"lunar_occultations"

> solar_eclipse
> lunar_eclipse

	Both exists already in exactly this form, but should be made plural  
(IAU thesaurus things are always plural if appropriate at all), just  
like "annular_eclipses".

	"solar_eclipse"	->	"solar_eclipses"
	"lunar_eclipse"	->	"lunar_eclipses"

> planetary_eclipse
> planetary_transit

	(NEW)	->	"planetary_eclipses", ALT "planetary transits"

> sun_spots (probably better seperate from starspots).

	No need: we've already got "sunspots".   A quick Google-survey  
indicates that "sunspots" is rarely written as "sun spots" (the  
latter are skin discolorings).  I suppose an ALT doesn't hurt.

> Perhaps most of these should be broken down into their actual  
> constituents rather than discribe types of events for actual UCDs.

There is/was a general feeling that the tokens shouldn't contain too  
much ontological baggage and the abandonment of any UCD-grammer (as  
originally proposed in the SV-document) means that the means of  
combining tokens has yet to be defined.  Thus, replacing something  
like the SV-like "microlensing_planetary" either means extended IAU- 
style normal phrases like

	(NEW)	->	planetary_microlensing"

or the assumption that - somewhere down the line - we'll decide how  
these tokens are to be combined, e.g.

	<rdf:Bag>
		<rdf:li resource="IAU:planets"/>
		<rdf:li resource="IAU:gravitational_lensing"/>
	</rdf:Bag>

(the equivalent N3 syntax would be.....?).   Once the semantics WG  
accepts the idea of IVOA-compatible vocabularies, it'll be time to  
move on to this topic - one which directly impacts other groups like  
VOEvent, since the ability to combine tokens to express information  
isn't an abstract ontological  exercise but a very down-to-earth need  
whose soltuion which should also be VO-wide if possible.

I think the RDF listings like that above is a reasonable and quite  
generically useful way of describing lists, sequences, etc.  Extended  
SKOS even offers NOT, AND, and OR (what does the N3 syntax suggest/ 
permit??).

Practically, I'd say we have to have too many tokens at first (so  
that we have tokens at all) but try to contain ourselves a bit and  
quickly decide how the IVOA wants us to combine them later.  The  
present IAU/IVOA list is already too large to be handled easily (see  
examples above where Andrew bravely went through the list and still  
didn't catch things which weren't missing after all).


Douglas Burke wrote:
>> Douglas implicitly raises a good point: the text file isn't much  
>> simpler than n3 and n3 is a lot less verbose than SKOS/OWL -  
>> should the IVOA suggest vocabularies are published in n3?
>
> I do much prefer to look at RDF/N3 rather than RDF/XML...

I certainly don't have any 'druthers about the format.  The advantage  
of N3 would be that it could replace the pure text format without  
much loss in human-readability.  On the other hand, I don't know if  
N3 is widely-enough accepted as an official format that the IVOA  
could simply stipulate using N3 as THE format for vocabularies.   A  
low buy-in cost for groups publishing their vocabularies sounds like  
a  good idea.  On the other hand, if the N3 syntax is too  
restrictive.....

> I have a question about the format of the identifiers used.
>
> If you look at the N3 form that cwm generates
>  - e.g. http://hea-www.harvard.edu/~dburke/playground/iau-djb.n3 -  
> then most terms are fine, in that they are represented as IAU:foo,  
> but we do find
>
> <http://www.Astro.physik.Uni-Goettingen.DE/~hessman/rdf/IAU#He 
> +_ionization_zone>
>
> which I guess comes about because of the "+" character. In itself  
> it's just ugly, and not a real issue, but I've come across cases  
> where certain parsers [*] didn't like the fragments to contain the  
> "." character, or start with a number, so I wonder if we should  
> take care in how we create the fragments, even if my reading of  
> http://gbiv.com/protocols/uri/rfc/rfc3986.html#collected-abnf is  
> that we can use these characters.
>
> [* whatever parser it is that longwell, http://simile.mit.edu/wiki/ 
> Longwell, uses]

Ugh - a pretty stupid contraint on token formats.  I rather liked the  
idea of using "_" to make the token effectively the same as the  
preferred label but this handiness will go away if we can't use other  
handy characters like "+" (let's not get into a unicode discussion).   
Otherwise, we'll need explicit computer-readable and human-readable  
tokens.  If the standard says we are allowed to use "+", then I vote  
for using it and notifying the parser-authors to fix their bug.


Ed Shaya wrote:
>> How about micro-OWLness as a start?  Again, if someone would tell  
>> me explicitly what OWL-ish entries you like......
>
> I don't understand what you are asking for here.  Property terms?

I meant that I didn't know enough OWL to know what different parts  
would be needed in a complete token entry ("complete" in the sense of  
containing all the information already present in the IAU thesaurus):  
all the ClassThis, subClassThat, and propertyBlah stuff.


Thanks to all again for their help.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman     Hessman at Astro.physik.Uni-Goettingen.DE
Institut für Astrophysik          Tel.  +49-551-39-5052
Friedrich-Hund-Platz 1         Fax +49-551-39-5043
37077 Goettingen                 Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
------------------------------------------------------------------------ 
-------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20071008/b6a32f42/attachment-0003.html>