[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[lyo-dev] Ordered list handling in OSCL/RDF
|
Hello,
We have a need to keep the order of some properties of one resource in our application. Say we have a Function resource which has multiple Argument resources linked. As you understand, the position of the function arguments is important.
We have evaluated a few approaches:
§1 Plain RDF list
In this approach, we make use of rdf:list https://www.w3.org/TR/rdf-schema/#ch_list.
Pros:
+ part of the spec (no idea why RDFS, though)
+ support in Turtle/JSON-LD and libraries such as Jena
+ extensions like Jena/Fuseki have SPARQL extensions for lists and efficient implementation that does not depend on the list length n.
Cons:
- range is a fixed rdfs:Resource (I know, that’s a different range, but that’s another discussion) and we can’t use OSLC Resource Shapes
- standard SPARQL support is cumbersome (e.g. it’s nontrivial to write a query that will find all Function resources which take a MyModel resource as an argument anywhere at any position) as well as any reasoning (“Note that using the rdf:List vocabulary in OWL would have put the ontology in OWL Full” https://www.w3.org/TR/swbp-n-aryRelations/#pattern2)
- violates the AAA principle because the list is linked.
§2 Custom literal predicate on the resource type
xsd:integer or another type that provides domain-specific ordering. In this case we say “:argX a Argument; mydomain:position “1”^^xsd:integer; mydomain:type xsd:double . ”. TRS followed this approach with the trs:order property.
Pros:
+ acceptable approach as long as the underlying resource type is semantically ordered
+ works well with SPARQL
Cons:
- position/order is not queryable in SPARQL w/o domain knowledge (i.e. query auther needs to understand which predicate provides ordering).
- client needs to sort the unordered list manually as there is no library support
- semantically wrong to use the predicate on the resources that do not have an innate ordering.
To give an example for the last point, in
def sin(x: double)
argument ‘x’ has order (semantically), while in the invocation:
sin(0.523598776) #30°
order is meaningless for the argument value itself, but has to be preserved, because the correct invocation depends on it.
§3 Custom literal predicate on a wrapper resource type
So for the last case from the example above we would define the ArgumentValue resource with two predicates:
* value
* position
so that we don’t have to add meaningless position to the ‘value’ resource type.
While this is still a correct approach and can be implemented on the most basic triplestores and RDF libraries, it is becoming a bit too complicated just to express order of resources (esp. if we would like to have a proper oslc:range on the value, we would need to create a wrapper type for each of those resource types that might need to be ordered).
I have left out reification because we most likely don’t want to use it to add important additional (important) meaning to the resources (also in line with https://www.w3.org/TR/swbp-n-aryRelations/#RDFReification).
In conclusion, I would like to hear how did you solve similar issues in your OSLC adaptors (or what the OSLC guidance shall be) and whether you think I shall use those linked lists from the RDF spec just because they are a standard or you think we could do better.
Also, are you aware of how new linked data efforts such as SHACL/ShEx and Linked Data Fragments may impact our choice (quick search did not turn up anything and I lack deep knowledge in those technologies to form an opinion).
Thank you in advance for you feedback and have a nice weekend!
–Andrew.