- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Wed, 22 May 2013 07:41:04 -0700
- To: Henry Story <henry.story@bblfish.net>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <OF66B126C3.66A64C6A-ON88257B73.004F28DB-88257B73.0050AA2B@us.ibm.com>
Henry Story <henry.story@bblfish.net> wrote on 05/22/2013 06:27:17 AM: > ... > I have no idea what you mean "define containers without forcing > people to change their vocabulary". > The question is what is the UC&R for this functionality? Where does > it come from? What is the > need? (I mean for the protocol) This is about allowing people to expose existing data in which they have been using something like Nandana's bt:hasBugReport predicate or something similar without forcing them to change the representation of their data to use rdf:member. I don't know that we have this requirement captured in our UC&R. If we don't we should fix this. > > The LDP spec is about GET, PUT, POST, DELETE. One whole section of > the spec is about how those > words are used in resources we call LDPCs . Fine. So it is quite > reasonable to ask what the point of > ldp:membershipPredicate is. Yes, it is. But the reason is much simpler than what you seem to think and it has nothing to do with validation. > I gave above what seem two possible > reasons for why it > is needed with respect to POSTing. If you know the restrictions on > the relation, you know what type > of document you can or cannot POST. That still leaves room for a > group such as RDF-Validation > group [1] to crete a language to make such definitions machine > parsable, but one could argue for > the inclusion of those relations on those grounds. > > Henry > > [1] https://www.w3.org/2012/12/rdf-val/Overview.php -- Arnaud Le Hors - Software Standards Architect - IBM Software Group
Received on Wednesday, 22 May 2013 14:47:53 UTC