- From: Dietrich Schulten <ds@escalon.de>
- Date: Sun, 22 Mar 2015 09:54:24 +0100
- To: public-hydra@w3.org
Hi, Am 21.03.2015 um 13:59 schrieb Dietrich Schulten: > To illustrate why I think this might be a problem: I want to be able to > let my service accept a query like > > http://example.org/orders?status=ORDER_PROCESSING > > where ORDER_PROCESSING stands for an enumerated value with linked data > name, while at the same time being able to query > Why would I want to do that? Isn't the only correct way to pass the full URL here: http://example.org/orders?status=http%3A%2F%2Fschema.org%2FOrderProcessing Certainly so, if you see json-ld exclusively as a human-readable serialization of RDF. But that is not the correct way to look at it. If you read the abstract of the json-ld spec, it is also a way to describe a deployed system that uses JSON in such a way that its communication gets a defined meaning as Linked Data. Because, smooth upgrade path :) (json-ld even has a construct which isn't there in the RDF model, but only in the json-ish, the expanded and the compacted form: data-indexing. Just to prove that json-ld is not *only* a human- readable serialization of RDF.) Dealing with query parameters as we do here is certainly an edge case, since the parameter value is not json-ld. But my general expectation is that an existing service that understands the URL http://example.org/orders?status=ORDER_PROCESSING should be able to say that with hydra. Certainly nourished by the fact that json-ld goes to great lengths to allow me to express that ORDER_PROCESSING really means http://schema.org/OrderProcessing. Best regards, Dietrich
Received on Sunday, 22 March 2015 08:55:27 UTC