SKOS concepts in VOTable

[Norman Gray]

Rick, hello.

An excellent point -- I'm maybe a little too close to this drum to hear it any more.

On 2012 May 31, at 16:49, Frederic V. Hessman wrote:

> I don't really like  content-role='type' in Norman's correction of my example, because the value "type" can mean anything and so will be used very everything and anything unless the VOTable schema/standard says otherwise.

You're right, 'type' can indeed mean just about anything, and that's why it's a good label for the relation; this is why I suggested (certainly not 'corrected'!) it.

When people associate UCDs with a column, or utypes, or (gawd 'elp us) xtypes, what they mean in all cases is 'type'.  In each cases the 'type' is a member of a different set of types, with different properties (the set of UCDs is very pragmatic, the utypes are 'pointers into a data model', and the xtypes are ... something else, and so on).  In each case the relationship between the VOTable column and the type is slightly different, but in a way that you actually care about only when wearing an ontology hat.

But doesn't this cause confusion?  No.  If I say that a column is a http://www.ivoa.net/rdf/Vocabularies/UCD#Poseqra or is a link to an http://purl.org/astronomy/vocab/DataObjectTypes/Image, then that's not confusable with me saying it's connected with http://www.ivoa.net/rdf/Vocabularies/AAkeys#Astrobiology, or that it has http://example.org/my/favourite/utype.  You can distinguish between these things either because your application 'knows' all of the types that (it recognises) it can do something with. Or you could retrieve the URL and find out more, if that was a useful thing for your application to do (though it probably wouldn't be in most currently obvious cases).

I'm mentioning UCDs here, not because I'm trying to hijack the existing references to UCDs in VOTable, but to illustrate that this generic/vague 'type' relation is not restricted to SKOS vocabularies (which is where we came in), but is future-proof -- there will be no need to add further attributes or roles in future.  Because an application will 'know' the details of any type it recognises, the @content-role='type' relation doesn't have to be restricted in the precise relationship between the thing annotated and the type annotation.

> If everything in the VO had a uniform semantic description (e.g. data models can also be described by a vocabulary which is just another semantic description, even though it's not officially so constructed) and "type" was reserved for this function, Norman's idea would be fine, but.....   What's so bad about reserving a particular content-role as being formally semantic?  I'm sure it would make programmer's jobs much simpler to know what they're supposed to be parsing.

My problem with the word 'semantic' is that essentially all of the content of a VOTable that isn't the <data>...</data> element is semantic.  Thus saying 'this is a semantic relation' is just saying 'this is a meaningful relation' (well, I'd have hoped so...).

In something like <PARAM name="Telescope" datatype="float" ucd="phys.size;instr.tel" unit="m" value="3.6"/>, there's some syntax in the XML rules, but @name, @datatype, @ucd, @unit and @value are all 'semantic' relations.

So it's not that it's _bad_ as such to use the S-word, just that it's redundant, and makes things look confusingly exotic.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK