- From: Erik Wilde <dret@berkeley.edu>
- Date: Wed, 05 Jun 2013 09:52:23 -0700
- To: public-ldp@w3.org
- CC: Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>
hello henry. On 2013-06-04 23:40 , Henry Story wrote: > Anyway I need to split up your question because it is problematic. i don't see why it's problematic, it is the starting point for how you intent to build a functioning system. but anyhow... > 1. "that has no prior knowledge of LDP will" > sorry but if you interact with a client with no prior knowledge of ldp, > does not know the ldp ontology, etc... then it will not be able to know > that the resource is an ldp resource. It won't even have the concept. that's how things work in my world, so i am glad we agree on this. and my guess is that this is what alexandre was trying to understand as well. given that a client needs built-in understanding of LDP to be able to use it, the follow-up question then is how to expose this shared understanding of "we now how LDP works" on the service surface. > 2. "when it encounters text/turtle LDP resources" > That is dangerously misleading shorthand for "an resource that returns a > text/turtle representation describing the resource as being an LDP resource" whatever makes you happy. it doesn't really matter here which RDF serialization we talk about, since they currently all function in the same way: on the media type level, there is no indication of the model, there only is an indication of the metamodel. i just picked text/turtle because that seems to be the preferred RDF serialization these days. > 3. "What to send as request payload". > Currently there is no language to describe this. It is the work for a future > Working Group on RDF validation > https://www.w3.org/2012/12/rdf-val/Overview.php > That is: if you can express what a valid description to send to an > LDP resource is then your question is answered. > For the moment the easiest answer is: there is no standard way to describe > the restrictions of what to send in such a way that a client with no prior > knowledge of a domain would know what it means. - there is no WG on validation. there is an upcoming workshop which may or may not lead to a WG. if there will be a WG, it is unclear what its deliverables will be. - if there will be a WG, it's job will be to work on validation, which is fairly different from "describing how RESTful interactions with a specific service work". the former can be a part of the latter, but doesn't have to be, and even if it is, it usually covers only a small fraction of the actual interaction semantics. given that we have now established that it is necessary for clients to know LDP beforehand, i think it would be interesting to figure out how this works in practice. for example, how can a client tell a server that it supports LDP, so that the server can start serving LDP representations? cheers, dret.
Received on Wednesday, 5 June 2013 16:52:49 UTC