From Linked Data Platform
Jump to: navigation, search

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.

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.)