Re: RDF Shapes has published shacl (Shapes Constraint Language) draft

Hi Tomasz,

Am 22.03.2015 um 14:41 schrieb Tomasz Pluskiewicz:
> On 2015-03-22 09:40, Dietrich Schulten wrote:
>> Hi Tomasz,
>>
>> Am 21.03.2015 um 22:00 schrieb Tomasz Pluskiewicz:
>>> On 2015-03-21 13:59, Dietrich Schulten wrote:

> If you want to use abbreviated URIs as defined in your example's
> @context, the solution is expanded @value node:
> 
>  "sh:member": [
>    "ORDER_PROCESSING",
>    "ORDER_DELIVERED",
>    {
>      "@value": "other_status"
>    }
> ]
> 
> When expanded you will get two URIs as expected and a literal
> "other_status". Does that answer your concern?
> 

Yes, great solution, thank you! See also
https://lists.w3.org/Archives/Public/public-hydra/2015Mar/0087.html

>>
>> PUT /orders/42
>> Content-Type: application/json
>>
>> {
>>     "status": "ORDER_PROCESSING"
>> }
>>
>> I'd like my service to be able to say that this is an expected request,
>> because of - smooth upgrade path.
>>
>> This desire is certainly nourished by the fact that it is so easy to
>> make the above json meaningful as Linked Data, e.g. by adding a Link
>> header to a jsonld context file which defines that status means
>> http://schema.org/orderStatus and that ORDER_PROCESSING really means
>> http://schema.org/OrderProcessing.
> 
> Ok, I see you answer my above question. This may be a problem indeed.

Or maybe not, after you solved my @type cast problem so elegantly :)

> Now, upgrading to JSON-LD for me kind of
> implies that the underlying data model is in fact RDF and you can't
> escape that fact. 

I do not want to escape that fact. What I do want is: keep the ability
of json-ld to *interpret* communication in plain json in terms of RDF as
much as possible.

If the server understood a query

/orders?status=ORDER_PROCESSING

until yesterday, and now it adds a Link header to its application/json
responses which interprets them as linked data, then it does not sound
reasonable that all client requests suddenly MUST be linked data, too,
and that the status query value must be a URL from now on.

In fact, I was assuming the opposite all the time and thought that the
expanded form in IriTemplates is only required if the server
specifically applies ExplicitRepresentation. Otherwise, if the server
says "status":"ORDER_PROCESSING" in a response, then the client also may
say ?status=ORDER_PROCESSING in a query which filters by that value.

I can see of course that the above URL query is not linked data and that
a pure RDF service wouldn't know what to make of it. My understanding
was that this is why such a service may ask clients to use
ExplicitRepresentation.

What do you think?

Best regards,
Dietrich

Received on Sunday, 22 March 2015 18:01:17 UTC