DataLink RFC period annoucment

[Marco Molinaro]

Dear all,
my 2 cents on a couple of points only (from the Jose, Markus, Pierre list).

> > Page 16.
> > http://www.ivoa.net/rdf/datalink does not exist. 404
>
> In this case, a 404 is almost fine, as the URL really only defines a
> name space, and in this role there's not requirement it resolves to
> anything at all.  In our case, though, we promise there's an RDF file
> there that would let people figure out semantic relationships between
> the various terms that are there (e.g., a "flatfield" is some kind of
> "file used in data reduction").
> Things still work with the 404, but it'd suck if it were there at REC
> time.  So, is anyone actively working on getting the vocabulary in?
> Can we discuss it a bit, too?

Is this the same point on which you already asked
(or was François? someone else?) for contributions
in terms of which predicates this vocabulary should
contain as a minimum set? It was some time ago,
I don't remember properly.
I think we need it if we want client applications to
act smart upon links, leaving it totally free to the
providers can make this field quite useless.

Can we build on the existing ivoa.net/rdf existing
vocabularies?
E.g. the 'flatfield' example can fit the
obs.calib.flat at en UCD vocab concept?

(BTW: should the link of the vocabulary point to
http://www.ivoa.net/rdf/Vocabularies/vocabularies-YYYYMMDD/datalink
or maybe
http://www.ivoa.net/rdf/datalink/YYYYMMDD/datalink
or similar?)

> > Page 16. 3.2.8 content_length
> > I would use unit="Kbyte", much more practical and user-friendly.
>
> This is a protocol, and hence users will not usually see the raw
> table, and hence the unit chosen doesn't really matter; it's up to
> the clients to format and display this information, if at all.
> Except with Kbyte we wouldn't leave the realm of 32-bit integers
> quite as quickly.
> Which made me notice we don't define the type of content_length yet.
> I think we should at least make a recommendation.  My first choice
> would be "long", which in VOTable is a 64 bit integer, and
> unit="byte" will do fine then [quick: how many 2014 hard drives can
> you fill before VOTable longs warp over with the number of bytes
> stored?  Assuming one hard drive weighs 100g, express the mass of
> that storage cluster in solar masses].
> If people are worried about interoperability of such longs and were
> to advocate int, I'd say unit should be kbyte (decimal prefix) with
> commercial rounding or so.
> For float, it wouldn't really matter and I'd go for byte again.
> So, which would it be?

I'd vote for long/byte.
If we're to use kilobytes for the unit, however, we have to decide
between: kbyte and Kibyte, at least to follow VOUnits (since it's
a recommendation).

> 2) Technical questions: Concerning the second method (with the  PARAM
definitions by GROUP):
> The possibilities opened by this method is very promising. At the first
view, it seems simple and flexible, and very useful to build on the fly
associated user forms.
>
> a) However, I do not see how to describe REST links, or any URL for which
the prefix depends of the parameter values. May be I'm wrong, but it seems
that this method can only build URL on this template : http://static_url
_prefix?param1=val1&param2=val2...
> However, it is quite common that some servers provide their collections
on this basis URL template :
> http://host/variable_path/datasetID (VOSpace links ?). It would be great
if basis URLs could be also described by this datalink method.

I think this is a good point, and maybe it doesn't affect only Datalink,
query interfaces from most of the protocols work in the HTTP-GET way.
I don't see how this can be answered now, but maybe we can take it into
account for future revisions at a higher level than the simple protocol.

>
> b) Also, I did not find any thing concerning HTTP encoding requirements.
May be a short paragraph could avoid some stupid future bugs (param=val
must be correctly HTTP encoded..., the & character must be used as
parameter separator)

I'd limit it to recommending proper HTTP encoding, that should be
sufficient for HTTP GET requests ('&' is not the only possible separator,
';' can also be used for nested GET...I don't see where we can use this
latter case, but...)

> 3) My wish.
> In IVOA we use frequently VOTable as a container (SIA, SSA, TAP, ObsTAP,
and now Datalink), but without magic code or any signature to recognize
that this VOTable is a Datalink result, or a TAP result or whatever. And
concretely it is a nightmare for client which are supporting
 simultaneously several of these protocols. I recommend to introduce in our
VOTable protocols (at least the new protocols) a signature which could be a
simple INFO tag (ex: <INFO name="protocol" value="datalink1.0"/>).
>

I agree on this wish.
S*AP, TAP (e.g.) are interrogated and answer directly, but Datalink opens
up the scenario.
In principle a client will always be able to know in advance what type of
service it is querying (Datalink provides standardid),
but a specific signature can turn out to be useful.

Cheers,
     Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140718/64f4274b/attachment-0001.html>