Re: ISSUE-22: Proposal based on sh:hasShape

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As far as I can tell the approach taken in http://arxiv.org/abs/1505.04972
is only suitable for a very limited set of constraints. It requires that a
requires relation can be constructed and then used as the core of the shape
recognition algorithm.  This does not work for constraints that can be
satisfied if only some of the values of a property have a particular shape
(e.g., someone who has a friend that belongs to a particular shape, but who
might have other friends), for disjunction, or for negation, as far as I can
determine.

This being the case, using the work in http://arxiv.org/abs/1505.04972
cannot be used as evidence that a particular kind of algorithm is going to
work for SHACL.

Iovka's semantics is for a constraint language that has some of the above
features, but it has some very strange behaviour with negation.  It also
admits multiple interpretations and there is as of yet no effective
algorithm that implements the semantics.

peter


On 06/24/2015 12:51 PM, Arthur Ryman wrote:
> Holger,
> 
> Are you saying that validation will fail if your engine encounters a 
> recursive call?
> 
> If so, I disagree with this proposal because it eliminates very natural
> and useful forms of recursion that have completely well-defined
> semantics, e.g. the way oslc:valueShape works.
> 
> The way to avoid infinite loops is to keep track of which shapes must be
> validated on which nodes. In effect, you are maintaining a graph whose
> nodes are pairs (x,s) where x is an RDF node and s is a shape name. As
> you validate x wrt s, you mark (x,s) as visited. During the validation,
> you may need to validate a neighbouring RDF node y with a shape r. You
> see if (y,r) is already visited. If not, you continue the validation on y
> wrt r. This process never leads to infinite loops. I have described it in
> detail in [1].
> 
> That being said, I am not sure about the case involving negation and 
> disjunction of shapes, but Iovka has a proposed semantics for that.
> 
> [1] http://arxiv.org/abs/1505.04972
> 
> -- Arthur
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVjCOxAAoJECjN6+QThfjzL38H+QGAun+UNrO3fYCtzC+DdoFH
JFBRmNRcfDrJRH77YPulVVbvLdNQD6CyZMMkp1lm7oW+J7KRjrMFWxY8dGH6ny/1
gn9Njjuqg7IjPBhNdBvldsDxaVE6dH1b1NHz/b6hABtGKsNoTXjDOgAfUkFTOl6y
BlpS156oGqTXW7vsLoAIgpAStTMsHD894/+2ap/PGzXLiEtjHoS+yHl6dyfkttS5
QSjwVgZ2owypxu0bNTAmD74ShXncdQt+dfzweVXAfAqIQNVvJAqY8VMAswBsBf5a
ycXtN0c/tyApIe6qyLN1WlGgy+IbDPWGyRPE9J2u72FyZXwmc+e5NxQ/fIGYyqM=
=UboY
-----END PGP SIGNATURE-----

Received on Thursday, 25 June 2015 15:52:55 UTC