Objects of sh:hasValue

[Tomasz Pluskiewicz]

Hello. 

The spec seems to implicitly hint that sh:hasValue allows a single object.

The playground however is quite happy with a property constrained like

[ 

  sh:path rdf:type ;

  sh:hasValue schema.org:Dataset, void:Dataset, dcat:Dataset

]

and it, as expected, fails to validate when one of the required types is missing from the focus node.

Is this correct usage by the spec or just a little liberty taken by the validation library?

Tom

[Holger Knublauch]

It is perfectly valid to have multiple hasValue values. Where do you think the spec hints otherwise?

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/91540a6c-3f3f-46b3-901e-1cb3baa3fd8bn%40googlegroups.com.

[Tomek Pluskiewicz]

Pretty much in every sentence :)

The singular “RDF term” sounded quite unambiguous to me

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/ei7WVb_rkN8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ca95181b-61aa-5683-936d-780897e71238%40topquadrant.com.

[Bohms, H.M. (Michel)]

If the spec is right (now), I would even propose to change the spec for the next version 😊

Especially for multiple typing checks the multiple variant seems very handy….

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAAFOhSf8LMAZWYbA3rij%2BVKABw0QpcBWqmLO2aT1Jv%3Dhp-9mng%40mail.gmail.com.

[Holger Knublauch]

The spec is written in fairly formal english, not necessarily intuitive. That is, for better or worse, how such specs are written. All constraint properties can theoretically appear multiple times, yet for many it doesn't make sense to have more than one. For example, in sh:minCount 2, 3 the 2 would be redundant and meaningless noise. However, sh:hasValue and sh:node are among the constraint types that make sense to have multiple values at the same shape. Since the spec is a description of each individual constraint, it always uses singular form. Many many implicit assumptions are not spelled out as it would easily double the spec in length. This is the task of secondary literature such as tutorials.

Holger

[Holger Knublauch]

The spec is written in fairly formal english, not necessarily intuitive. That is, for better or worse, how such specs are written. All constraint properties can theoretically appear multiple times, yet for many it doesn't make sense to have more than one. For example, in sh:minCount 2, 3 the 2 would be redundant and meaningless noise. However, sh:hasValue and sh:node are among the constraint types that make sense to have multiple values at the same shape. Since the spec is a description of each individual constraint, it always uses singular form. Many many implicit assumptions are not spelled out as it would easily double the spec in length. This is the task of secondary literature such as tutorials.

Holger

On 10/30/2020 6:38 PM, Bohms, H.M. (Michel) wrote: