Mime type for annotated data

[Patrick Dowler]

I have to second Mark's point about multiple model mappings...

The prior art in this area is DataLink, where the mime-type is
application/x-votable+xml;content=datalink and it means "the content
of the table is a DataLink links table". How right or wrong would that
be if there were multiple table resources and only one of them was the
links table?

For TAP (and other query services) we do not use the content parameter
to indicate "query result" because it adds no value. I can see how
having something to indicate that pivot mappings are included and (as
mentioned) to request that they be included via RESPONSEFORMAT would
be useful but I'm not sure if that's the best mechanism to do so.

My interpretation of RFC2045, specifically this BNF:

content := "Content-Type" ":" type "/" subtype
                *(";" parameter)

says one can add multiple parameters separated by semi-colon, so something like

application/x-votable+xml;content=datalink;content=mivot

appears to be a valid use and would re-use the content parameter to
indicate "includes MIVOT annotation".

That would seem to be sufficient to request MIVOT annotation and I
guess tells clients that are going to read the VOTable that they
should expect to find such content.

aside: we did conclude at some point that the VOTable spec, where the
mime-type is defined, should also define/specify allowed parameter
names but that looks like something for 1.6...
https://github.com/ivoa-std/VOTable/issues/26 ...

still, if I was prototyping something, I would start with
content=mivot and see if it's useful/sufficient/consistent. I know
that in our service implementations if a caller requests
RESPONSEFORMAT={something} we always make sure that exact mime-type is
in the content-type header of the output... so if someone queries with
RESPONSEFORMAT=application/x-votable+xml;content=mivot and our service
cannot map the QUERY to a data model, what would we do?
- respond with a different content-type than requested (but more "correct")?
- fail because we cannot provide content=mivot ??
- respond with the  requested mime-type but put an empty mapping
element in there??

my 2c,

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Thu, 5 Dec 2024 at 13:49, CresitelloDittmar, Mark via dm <dm at ivoa.net> wrote:
>
> Laurent,
>
> This is out of my wheelhouse so to speak, but..
> I'd be careful about #2 since there is the potential for the data to be mapped to more than one model.
>
> Mark
>
>
>
>
> On Thu, Dec 5, 2024 at 10:01 AM Laurent Michel via apps <apps at ivoa.net> wrote:
>>
>> Dear groups
>>
>> At the last interop, apps session, I showed a TAP service that annotates data with MIVOT, as long as you use
>>     FORMAT=application/mango.
>>
>> I was rightly told that this was probably the worst choice I could have made, even for a simple demonstrator.
>>
>> The question now is to construct a mime type, compatible with the RFCs and expressing the fact that the response to the request is a VOTable, whose data is mapped onto a model using the MIVOT syntax.
>>
>> I think the right solution is to use the parameters as defined in rfc2045
>>
>> There are two options:
>>
>> 1- say the data is annotated with MIVOT and let the client find out which model it is.
>>
>>     application/x-votable+xml;mapping=mivot
>>
>> 2- say the data is mapped to the MANGO model with MIVOT
>>
>>     application/x-votable+xml;mivot=mango
>>
>> This second solution highlights a particular model, but it may make sense for our use cases.
>>
>> Any suggestions or comments?
>>
>> All the best,
>>
>> Laurent