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

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:
>>>
>>> see also in the playground [1].
>>>
>>> First impression:
>>> - quite powerful already, I like the minValue/maxValue. It would be nice
>>> if we could hint in the spec that SHACL is a possible way to express
>>> constraints, so clients and servers could start to use it with some
>>> confidence. For interoperability reasons, it would be helpful to show
>>> some preference here and not leave this completely open.
>>>
>>> - sh:Set: yet another collection construct. Oh well... :)
>>
>> Is that really necessary? Why not simply
>>
>> "sh:allowedValues": [
>>    "ORDER_PROCESSING",
>>    "ORDER_DELIVERED"
>> ]
>
> The draft has that alternative, too, it uses a singular property
> allowedValue (no plural s):
>
>   "sh:allowedValue": [
>     "ORDER_PROCESSING",
>     "ORDER_DELIVERED"
>   ]
>
> They are still undecided if there should be both ways or, if just one,
> which one. I chose the one that is mentioned more prominently.
>
>>
>>>
>>> - sh:predicate competes with our use of hydra:property in hydra:mapping
>>> and hydra:supportedProperty, we have to duplicate the property - should
>>> we integrate with shacl so deeply that only sh:predicate will be left?
>>
>> I don't think so. If a client was ignorant of SHACL, then it would not
>> understand sh:property. If anything I would make sh:property optional
>> and rely only on hydra:property in this context.
>
> But then it wouldn't be a complete shape, e.g. for a SHACL library that
> uses the description to validate.

I thought that would be it. In such case duplication is unavoidable IMO.

>
>>
>>>
>>> - Same for hydra:required and sh:minValue
>>>
>>> - in a given @context, all values of sh:member can be either individuals
>>> (values which are URIs) or literals (values which are plain strings,
>>> numbers, etc.), depending on whether or not sh:member is defined as
>>> "@type":"@vocab"
>>>
>>> - the same applies to sh:defaultValue: the defaultValue can either be a
>>> literal or an individual within the same @context, but not both
>>
>> RDF in any form doesn't forbid mixing literals and URIs here. I don't
>> see why SHACL would add such limitation. It should be up to the server
>> to define whether either or both were acceptable and act accordingly.
>
> That is right, the problem is not in SHACL, but in the combined use of
> SHACL with the "@type" feature of json-ld - be it @type:@vocab or @type:@id.
>
> In the context I have to decide if the values of sh:member are to be
> interpreted as a literal or as a linked data identifier. If I say
>
> "@context": {
>     "@vocab": "http://schema.org/",
>     "sh": ...,
>     "sh:member": {"@type": "@vocab"},
>     "hydra:property": {"@type": "@vocab"},
> }
>
> then I express that all sh:member values should be prefixed with
> "http://schema.org/". Quite handy, so this is valid:
>
> "hydra:search": {
>    "@type": "hydra:IriTemplate",
>    "hydra:template": "http://example.org/orders{?status}",
>    "hydra:mapping": {
>      "hydra:variable": "status",
>      "hydra:property": "orderStatus",
>      "sh:allowedValues": {
>        "@type": "sh:Set",
>        "sh:member": [
>          "OrderProcessing",
>          "OrderDelivered"
>        ]
>      }
>    }
> }
>
> The variable 'status' takes values for the property with the @id
> http://schema.org/orderStatus
>
> and the allowed values are objects with an @id of
>
> http://schema.org/OrderProcessing and
> http://schema.org/OrderDelivered.
>
> But if I add one more IriTemplate which shares the same @context:
>
> "hydra:search": [
>    { ... mapping from above ... },
>    {
>      "@type": "hydra:IriTemplate",
>      "hydra:template": "http://example.org/orders{?rating}",
>      "hydra:mapping": {
>        "hydra:variable": "rating",
>        "hydra:property": "ratingValue",
>        "sh:allowedValues": {
>          "@type": "sh:Set",
>          "sh:member": [
>            "1",
>            "2",
>            "3",
>            "4",
>            "5"
>          ]
>        }
>      }
>    }
> }
>
> then I'm in trouble because I say that the allowed values are
> http://schema.org/1 through http://schema.org/5.
>
> The same problem applies if I use "@type":"@id".

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?

>
>>>
>>> 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
>>
>> Is the ORDER_PROCESSING in the query string as defined in the example
>> SHACL definition? I think this is not right. Of course you used a
>> human-readable form in the JSON-LD document by defining it in the
>> @context. I do think however that parameter passed in the URL should be
>> a full absolute URI like
>>
>> http://example.org/orders?status=<http://schema.org/OrderProcessing>
>
> That makes sense if you see json-ld only as a human-readable
> serialization of RDF.
> But that is not the only 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. The latter being proof that json-ld is not *only* a
> 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 would be that an existing service that
> understands the URL http://example.org/orders?status=ORDER_PROCESSING
> should be able to say that with hydra. Similarly, the same existing
> service might handle such a request:
>
> 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. 
But, given that you consider a smooth upgrade path, I would assume that 
the initial system would only accept a closed set options for order 
status. Something like { "status": "5" } would be an invalid message 
anyway and would still be invalid if you tried to interpret it as a URI 
after a JSON-LD upgrade. 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. Of course you can hide for just so long but struggling 
like I think you do is futile.

My point is that this is precisely where RDF shines, that it (by which I 
mean serialization formats) lets you reliably distinguish between URI 
and literal values. But I'm afraid that if you need such semantics, it 
will be necessary to make the upgrade path a little less smooth and make 
the requests more explicit like http://example.org/orders?status="5" 
(with quotes), or

PUT /orders/42
Content-Type: application/json

{
    "status": { "@value": "5" }
}

Anything else could still use the smooth path you describe.

>
>>
>> So here are example of the tags I mention above. First a preexisting tag
>> the user selected and then a new one, entered in plain text.
>>
>> http://example.org/articles?tag=<http://exmaple.org/tag/lengthy-read>
>> http://example.org/articles?tag="future technology"
>>
>> The server could mint an URI <http://exmaple.org/tag/future-technology>
>> for the latter and use that URI from then on.
>>
>> Note that parameters above are supplied in heart of what has been
>> discussed in issue #30 [1] for variable representations.
>>
>> What do you think?
>
> If I put on the shackles ;-) I think I could only use both variants if
> both variants are explicitly allowed. In that case one must probably go
> to full verbosity to allow both as tag query parameter.
>
> "sh:allowedValue": [
>    { "@id": "http://exmaple.org/tag/future-technology" },
>    "future technology"
> ]
>
> No @type casting would be possible here.

Yes, that works too. However IMO, the way where @type is implicit and 
@value is explicit is more friendly for json to json-ld upgrade.

>
> I'm a bit concerned that using SHACL will restrict me to use only
> ExplicitRepresentation in IriTemplates. Because only in
> ExplicitRepresentation I can pass a typed value, and SHACL has of course
> no JSON upgrade path on its agenda, so it only prescribes typed values.
>
> BTW, if I am not mistaken, the <> brackets around the URL are not right,
> neither in BasicRepresentation nor in ExplicitRepresentation :)

Yes you're right of course.

>
> Best regards,
> Dietrich
>

Received on Sunday, 22 March 2015 13:42:08 UTC