Re: Comments on March 2014 of draft of LDP

Here is a small insight from experience implementing the LDP spec. The 
spec currently has these 2 predicates:

LDP+'hasMemberRelation'
LDP+'isMemberOfRelation'

This combination is quite tedious to program to. In many cases, you need 
to know what the membership predicate is, but you don't (at that 
particular point) need to know whether the members are the subject ot the 
object of the triples. This leads to a lot of code of the form

membershipPredicate = container.get(LDP+'hasMemberRelation') ? 
container.get(LDP+'hasMemberRelation') : 
container.get(LDP+'isMemberOfRelation')  // Javascript

or if you are a Python programmer

membershipPredicate = container.get(LDP+'hasMemberRelation') if 
container.get(LDP+'hasMemberRelation') else 
container.get(LDP+'isMemberOfRelation')  // Python

There are multiple reasons to write this code, but one very common one is 
to figure out what sort of container you are working with. If you have an 
implementation that deals with many container "types", the reliable way to 
identify the "type" of a particular container is to check what predicate 
it is based on. Which way round the triples are written is not relevant 
for this purpose.

It would have been easier to code to, and in my view conceptually clearer 
too, if the LDP predicates had been:

LDP+'membershipResource'    # the constant URL that defines the container
LDP+'membershipPredicate'   # the predicate that defines the container
LDP+'membersAreObjects'      # a boolean that tells you whether the 
membershipResource is the subject and the members the objects (the common 
case for us), or vice versa, in the membership triples 

Best regards, Martin

Martin Nally, IBM Fellow and VP,
IBM Rational
tel: +1 (714)472-2690