Datalink vocabulary additions

[Markus Demleitner]

Dear Semantics,

[cc: DAL, but followups should, I think, go to Semantics]

At the Sydney Semantics Session
(http://wiki.ivoa.net/twiki/bin/view/IVOA/InteropOct2014Semantics) I
had a little talk on the maintenance of the vocabulary for the
annotation of rows in datalink responses (notes at
http://wiki.ivoa.net/internal/IVOA/InteropOct2014Semantics/datalinkvoc.pdf).

It was agreed in that session that maintenance of the vocabulary
should, for now, be the Semantics chair's responsibility (hence my
preference for the semantics list for discussions).

I had furthermore promised to send a mail proposing some new concepts
I'd like to see included, together with proposals for terms to use
for them, over the Semantics mailing list, where hopefully a lively
and constructive debate would ensue resulting in proper and precise
definitions and good terms.

Well, here goes, as far as the mail is concerned.


Concepts (and proposed terms) for inclusion into the datalink
vocabulary


(1) Larger chunks of metadata in separate files.  I'd need that to
link to observation logs, but I could see logs a pipeline has
written, or an extensive provenance, or similar.

Proposed term(s): #metadata?  #documentation?


(2) Things like a rebinned (higher S/N) version of the dataset, or
perhaps the data in a different waveband on a multi-band instrument,
or the same observation with a different instrument setup (as in V500
vs.  V1200 in Califa), etc.  Essentially: Science data that was
obtained "together with" #this but that's not identical with #this.

Proposed term(s): #science? (but that's a bit too broad)  #alternate?


(3) Different representation of the same dataset, e.g., a spectrum
that was originally a FITS image formatted  as a FITS table, an SDM
VOTable, or a CSV file (where of course the SDM VOTable would be the
#this).  Essentially, the same data as #this modulo the different
expressivenesses of container formats.

Proposed term(s): #alt-format?


(4) Something went wrong when generating this link.  This I'm not
quite convinced of any more myself.  I came across needing something
like this because in DaCHS, when generating links, I'm doing
what boils down to:

  try:
    <operator-provided code>
  except Exception, msg:
    add_datalink_row(pub_DID, error_message="Fault: Something went wrong:
      %s"%msg, semantics="#fault")

-- so, essentially I know that something went wrong when generating a
datalink, but I don't really know what.  Pat has correctly pointed
out that it's far preferable to just keep the semantics that the link
would have had if the generation hadn't failed.  I largely agree with
this; the situation DaCHS has here, having to execute essentially
unknown code in the row generation and  thus now knowing what
semantics the link would have had, is perhaps so exotic that a local,
custom term is enough.  Hm.

Proposed term(s): #fault?


That concludes the proposed concepts.  One other thing I'd like:

#proc currently has "Server-side data processing result" as its
explanation.  What really is in such datalink rows is, I submit,
better described by "reference to a server-side processing service"
-- so, can we change that explanation?

Opinions?  Proposals for sharper descriptions, better terms?  Any
contributions are welcome.

Thanks,

         Markus