Mark (with a query for others at the bottom),
On 2006 Aug 1 , at 14.57, Mark Taylor wrote:
>> My thing was expressing some puzzled frustration that more folk
>> aren't using UCDs and UTYPEs. Taking advantage of the descriptions
>> they represent is certainly _my_ day-job, and inasmuch as it's
>> concerned with practical communication between applications, I can't
>> really explain why it's not part of other folks' day jobs, too.
>
> My 2p's worth is this: they are not widely used because it's difficult
> to use them in a way which makes your life easier or provides
> worthwhile
> additional functionality. Trying to make sense of UCDs that
> someone else may or may not have stuck on to columns or tables or
> groups or whatever requires something uncomfortably close to
> artificial intelligence.
This is very true, and there's little drive towards applications
because rather few folk use them. I think the last remark is very
true, but I think it's something _comfortably_ close to AI that you
need.
> You've got to decide whether you're looking
> at UCD1 or UCD1+, attempt to make sense of what a load of words
> separated by semicolons mean, decide whether, say, phot.mag.reddFree
> is an acceptable stand-in for phot.mag, think about whether you
> need to perform unit conversions for the quantity that you've
> identified to mean what you think it means...
> Worst of all, you can't rely on the UCDs being there, so if you
> really care about where to find RA and Dec, say, you're still
> realistically likely to be checking column names etc.
> IMHO UCDs sound like a good idea, but do not in fact provide
> machine-readable semantics in any very useful sense.
I will pin this user-story above my desk!
> Utypes are easier to work with, but I don't think(?) there are the
> public data models to derive them from. If you're communicating
> with yourself by reading utypes which you've just written,
> referencing your own data model, it may make sense to use them,
> but until/unless that data model is taken up more widely
> it doesn't really gain you much over just knowing the J mag is
> in column 4 because that's where you always write it.
You don't really need a big public data model (argh, that phrase
again) to get value from UTYPEs.
If you add UTYPEs to your published data, then you have at least
documented what you intend that data to mean, via a dereferencable
URL, whether or not any of the stuff I talk about below ever actually
happens.
If you or someone else declares that jach:jmag is a slightly more
specific type of iau:j-magnitude, and that both are associated with
UCD phot.mag.j:
jach:jmag a iau:j-magnitude.
iau:j-magnitude a [ hasUcd "phot.mag.j" ].
(perhaps at some well-known or easily-guessable URL in the archive
you're taking the data from), then it becomes possible for an
application to ask `here is a list of the UTYPEs I've got: are any
like 'phot.mag?', and `what UCD is UTYPE <X> most like?'.
Possible, that is, once I've written the service that does it. This
would not be hard to do (a couple of weeks work, I'd think). But
would that be useful to you? Are those the sort of questions you'd
want to ask?
It's also simultaneously both decentralised (the UTYPEs can be as
specific to the data provider as they wish) _and_ centralised (you
can agree or discover some consensus or popular UTYPE set and tie it
in).
Perhaps I should just go ahead and do this. Tim/Brad (or anyone
else): do you have a list of column names that you put in FITS/
VOTable files, plus summary documentation, that you could let me take
a look at?
Norman
--
------------------------------------------------------------------------
----
Norman Gray / http://nxg.me.uk
eurovotech.org / University of Leicester, UK
