SKOS concepts in VOTable

[Brian Thomas]

Hi All,

Sorry to chime in at this late point in the discussion. I guess I don't
understand why we need to invent something completely new to
handle this situation. {apologies if someone already suggested the
following and it was deemed unacceptable}

Why aren't we considering simply importing parts of the RDF standard
into VOTable schema? What about the "rdf:about" attribute into the
VOTable standard? This would be unambigious in use (the rest of the
world already defines and understands it), it could be made to allow for
multiple semantic urls to be declared and it would conform to an existing
standard and would be compatible with SKOS, as well as other forms of
RDF like owl and because its namespaced, it would be trivial for downstream
parsers to simply ignore it.

For example

<VOTable xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    ...
 >
...
<field name="gal_type" 
rdf:about="http://www.ivoa.net/astroobjects.rdf/#galaxy-morphological-type" 
../>
..
</VOTable>


Going further afield..I can see a case for allowing an import of 
"rdf:Description" elements as children
as well and allowing the whole parts of an rdf document to be imported. 
For example,


<VOTable xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:tsc="http://www.ivoa.net/time_space_coordinate_defs.owl#"
 >
    ...
<field name="coordinate_system" ..>
<rdf:Description rdf:about="tcs:sky_coordinates">
<tsc:epoch rdf:resource="tcs:J2000#"/>
</rdf:Description>
    ...
</field>
 >
...
</VOTable>


Granted, that the last example is more challenging to for the machine to 
parse
and grok...and we already have a time space coordinate definition, but
you get the idea.

My 2 cents,

-brian


On 06/01/2012 08:24 AM, Norman Gray wrote:
> Mark and all, hello.
>
> On 2012 May 31, at 23:15, Mark Taylor wrote:
>
>> >  On Thu, 31 May 2012, 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?
>> >  
>> >  An alternative approach is to address this in some place other than
>> >  the VOTable standard, for instance the relevant Theory or Semantics
>> >  or DM standard could prescribe that VOTables used in a particular
>> >  context should use the LINK attribute, and in particular its
>> >  content-role attribute, in such and such a way.