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_multiple_lenses
> microlensing_binary_source
> microlensing_binary_lens
> microlensing_multiple_source
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-133http://www.Astro.physik.Uni-Goettingen.de/~hessman
http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2007-10-08Z11:52:40