Difference between revisions of "User:Rcygania2"

From Linked Data Platform
Jump to: navigation, search
(Scratchpad)
Line 16: Line 16:
 
* Documents with multiple entities, e.g., vocabularies
 
* Documents with multiple entities, e.g., vocabularies
 
* 303 redirects -- an existing design pattern, how to support it?
 
* 303 redirects -- an existing design pattern, how to support it?
 +
 +
=== 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?

Revision as of 17:02, 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?