SKOS concepts in VOTable

[Frederic V. Hessman]

(blush) I hope I'm not holding things up by being stupid.

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.  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.  Or has "type" already be reserved by someone and, again, I'm being stupid?

As always, I'm sure Norman knows best - we just have to keep him on his toes by demanding that he convince us.  

Rick

On 31 May 2012, at 15:54, Norman Gray wrote:

> On 2012 May 28, at 10:54, Mark Taylor wrote:
> 
>>> Solution 3 :
>>> Use <LINK> subelements for <FIELD>.
>>> PROs : already allowed in VOTable 1.2. URIs can be expressed in href="".
>>> Possible to use content-type and content-role attributes to give additional
>>> context. Possible to have multiple <LINK> for one <FIELD>.
>>> CONs : not sure how parsers would handle this or how this can be used
>>> in TAP...
>> 
>> Since LINK is already present, and seems to be syntactically and
>> semantically capable of doing what's required here, it looks to me
>> like the best option.
> 
> This discussion has gone quiet -- perhaps this represents preliminary consensus.
> 
> Since VOTable 1.3 now appears to be on the cards, would it be useful for me to draft specific proposed replacement text for Section 3.5 (LINK Element) of the VOTable spec?
> 
> I would make basically the proposal in my email of 2012 May 28, unless Rick feels this doesn't adequately address his doubts.
> 
> A small extra thing occurred to me.  I would also suggest constraining link/@content-role elements to contain only roles described in the VOTable spec, with the exception of roles starting "x-", which can be prototyped freely.
> 
> I'll also suggest a @content-role value of 'seealso', which can point to any other documentation, machine- or human-readable, about the thing containing the link element.