OSLC - Is there a way to get an artifact and retrieve all display values as well?
I am retrieving elements such as work items. I get data back. The data is primitive like the description, and easy to access. The data is complex such as an enumeration in this case I have to do additional requests to get the display value for the enumeration literal.
I am working with a team that has a stateless approach to their connectors. There is a concern that the bandwidth needed to get all the data, including display values for enumerations, categories, etc. is creating too much traffic to be efficient.
I think that is just how OSLC is, so my question to the OSLC gurus, is this how it is, or is there a way to get more data back in one go?
2 answers
From an OSLC perspective, a resource that has one or more enumerated property values has an RDF statement for each such value, referencing the URI of each enumeration member. It's good practice for the resource to reference an OSLC instance resource shape. A resource shape should define the allowed values for an enumerated OSLC property, but these just reference the URIs of those enumeration members. The enumeration members themselves typically have statements such as rdfs:label or dcterms:title to provide the name ofeach member. However, from an OSLC aspect, those statements can be in any RDF graph. Some applications may include those statements in the graph of the resource shape for convenience of OSLC clients, but in general, clients may have to perform a GET on the enumeration member URI to see statements against that subject. Some enumeration members might be defined in static vocabularies provided outside of any tool. This is just the way that OSLC, and linked data, is.
Report Builder (part of JRS) builds a type system model that covers enumeration values by querying LQE. That type system model can then serve the RB UI when it wants to show the user a list of allowed values for some meta property. The type system model is typically auto-refreshed every 12 hours.
I suspect to reduce the frequency of having to get enumeration members, the application/adapter will have to perform some form of caching. The labels for enumerations tend to to change often, so having a time-limited cache of labels for enumeration member URIs would avoid having to perform HTTP GETs each time a label was required.
Comments
Ian Barnard
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 08 '21, 12:56 p.m.Basically yes that's how it is - but by caching at least for the duration of a run, or perhaps for e.g. 1 or 2 days with the ability to force a flush of the cache, you can reduce repeated requests to the server. For DOORS Next I've played around with a http cache in front of the server and you have to be careful that the configuration (i.e. everything that might vary the result) is included in the URL because at least the HTTP caching library I tried doesn't consider headers and if the configuration varies and it's in a header the cache won't see these as different requests and will incorrectly (from your perspective, correctly from its) return the cached data for a different config. Once I'd been bitten by that and added the config URI to the URL (as well as the header) it worked well to reduce traffic significantly.
1 vote
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 08 '21, 2:26 p.m.Thanks Ian, I thought about contacting you directly, but then I though having it here as it is would be more beneficial.