Specification Problems

vocab URL

Section 2.3 "Examples: DALI-examples" proposes to use ivo://ivoa.net/std/DALI#examples as the default vocabulary URL. That is unfortunate as the actual terms in RDFa are generated through concatenation, such that the terms that would actually end up in the StandardsRegExt document (not that they're actually there) would look like "examplesname", "examplescapability", etc.

Possible solutions:

(1) We could keep the notion that we're using StandardsRegExt records to keep the examples vocabulary. In that case we would IMHO have a document separate from DALI's, which would mean we should write an erratum saying the vocab URL should be ivo://ivoa.net/std/DALI-examples#. This is (essentially) what's in the TAP Implementation Notes right now.

(2) After the (positive) datalink experience with RDF-enabled vocabularies and because there's no (known) code using this anyway so far, my personal take is that we shouldn't use StandardsRegExt for that in the first place. Vocab URIs, if they resolve at all, should resolve to something that RDF tools can do something with, and hence I'd say we should write an erratum saying the default vocab URI would be http://www.ivoa.net/rdf/examples (which is in parallel to what we have in datalink now).

As we don't really expect our tools to evaluate vocab, all this is IMHO less dramatic than it sounds. -- MarkusDemleitner - 2015-05-11

Suggested Extensions

DALI"> more datatype formats in DALI

There is already a section with specific rules for the format of data values for numbers and timestamps. I propose this be extended to include the basic geometric values we know we need in TAP, SIA, etc: point, circle, polygon, and interval (1D numeric interval). Having messed with this from every angle, the cleanest approach for these is to only encode values as an array of numbers as this most usable in the places we need to use such values: ADQL queries, parameter values, query results (eg VOTable value).

We do not have an STC-S standard, TAP-1.0 simply provides some non-normative recommended syntax, and we agreed as far back as the Hawaii interop that metadata (eg coordsys, epoch, etc) doesn't belong in the values. But we do need to provide values and I think this is the best approach below.

point

votable: datatype="double" arraysize="2" unit="deg" xtype="point"

votable value: 1.2 3.4

ADQL: POINT(1.2, 3.4)

circle

votable: datatype="double" arraysize="3" unit="deg" xtype="circle"

votable value: 1.2 3.4 0.5

ADQL: CIRCLE(1.2, 3.4, 0.5)

polygon

votable: datatype="double" arraysize="*" unit="deg" xtype="polygon"

votable value: 1.2 3.4 1.3 3.4 1.3 3.5 1.2 3.5

ADQL: POLYGON(1.2, 3.4, 1.3, 3.4, 1.3, 3.5, 1.2, 3.5)

interval

votable: datatype="double" arraysize="*" xtype="interval" (useful with various units, but for me: d or m)

votable value: 54321.0 54321.5

ADQL: INTERVAL(54321.0, 54321.5)

The arraysize="*" here is because in practice we have intervals with sub-intervals (start stop start stop ...) that we want to convey, corresponding to the energy or time bounds of observations. In the example above it could be 2, but in general output from our services could be some large even number of values.

The ADQL equivalent is just there to show what the same design principle looks like there and hopefully we can do this in ADQL_Next.

-- PatrickDowler - 2015-05-14

Have you thought about (representing) half-open intervals? Also: Presumably the interval xtype would be applicable to real values, too -- what about the various integer types (these are an extra challenge with half-open intervals as we don't have a default NULL literal from them, so without a proper declaration you coulnd't tell up-to from starting-at intervals? What about chars? Also, I'd advocate that we make very clear that there are no string intervals (proto-PQL as in SSAP hasn't always been that clear) -- MarkusDemleitner - 2015-05-15