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

First attempt - describe allowed values for a property in an IriTemplate
with SHACL.

In this case I want to say:

1. that ORDER_PROCESSING and ORDER_DELIVERED are allowed values for the
uri template variable {status},

2. that they correspond to the enumerated values
http://schema.org/OrderProcessing and :OrderDelivered,

3. that at least one of them should be sent,

4. that the client should query status=OrderProcessing by default.

All that is feasible:

{
  "@context": {
    "@vocab": "http://schema.org/",
    "hydra": "http://www.w3.org/ns/hydra/core#",
    "sh": "http://www.w3.org/ns/shacl#",
    "sh:member": {"@type":"@vocab"},
    "sh:predicate": {"@type":"@vocab"},
    "sh:defaultValue": {"@type":"@vocab"},
    "hydra:property": {"@type":"@vocab"},
    "ORDER_PROCESSING": "OrderProcessing",
    "ORDER_DELIVERED": "OrderDelivered"
  },
  "hydra:search": {
    "@type": "hydra:IriTemplate",
    "hydra:template": "http://example.org/orders{?status}",
    "hydra:mapping": [
      {
        "@type": ["hydra:IriTemplateMapping", "sh:Shape"],
        "hydra:variable": "status",
        "hydra:property": "orderStatus",
        "sh:property": {
          "sh:minCount": 1,
          "sh:predicate": "orderStatus",
          "sh:defaultValue": "ORDER_PROCESSING",
          "sh:allowedValues": {
            "@type": "sh:Set",
            "sh:member": [
              "ORDER_PROCESSING",
              "ORDER_DELIVERED"
            ]
          }
        }
      }
    ]
  }
}

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... :)

- 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?

- 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

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

http://example.org/orders?orderNumber=1234

where 1234 is just a number

It seems not possible to define both template mappings within the same
@context. Does anyone else think, too, that this is a problem?

Best regards,
Dietrich


[1] http://tinyurl.com/omxv8xy

Am 21.03.2015 um 11:38 schrieb Dietrich Schulten:
> Hi,
> 
> The RDF shapes group has published a draft [1] and a primer [2] of a
> vocabulary which expresses value constraints. Markus has expressed the
> hope that this could be used with hydra:supportedProperty, so this is
> going to be interesting:
> 
> [1] http://w3c.github.io/data-shapes/shacl/
> [2] http://w3c.github.io/data-shapes/data-shapes-primer/
> 
> Best regards,
> Dietrich
>

Received on Saturday, 21 March 2015 13:00:30 UTC