Re: Hydra<>SHACL integration

On 9/20/2015 22:04, Dietrich Schulten wrote:
> Hi,
>
> I am looking into SHACL[1] with Hydra.

Unless I am missing something (I am not a Hydra expert), the 
correspondence seems to be hydra:Class = sh:ShapeClass and 
hydra:SupportedProperty = sh:PropertyConstraint. Depending on how far 
you guys want to take this, I guess a deep integration could consist of

1) declare hydra:Class to be a subclass of sh:Shape (or just use 
sh:ShapeClass)
2) use sh:property as alternative to hydra:supportedProperty
3) replace hydra:required with sh:minCount=1
4) add missing features from Hydra (e.g. readable/writable) to 
sh:PropertyConstraint

Holger


>
> In SHACL one can describe a set of property constraints for instances.
>
> ex:AllowedValuesExampleShape
>  a sh:Shape ;
>  sh:property [
>   sh:predicate schema:eventStatus ;
>   sh:allowedValues ( schema:EventCancelled,
>                    schema:EventScheduled, schema:EventPostPoned ) ;
>  ]
>
> If I understand the SHACL spec draft[2] correctly, this shape can be
> applied to a scope:
>
> 1. by an individuum which adopts the shape via a sh:nodeShape property
> whose value must be an IRI such as ex:AllowedValuesExampleShape, stating
> that this individual satisfies AllowedValuesExampleShape.
>
> 2. by the shape which can apply itself to an rdfs:class via
> sh:scopeClass, which says that every single individuum of that
> rdfs:class must satisfy the shape
>
> 3. by the shape which can define "scope selectors" for subjects having a
> certain predicate, or objects of a certain predicate, or for all
> subjects or objects in a given graph
>
>
> In Hydra we say that a method expects a certain type and we can make
> statements about its properties, e.g. below I say that the
> schema:eventStatus is a required property for a PUT request.
>
> {
>    "@context": {
>      "@vocab": "http://schema.org/",
>      "hydra": "http://www.w3.org/ns/hydra/core#"
>    },
>    "@id": "http://localhost:8080/webapp/hypermedia-api/events/1",
>    "hydra:operation": [
>    {
>      "hydra:method": "PUT",
>      "hydra:expects":
>      {
>        "@type": "Event",
>        "hydra:supportedProperty": [
>        {
>          "hydra:property": "eventStatus",
>          "hydra:required": true
>        }]
>      }
>    },
>    {
>      "hydra:method": "DELETE"
>    }]
> }
>
> How do I constrain the allowed values for eventStatus with SHACL in the
> context of a Hydra response? Can I simply add sh:allowedValues as shown
> below?
>
> {
>    "@context":
>    {
>      "@vocab": "http://schema.org/",
>      "hydra": "http://www.w3.org/ns/hydra/core#",
>      "sh": "http://www.w3.org/ns/shacl#"
>    },
>    "@id": "http://localhost:8080/webapp/hypermedia-api/events/1",
>    ... event properties ...
>    "hydra:operation": [
>    {
>      "hydra:method": "PUT",
>      "hydra:expects":
>      {
>        "@type": "Event",
>        "hydra:supportedProperty":
>        {
>          "hydra:property": "eventStatus",
>          "hydra:required": true,
>          "sh:allowedValues" : {
>            "@list": [ // SHACL requires this to be an rdf:List
>              "schema:EventCancelled",
>              "schema:EventPostPoned"
>            ]
>          }
>        }
>      }
>    },
>    {
>      "hydra:method": "DELETE"
>    }]
> }
>
> By using sh:allowedValues I am saying that the value of
> hydra:supportedProperty is not only a hydra:SupportedProperty, but also
> a sh:PropertyConstraint. Does that make hydra:supportedProperty an alias
> of sh:property by inference? If so, I guess that the value of
> hydra:expects is now not only an Event, but also a sh:Shape.
>
> So I am really saying that one should send a sh:Shape as request body of
> the PUT - which is not what I mean to say. What I want to say is that
> the client may cancel or postpone the event. For this it should send an
> Event with the appropriate eventStatus value.
>
> The following seems better, but it pushes the envelope quite a bit
> because the SHACL spec specifically says that the value of sh:nodeShape
> must be an IRI and the subject of sh:nodeShape must be an individual. I
> took the freedom to inline the nodeShape below:
>
> { ...
>    "@id": "http://localhost:8080/webapp/hypermedia-api/events/1",
>    "hydra:operation": [
>    {
>      "hydra:method": "PUT",
>      "hydra:expects":
>      {
>        "@type": "Event",
>        "sh:nodeShape": {
>            "@type": "sh:Shape",
>            "sh:property" : {
>              "sh:predicate": "eventStatus",
>              "sh:allowedValues" : {
>                "@list": [
>                  "schema:EventCancelled",
>                  "schema:EventPostPoned"
>                ]
>              }
>            }
>          }
>        "hydra:supportedProperty": [
>        {
>          "hydra:property": "eventStatus",
>          "hydra:required": true,
>        }]
>      }
>    }]
> }
>
> What are your thoughts how Hydra could or should integrate with Hydra?
>
> If an inline nodeShape is a good fit, should we raise an issue with the
> SHACL group to see if they can allow inline node shapes?
>
> To me, the nodeShape scope (1.) seems to fit somewhat better than the
> other scopes (2., 3.). Usually I want to constrain a request body for a
> particular ReST resource, maybe even in a particular status of the
> resource - but I do not want to constrain an entire class I might not
> even own.
>
> There is a second case where I think it makes sense to constrain values:
> IriTemplateMapping. Similar questions arise there.
>
>
> Best regards,
> Dietrich
>
> [1] https://www.w3.org/2014/data-shapes/wiki/Main_Page
> [2] http://w3c.github.io/data-shapes/shacl/
>
>
>
>
>

Received on Monday, 21 September 2015 01:17:04 UTC