Date 1 - 1 of 1
|1 - 1 of 1|
Some points I want to make, but we ran out of time in the meeting…
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.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
|1 - 1 of 1|