OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Ordered list handling in OSCL/RDF


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.


+ 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.


- 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.


+ acceptable approach as long as the underlying resource type is semantically ordered
+ works well with SPARQL


- 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!


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]