Re: ISSUE-13

> 4.1.2, "BPR servers must provide an RDF representation for BPRs"
Maybe I'm being overly literal, but I interpret that as being equivalent 
to: "Every BPR has an RDF representation, and the server must provide it 
when it is asked for."  Nothing more, nothing less.
Consequently:
> 1)   Does this restriction mean that BPCs can have members that are not 
BPRs?
Assuming that a LDPC is an LDPR (as is true in the current spec), it means 
that an LDPC must have an RDF representation and that its server must 
provide that when asked.  It says nothing about the LDPC's members, one 
way or the other.  5.4.3 currently says that non-RDF member 
representations may be accepted by an LDPC on POST-Create, so I would 
answer the question above with "no, that restriction does not limit an 
LDPC's membership."
> 2) ...
I would say the clause noted in 2b governs; we might need to add 
5.5.1-equivalent text in 5.8 for PATCH, assuming we want the same 
behavior.  Since 5.5.1 is "should not", in the end the server is free to 
accept or reject requests to edit membership via PUT/PATCH on the LDPC. 
Which seems reasonable to me at this point.
>  I would assume that we can use PATCH to insert/update triples whose 
subjects are members of the container (i.e. without changing the 
membership itself).
That seems like a practice to discourage.  If you want to update the 
members' content, interact with those resources through their URLs not 
through the container, which will be problematic for caches.  I'd be 
interested in feedback from implementations that are fundamentally 
fronting a "simple" graph store though; I've seen some aversion to 
"cracking open the payload" in earlier discussions, even if I'm not 
entirely convinced about that yet.  If we made any strong (MUST/NOT) 
statements about this case, I would expect that aversion to resurface.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario