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

Forwarding to the group, because I apparently answered Dietrich alone.


-------- Forwarded Message --------
Subject: Re: RDF Shapes has published shacl (Shapes Constraint Language) 
draft
Date: Sat, 21 Mar 2015 22:00:45 +0100
From: Tomasz Pluskiewicz <tomasz@t-code.pl>
To: Dietrich Schulten <ds@escalon.de>

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"
]

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

>
> - 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.
Think a tag property (a folksonomy). Existing values are likely to have
a URI, but often users can create ad-hoc tags in plain text. The server
upon receiving a literal instead of a string would mint a URI for a new
tag and use that instead. Would that be impossible with SHACL?

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

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?

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

Why is it not possible? Is that a limitation of Hydra or SHACL?

Regards,
Tom

[1] https://github.com/HydraCG/Specifications/issues/30

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