Single predicate as sequence path considered invalid
Tomasz Pluskiewicz
Holger Knublauch
This constraint is specified at
https://www.w3.org/TR/shacl/#property-path-sequence and was
intentionally designed like that. As you say it could
theoretically have the same effect as IRI properties, yet then the
algorithms would need to make an additional IF for the special
case, and I assume we agree that sequence paths with a length of
one don't make sense.
Think about it this way: if we would map such lists to single
values, then arguably any API function that takes single values
should also be allowed to take array arguments with length of one.
It would become quite chaotic.
Holger
--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/eb72df9c-eee2-46f2-8872-49f860fcbcc1n%40googlegroups.com.
Tomasz Pluskiewicz
Holger Knublauch
On 2021-02-20 5:55 pm, Tomasz Pluskiewicz wrote:
FWIW, I can't say I agree
If you have a function which only works with a Property Path, you still conditional code to check whether a Property Shape has a Property or Sequence Path. It's just shifting that same complexity from one place to another. At the same time sacrificing simple of use for the shape authors.
And no, a single-element sequence do make sense. It's just a single edge traversal. I expect an algorithm to follow paths would handle that case without explicit logic.
Yes, traversal algorithms would work. But I can tell you that in
my own code there are dozens of checks that perform different
behavior of the sh:path is a URI vs a blank node. For example it
allows faster SPO look-up vs path engine, and Forms can actually
edit such values while path values are treated as "inferred" and
read-only (except sh:inversePath IRI). It would be a pain to have
to cover this special case of single-element paths in all those
places. And where would it stop - ex:prop1|ex:prop1 too?
But that's a topic where both view points are valid, so let's
agree to disagree, and the spec is what it is.
Holger
Tom
--sobota, 20 lutego 2021 o 01:29:52 UTC+1 Holger Knublauch napisał(a):
This constraint is specified at https://www.w3.org/TR/shacl/#property-path-sequence and was intentionally designed like that. As you say it could theoretically have the same effect as IRI properties, yet then the algorithms would need to make an additional IF for the special case, and I assume we agree that sequence paths with a length of one don't make sense.
Think about it this way: if we would map such lists to single values, then arguably any API function that takes single values should also be allowed to take array arguments with length of one. It would become quite chaotic.
Holger
On 2021-02-20 6:19 am, Tomasz Pluskiewicz wrote:
Hi
I was surprised to find out today that a Property Path declared as an RDF List with only a single element is not a valid construct and fails validation with SHACL.js
I would expect [ sh:path ( ex:property ) ] be treated equally to [ sh:path ex:property ]
Why is sequence path defined to require at least two members?
Best,Tom--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/eb72df9c-eee2-46f2-8872-49f860fcbcc1n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/a1713a7a-da23-4c77-85a1-b065b2fc4bebn%40googlegroups.com.