Re: [lyo-dev] Ordered list handling in OSCL/RDF

["Jim Amsden" <jamsden@xxxxxxxxxx>]

See sh:order in https://www.w3.org/TR/shacl/


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Andrii Berezovskyi
<andriib@xxxxxx>
To:      
 "oslc-core@xxxxxxxxxxxxxxxxxxxx"
<oslc-core@xxxxxxxxxxxxxxxxxxxx>, "Lyo      
 project developer discussions" <lyo-dev@xxxxxxxxxxx>
Cc:      
 Leonid Mokrushin <leonid.mokrushin@xxxxxxxxxxxx>
Date:      
 07/07/2017 02:05 PM
Subject:    
   [lyo-dev] Ordered
list handling in OSCL/RDF
Sent by:    
   lyo-dev-bounces@xxxxxxxxxxx

---

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.

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev