This class is the base class of Stored Trace and Computed Trace. It has no direct instances (only the two subclasses above can be instantiated), but everything described here is valid for any indirect instance.
Traces have one aspect resource:
- @obsels, linked through http://liris.cnrs.fr/silex/2009/ktbs#hasObselCollection
Retrieve the description of the trace, augmented with the following generated properties:
- http://liris.cnrs.fr/silex/2009/ktbs#compliesWithModel can be either “yes”, “no” or “?” (if the model is not available)
- links to the @obsel aspect resource.
This allows to change the description of the trace itself.
Deletes the trace and its aspect resources.
TODO: what happens if the trace is the source of a computed trace?
This aspect resource stands for the obsel collection of the trace.
Return the description of all the obsels of the trace. This description can be filtered by passing the following query-string arguments:
after: an obsel URI, only obsels after this one will be returned before: an obsel URI, only obsels before this one will be returned limit: an int, only that many obsels (at most) will be returned minb: an int, the minimum begin value for returned obsels mine: an int, the minimum end value for returned obsels maxb: an int, the maximum begin value for returned obsels maxe: an int, the maximum end value for returned obsels offset: an int, skip that many obsels reverse: a boolean, reverse the order (see below)
For example http://localhost:8001/base1/t01/@obsels?minb=42&maxe=101 will return only those obsel beginning at or after 42 and ending at or before 101.
Some of these parameters
rely on the Obsel total ordering.
@obsels?limit=10 will return the first ten obsels,
@obsels?reverse&limit=10 will return the last ten obsels.
Remember however that most RDF serializations have no notion of order
(they convey a set of triples)
so the representation of those resources may appear unordered.
The JSON-LD serializer in kTBS is a notable exception:
the obsel list is sorted according to the obsel ordering.
Even with unordered serializations, however,
this still allows to retrieve obsels of a big trace in a paginated fashion,
limit to specify the size of the page,
after to browse from one page to another
(setting its value to the latest obsel of the previous page),
before when paginating in the
To make it easier,
kTBS provides a
next Link HTTP header (per RFC 5988)
pointing to the next page.
Obsels with a complex structure (see below)
may not be entirely described in the representations of
More precisely, all attributes (i.e. outgoing properties) of obsels,
and all inter-obsel relations will always be represented.
However, if an attribute has a complex value,
represented as a blank node with its own properties,
then the representations of
will usually truncate such property paths to a length of 3.
This limitation has been introduced to ensure good performances, and is deemed acceptable as obsels typically have a flat structure (depth of 1), and occasionnally a depth of 2. In order to get the full description of an obsel, you can of course still get it from the obsel URI.
Also, note that transformation methods sill have access to the whole structure of obsels
This method can be used to modify the obsels of a trace. Be aware that kTBS performs absolutely no control on the put graph, so this is at your own risks.
This method deletes the obsel collection, and with it all the obsels of the trace.
Note that a trace must always have an obsel collection, so a new (empty) one will immediately be created. Hence, this method can be thought of as simply deleting all obsels, and leaving the obsel collection resource intact.
|||The value is case insensitive,
and any value different from |
|||You may retrieve longer paths in some situations, but this should not be relied upon.|