Warning:
This wiki has been archived and is now read-only.
User:Rcygania2
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.
Contents
1 Goals in the WG
What I want out of LDP is having a specification for accessing and manipulating RDF graphs via RESTful HTTP. Key issues:
- Server-driven IRI assignment
- Pagination
- Constraints (probably not doable for LDP v1)
- Splitting the graph into individual resource descriptions
- Relationship between entity URIs and RESTful "document" URIs
- Server-managed properties
- Formal model
- Fixing non-RESTful URI business in the submission
2 My links
3 Scratchpad
3.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?
3.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?
Additional related question:
5. If member descriptions are inlined into a container representation, can one manipulate the member descriptions through PATCH/PUT on the container? (I'd say the answer should be no. Containers are for manipulating membership only.)