<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-ligatures:none;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-GB link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi,</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Another way of thinking about abstracting the meaning/functionality of various services is to think of the service as an API to manipulate and query an underlying data model – UWS is a data model of a job queue with an associated API. The IVOA already has a standard way of describing data models, namely VO-DML, which is why I put the link that I did on the P3T wiki page as a potential starting point for the formal description of service APIs as a step to formalizing the “schema” part of the openAPI specification of the interface – the VO-DML tooling already has a JSON serialization of the data models as well as an XML serialization.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>UWS is slightly unusual amongst IVOA protocols in that its response is not a VOTable – TAP obviously needs its main response to use a table data model, but there are other services – e.g. datalink where the response (especially in the case of templating and specifying parameters), where it is fairly unnatural to try to express the intention in a table model. There is a standard way (MIVOT) of expressing a data model in VOTable, but it does take quite a lot of parsing. Previous attempts to try to express the VOTable model in JSON have not been able to reach a satisfactory conclusion, but perhaps in some cases it might be a cleaner route to JSON to express the intended output in the “natural” data model rather than going via a tabular expression of that model.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There are some other aspects of DM use in IVOA – e.g. the same or similar concepts appearing in several models that would also benefit from some rationalization, but I think that is outside the remit of this group.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Paul.</p></div></body></html>