[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]