[OSLCCORE-171] TRS base member predicate may introduce incompatibilities with TRS 1.0 - OASIS Technical Committees Issue Tracker

Details

Type: Bug
Status: Open
Priority: Major
Resolution: Unresolved
Component/s: TRS
Labels:
None

Proposal:

Hide

Backward compatibility may be more important than precise use of LDP in the TRS specification. There is no problem using ldp:Container instead of ldp:DirectContainer. ldp:Container uses ldp:member as its predicate, and it seems reasonable enough for the TRS specification to specify MUST for rdfs:member, its more general super property.

ldp:DirectContainer is not really necessary for TRS because there's no need for the TRS base resource to have a domain vocabulary specific membership predicate, after all we are defining the TRS vocabulary and should have a fixed property for base members. There's no need to have this be variable, it doesn't add any capability and the variability would introduce complexity and interoperability problems.

So I propose we specify the range for trs:base be ldp:Container, and the membership predicate MUST be rdfs:member. This is compatible with LDP and TRS 1.0 as well as the Lyo oslc-trs implementation and does all that the TRS spec needs.

Show
Backward compatibility may be more important than precise use of LDP in the TRS specification. There is no problem using ldp:Container instead of ldp:DirectContainer. ldp:Container uses ldp:member as its predicate, and it seems reasonable enough for the TRS specification to specify MUST for rdfs:member, its more general super property. ldp:DirectContainer is not really necessary for TRS because there's no need for the TRS base resource to have a domain vocabulary specific membership predicate, after all we are defining the TRS vocabulary and should have a fixed property for base members. There's no need to have this be variable, it doesn't add any capability and the variability would introduce complexity and interoperability problems. So I propose we specify the range for trs:base be ldp:Container, and the membership predicate MUST be rdfs:member. This is compatible with LDP and TRS 1.0 as well as the Lyo oslc-trs implementation and does all that the TRS spec needs.

Description

The TRS 1.0 specification did not define a trs:Base class, but rather referred to the object of a trs:base predicate as an "RDF container". The Base Resources does not specify and rdf:type for the base resource. The members of this RDF container are captured using rdfs:member predicates.

TRS 2.0 also does not define a trs;Base class, it also refers to the Base resource as the target of the trs:base predicate whose range is specified to be ldp:DirectContainer. The TRS 2.0 spec does define some properties of this unspecified resource type, so when I created the resource shapes for TRS 3.0, I added a trs:Base resource shape that oslc:describes ldp:DirectContainer in order to formerly reflect what was in the 2.0 specification.

It is not clear what TRS 1.0 implementations exist, but any TRS implementations done using eclipse/Lyo oslc-trs as a reference implementation may not be entirely compatible with TRS 2.0 as specified. It appears oslc-trs does utilize LDP, but it sues ldp:Container, not ldp:DirectContainer (a subclass), and uses rdfs:member, not ldp:member (ldp:member is a subPropertyOf rdfs:member). A TRS provider I recently implemented (https://github.com/OSLC/iotp-adaptor) using oslc-trs does produce ldp:Container with rdfs:member, and this base is consumed without any problem by IBM LQE.

So it appears we have a mixture of container and member specifications that we may need to maintain for backward compatibility.

TRS base member predicate may introduce incompatibilities with TRS 1.0

Details

Description

Attachments

Activity

People

Dates