search

w3c / data-shapes

RDF Data Shapes WG repo
89 stars 33 forks source link

non-isomorphic but equivalent paths in validation reports #58

Closed pfps closed 7 years ago

pfps commented 7 years ago

The test suite is deficient in checking paths that occur in validation reports.

A SHACL implementation may produce non-isomorphic but equivalent paths in validation results. For example, for a shape like ex:s1 a sh:PropertyShape ; sh:targetNode ex:i ; sh:path ( :b1 :b1 ) ; sh:class ex:C . :b1 sh:inversePath ex:p . a validation result can have a sh:resultPath link to a structure like ( :bbn1 :bbn2 ) . :bbn1 sh:inversePath ex:p . :bbn2 sh:inversePath ex:p . or to a structure like ( :bbn :bbn ) . :bbn sh:inversePath ex:p . Each of these alternatives has a likely implementation methods that will produce it.

HolgerKnublauch commented 7 years ago

I have addressed this today by clarifying that such shared bnodes need to be normalized prior to the graph isomorphism check.

pfps commented 7 years ago

What is "normalization" in this context?

HolgerKnublauch commented 7 years ago

Here it means to make a deep copy of the bnodes so that they are not shared (i.e. have not two incoming subjects).

pfps commented 7 years ago

If this is the case, it needs to be stated in the document.

HolgerKnublauch commented 7 years ago

I have added such a clarification yesterday.

pfps commented 7 years ago

It's still not right. Triples with sh:alternativePath are not retained. sh:sourceShape is not handled correctly.

However there isn't any reason to get it right, except to note in the document that it isn't right so that people who view it later are not confused.