1. Oslc-Op
  2. Topics

LDM specification

David Honey2
 

Some further points about the POST to the oslc:queryBase that we might want to discuss in a future meeting:

  1. We might want to allow an LDM server to immediately return 202 Accepted rather than force the client to wait synchronously for a response. This is a standard HTTP pattern for long running operations. The response would include a Location header that provides a resource that a client can periodically poll to determine status and, on completion, the results.
  2. We should think about limits on number of inputs. Currently, LDX has enforced constraints on the number of target URIs and predicate URIs. A client that exceeds those limits will get an error response. An LDM server might impose similar limits. So, we should specify that the RDF returned might be an oslc:Error as per OSLC Core. If there are such limits, we might consider providing details as part of the LDM descriptor. This would allow clients to break the request into smaller chunks.
  3. We should think about limits on the number of results, and potential pagination. ILinkIndexService currently limits the number of results, but does not support pagination. For pagination, we should discuss whether this must be stable paging, or can be unstable paging. There are pros and cons for each. Standard OSLC paging won’t be suitable here.
  4. We need to think of other unhappy paths. For example, if the query times out, should the specification define how that should be handled, and the corresponding oslc:Error response?

 

Best regards,

David

 

From: oslc-op@... <oslc-op@...> On Behalf Of David Honey2 via lists.oasis-open-projects.org
Sent: 16 March 2023 16:30
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] LDM specification

 

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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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

 

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

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