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: Re: [oslc-core] Ordered list handling in OSCL/RDF

In general, our recommendation has been to avoid (but not prohibit) use of RDF collections (list, bag, and sequence).

For ordering, we generally recommend one of the other two approaches you have suggested:
  1. First, if possible and appropriate, allow the client to order resources using some natural property of those resources. For example, we do not express ordering in the relationships between change requests, or between test cases and requirements. Rather, we allow clients to order the targets of such links using some property of those target resources, such as change request severity and number.
  2. If the above is not appropriate, create an intermediary resource with an ordering property. For example, we did that in the Configuration Management specification with the contributions to a global configuration. In that case, it was not appropriate to add an ordinal number to the configuration, since a single configuration could contribute to different configurations in different orders. Instead, we created an intermediary Contributions resource, and placed the ordering property in that.


From:        Andrii Berezovskyi <andriib@kth.se>
To:        "oslc-core@lists.oasis-open.org" <oslc-core@lists.oasis-open.org>, "Lyo project developer discussions" <lyo-dev@eclipse.org>
Cc:        Leonid Mokrushin <leonid.mokrushin@ericsson.com>
Date:        07/07/2017 11:05 AM
Subject:        [oslc-core] Ordered list handling in OSCL/RDF
Sent by:        <oslc-core@lists.oasis-open.org>


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


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

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]