Difference between revisions of "User:Rcygania2"

From Linked Data Platform
Jump to: navigation, search
(Scratchpad)
Line 27: Line 27:
  
 
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?
 
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.)

Revision as of 19:56, 15 March 2013

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 My links

2 Scratchpad

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?

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