Some points I want to make, but we ran out of time in the meeting…

Regarding the data returned from a GET of an LDM descriptor. That should be RDF, and the requestor should be able to ask for standard RDF mime types, such as text/turtle, or application/rdf+xml. The request should use standard HTTP cotent negotiation mechanisms such as an Accept header, to specify the RDF mime types it would like. We should define an OSLC resource shape for that descriptor. That might include standard core properties such as dcterms:title, and oslc:queryBase. We should use standard DCMI and OSLC vocabulary terms whenever possible. I think we should keep the descriptor small. A client that is only interested in finding the oslc:queryBase should not be burdened with handling  a huge response body for the descriptor.

If there is additional meta data about the scope of data available/indexed in that LDM server, that should be provided through additional endpoint URIs discovered from the descriptor  and not returned inline in the descriptor. That also allows us to define resource shape(s) for such data once we’ve decided what might be useful. I think we should discuss use cases and let those drive what meta data might be needed to support them.

OSLC currently does not use JSON schemas. Although it recommends that JSON-LD is supported, this is really a JSON representation of an RDF schema. So for the POST to the oslc:queryBase of an LDM server, I think it preferable to use a body that is of mime type application/x-www-form-urlencoded. This is a standard HTTP pattern for requests with a large number of HTTP parameters and/or lengthy parameter values that would otherwise result in a URI that exceeded server limitations. This avoids the need to invent a JSON schema or RDF vocabulary. It’s consistent with what we currently do elsewhere in OSLC. The specification would just have to define the names of the parameters and their meaning. The response to the LDM oslc:queryBase request should be RDF. The request should use standard HTTP content negotiation as per OSLC Core.

Best regards,

David