I'm Richard Cyganiak, a researcher at the Digital Enterprise Research Institute (DERI) in Galway, Ireland. I'm a member of the RDF and GLD WGs, and a veteran of the RDB2RDF WG.
2.1 Use cases and requirements for LDP
- Graph nodes with many incoming and outgoing edges: Representations need to be split and paginated
- Graph nodes with many incoming and outgoing edges: How to add and remove edges?
- Graph nodes with many edges and different properties
- Documents with multiple entities, e.g., vocabularies
- 303 redirects -- an existing design pattern, how to support it?
2.2 Dinner breakout questions
The following questions arose from the dinner breakout at F2F2.
1. Can we have a value set that doesn't imply that you can create resources by POSTing to it (no factory)? Is that a simple ldb:Container?
2. Can a client PUT/PATCH arbitrary (non-membership) triples to a container? I feel we would have a simpler model if that was not allowed, and if PUT/PATCH on containers were restricted to only the manipulation of membership triples. If you want extra triples, they probably should be about the *membershipSubject*, which can have a separate URI, and you can already assert arbitrary triples about it via PUT/PATCH.
3. If membershipSubject and container URI are not the same: What can the client expect to find when dereferencing the membershipSubject? Does the membershipSubject link to the container and how? Should it contain the container metadata (ldp:Container, ldp:membershipSubject, ldp:membershipPredicate) so that clients can find any related containers?
4. If membershipSubject and container URI are not the same: Can a client change membership triples by PUT/PATCH to the *membershipSubject*? It sounds like it's a bad idea for clients to try this. Should the client rather discover the container, and then PUT/PATCH to the container? Does the spec need to say something about what clients are supposed to do in this case?