[msdemlei at ari.uni-heidelberg.de: Preview UCD?]

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Mar 23 11:20:40 CET 2017


Dear Semantics,

a couple of years ago I posted the below message over this list
(http://mail.ivoa.net/pipermail/semantics/2014-October/002477.html),
which back then elicted little feedback.

In discussions with the Aladin team during the current Asteric Tech
Forum, quite similar requirements surfaced -- they would, for
instance, like to identify URLs in VOTables as, say, datalink.

That particular use case wouldn't be covered by the proposal to
re-use the datalink semantics vocabulary, though, since that doesn't
contain "datalink" as a term, and I don't think it should be there.
It is a bit different: "preview" is a generic term, "datalink"
references a VO standard.

Now, I still think it would really help clients to have a better idea
what's at the end of a link they encounter in a VOTable, and over the
2014 mail I'd say there are two different, not really related cases:

(1) What's at the end of a link?
(2) What ("high-level") standard does it conform to (i.e., datalink,
    SSA response, etc)?

My current impression is that (2) always implies (1).  So, I'd hope
we can still get by with introducing a couple of secondary UCDs and
have just one qualification of meta.ref.url.  Examples would include

meta.ref.url;meta.type.preview
meta.ref.url;meta.type.datalink

(or perhaps "data" instead of "meta.type"?)

So -- what do people think about this?  Is UCD the right tool to use?
If not, what would be?  Does anyone else think this is even a
problem?

      -- Markus


----- Forwarded message from Markus Demleitner <msdemlei at ari.uni-heidelberg.de> -----

Date: Wed, 8 Oct 2014 11:18:14 -0600
From: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
To: semantics at ivoa.net
Subject: Preview UCD?

Dear Semantics WG,

I'd like to add columns containing previews to my "product" tables
(i.e., for SSAP, SIAP, ObsCore), and I'm looking for an easy way to
convey their location to clients, ideally independent of the actual
protocol.

After a very short deliberation, I decided that having a UCD for
previews would be the simplest way to do that.  This could be
meta.preview or maybe even meta.ref.url;meta.preview.

In conversations with Sebastién and Mireille we realised that doing
such a thing raises the question if we shouldn't use the opportunity
to allow more specific metadata to be conveyed on meta.ref.url in
other cases, too -- e.g., there's a case to be made that clients
should be able to tell an accref apart from a service access URL
based the UCD of the element it's encountered in.

At that point I realised that this path of thought leads to what we
are currently producing in datalink, where there's an "official"
vocabulary for kinds of data products (a source is at
http://volute.googlecode.com/svn/trunk/projects/dal/DataLink/datalink-terms/src/datalink-terms.csv;
this exists in some RDF serialisation somewhere, too).

And then the question is if that vocabulary couldn't be leveraged for
a fine-grained description of meta.ref.url, maybe by defining a data
hierarchy that would have terms from that vocabulary.  My preview UCD
would then be meta.ref.url;data.preview, say.

So -- what do people think?  Is preview a special enough case to just
add meta.preview?  Is the utility of being able to say what kind of
product a table column links to big enough to try the inclusion of a
UCD-external vocabulary?  Is there another UCD-based way to do what I
want?  Or would this be a case for annotation based on LINK?

Cheers,

        Markus

----- End forwarded message -----

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


More information about the semantics mailing list