Generic FIELD/PARAM metadata items in VOTable

Molinaro, Marco marco.molinaro at inaf.it
Fri May 19 10:20:29 CEST 2023


Hi Mark, Markus, all,

thanks for the useful and clean summary.

I was about to reply asking whether a mix of (2) and (3)
would be possible, because I too feel that that LINK
usage is not an obvious one.

I thus would favour the "META" element with the
suggested changes proposed by Markus, even if he
doesn't like them completely.

I'm wondering how or whether the key/value, or
property/content, would be advertised to the client
or documented.
Or would this be to allow custom or dedicated
server-client interaction only?

Cheers
    Marco

Il giorno ven 19 mag 2023 alle ore 09:08 Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> ha scritto:

> Hi Apps,
>
> On Wed, May 17, 2023 at 05:07:59PM +0100, Mark Taylor wrote:
> >    (1) Allow FIELD/PARAM to contain INFO children:
> >
> >         <FIELD name="healpix_id" datatype="int">
> >           <INFO name="healpix_order" value="8"/>
> >         </FIELD>
> >
> >    (2) Invent a new element for this purpose, say META:
> >
> >         <FIELD name="healpix_id" datatype="int">
> >           <META key="healpix_order" value="8"/>
> >         </FIELD>
> >
> >    (3) Use the existing LINK element using RDF to indicate semantics:
> >
> >         <FIELD name="healpix_id" datatype="int">
> >           <LINK action="rdf" content-role="#healpix_order" value="8"/>
> >         </FIELD>
> >
> [...]
> >
> > I think either of us could live with either solution.
> > Markus feel free to correct or clarify any of the above.
>
> I think Mark has nicely summarised the state of affairs, and yes, if
> someone else does the work I won't stand in the way of either of
> these proposals.
>
> Except... I hesitate to complicate the situation, but having somehow
> repressed the memories of that discussion, at the Bologna Interop I
> actually discussed "proper" RDF (that is, RDFa) in VOTable:
>
> https://wiki.ivoa.net/internal/IVOA/InterOpMay2023Semantics/rdfa-notes.pdf
>
> Given that, I'd suggest that *if* we create a new element as per
> META, let's at least make it RDFa-ready *in case* we'd ever want to
> go in that direction.  That is: literal values should go into the
> element content (if we *really* don't want that because it's not
> quite in line with the style of the rest of VOTable, then call the
> attribute @content rather than @value), and references would go into
> an @href attribute.  And we ought to use @property instead of @key.
>
> So:
>
>   <META property="healpix_order">8</META>
>
> or:
>
>   <META property="healpix_order" content="8"/>
>
> And then perhaps, as an illustration of using an RDF object:
>
>   <META property="
> https://www.ivoa.net/rdf/voresource/relationship_type#IsDerivedFrom"
>     href="ivo://cds.vizier/j/a+a/658/a167"
>     >Gobrecht et al: (Al2O3)n, n=1-10, clusters data</META>
>
> Note that that's not enough to produce the right RDF triples (because
> the subject will be wrong without doing something on the FIELD, and
> that's not pretty to do because of ID vs. id), but at least it won't
> build new barriers to RDFa in VOTable.
>
> Given my conclusion in the talk ("it's not low-hanging fruit, and the
> fruit's not terribly sweet either"), however, I think I'd still go
> for the (totally non-RDFa but otherwise nicely RDF-spirited) option (3).
>
>             -- Markus
>
> (who clearly is still struggling to let go of Semantics:-)
>


-- 
Marco Molinaro
INAF - Istituto Nazionale di AstroFisica
Osservatorio Astronomico di Trieste
email marco.molinaro at inaf.it
tel. [+39] 333 33 20 564 [also Telegram]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20230519/2b6651db/attachment-0001.htm>


More information about the apps mailing list