IAU thesaurus in RDF (an update)

[Ed Shaya]

Frederic V. Hessman wrote:

>> I don't understand why there are so many TopConcepts, most of which 
>> have  many layers of broader things above it.
>> For instance _21_cm_line is a top concept, yet broader is 
>> radio_recombination_lines, broader is recombination_lines, broader is 
>> emission_lines, broader is specral_lines.  I would perhaps accept 
>> spectral_lines as a TopConcept.
> 
> Sorry - I just flushed all of the Concepts right through without 
> thinking about it (I'm interested in the tokens, not the 
> relationships).   It was no problem to throw out Concepts which are 
> somebody's NT, now reduced from 2790 (!!) to 991 (!).   Are 
> "TopConcepts" really so important?  I confess I stuck them in only 
> because Norman had in his documents and I could just as easily leave 
> them out.  Presumably, your OWL tools determine top-edness automatically.

This was not the response that I had anticipated.  I realized right 
after I sent the message that this looks just like an Index in the back 
of a text book with the topLevelConcepts being the top level.  For that 
purpose you might want a couple of hundred items at the top level.
I wsa then going to respond, OK, I see.  Useful for those (dreaded) humans.

> 
> Don't speak OWL, so If someone will suggest a complete and standard OWL 
> syntax for the entries, I'd be happy to automatically produce an OWL 
> version / include OWL elements as well, as appropriate.

Can you generate a version with the extended SKOS:
skos:broaderPartitive  (PartOf)
skos:broaderGeneric   (subClassOf)
skos:broaderInstantive (InstanceOf, ie the unique physical object like 
ZZ_Ceti, as opposed to ZZ_Ceti_star)
As mentioned here:
http://
isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/appextensions.html ?
We don't need narrowerPartitive etc, since that is redundant.

If so, then I can convert to a full blown OWL Ontology with 3 commands 
in vim. At this point it would be valid but missing the properties 
between PhysicalObjects and their Measurements.  This has to be done
manually, I suppose.

Then with a couple of button presses, I can split it into a bunch of 
reasonably sized namespaced files.  I was thinking most skos:broader 
items, like spectral_lines, could form separate namespaces.

So, we are talking now about having 3 versions, all meant to be official:
extended SKOS, SKOS/OWL (just add <owl></owl> and <import skos.owl/>), 
and OWL (where terms become classes). A script can be written to go from
the OWL to SKOS.  The other direction loses information.

Ed