Pre-limiting values available to the user

[cbur...@healthwise.org]

Suppose I have a data graph with an underlying ontology that defines a class/NodeShape and two propertyShapes as follows:

ex:ClassA

  a owl:Class ;

  a sh:NodeShape ;

  sh:property ex:ClassA-property1 ;

  sh:property ex:ClassA-property2 ;

.

ex:ClassA-property1

  a sh:PropertyShape ;

  sh:maxCount 1 ;

  sh:minCount 1 ;

  sh:path ex:property1 ;

  sh:class ex:ConceptType1 ;

.

ex:ClassA-property2

  a sh:PropertyShape ;

  sh:maxCount 1 ;

  sh:minCount 1 ;

  sh:path ex:property2 ;

  sh:class ex:ConceptType2 ;

.

Now suppose I want to impose a further constraint on the instances of ex:ClassA in my data graph: The value of ex:ClassA-property2 is constrained in a specific way (expressible by a SPARQL constraint) based on the user-selected value for ex:ClassA-property1. I have written a SPARQL-based SHACL constraint to enforce this.

But is there a way to use that constraint to actually limit the values presented to the user for ex:ClassA-property2, so that they cannot choose a "wrong" value in the first place? (I understand that this would likely require the value of ex:ClassA-property1 to be selected and saved first.)

Sorry if any of this is unclear -- happy to provide more details if needed.

[Holger Knublauch]

Hello Carl,

no, the user input widget only looks for the declared sh:class. Doing more sophisticated on-the-fly checking against something as complex as SPARQL queries would likely be too slow, and people would see the error when they try to press the Save Changes button because the form will display an error/warning in that case. In your specific case, the situation would become even harder to check on the fly, because - as you say - the values depend on each other and we would need to temporarily infer all currently entered values etc.

We do have support for one specific scenario though, in cases such as "when property1 (country) is 'USA' then property2 (state) must be one of 'Alaska', 'Alabama', ... in case that patterns is what you need. I can provide details if that sounds interesting.

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/d85ea09f-4659-4a2e-b066-6d81799d94f4n%40googlegroups.com.

[Carl Burnett]

Thanks for the quick reply, Holger.

 

Do you mean that you support only the scenario related to geography, or also other similar scenarios? In our case, we want to look at the specific rdf:type of the concept that has been selected as the value of one property and use it to constrain the values of another concept scheme that are in play for the second property.

 

From: topbrai...@googlegroups.com <topbrai...@googlegroups.com> On Behalf Of Holger Knublauch
Sent: Wednesday, August 11, 2021 2:43 PM
To: topbrai...@googlegroups.com
Subject: Re: [topbraid-users] Pre-limiting values available to the user

 

*** External email: use caution ***

--
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/6hyN44MnaV8/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/ee3dca12-0c83-5c96-1462-8cf26a486ccc%40topquadrant.com.

[Holger Knublauch]

I am attaching an example shapes graph for a scenario like the country/state pairs. Applicable values are expressed by a SHACL node shape that has a dash:HasValueTarget as its sh:target and uses a sh:in enumeration for the permissible values. As an example choosing 'Temperature' as the quantity kind of the focus node needs to constrain the values of unit for that same node to Celsius, Fahrenheit or Kelvin.

This does not seem to be exactly the scenario you have, which seems to be "all concepts under a given concept scheme"? As I said this is difficult to generalize and may require a custom widget or custom extension.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/MWHPR19MB1598A8BD87AA53630FB946C2B7F89%40MWHPR19MB1598.namprd19.prod.outlook.com.

[Carl Burnett]

Thanks, Holger. The main differences between the country/state scenario and mine are:

1. The values of sh:in (for the PropertyShape declaration) and dash:object (in the sh:target declaration) need to be resources, rather than strings as in your example.
2. My sh:target statement would need to be more complex, because I want to invoke the special shape (analogous to states:AUAddressShape) not when the instance has a certain value for the “other property,” but when its value has a certain rdf:type.

 

Is this doable, either in an out-of-the box way or in a customized way? (Feel free to reach out to me off of the list if that’s more appropriate.)

 

thanks,

Carl

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/662890d3-6ce4-3ea9-c8c4-c4de1639a007%40topquadrant.com.

[Holger Knublauch]

On 2021-08-13 2:35 am, Carl Burnett wrote:

Thanks, Holger. The main differences between the country/state scenario and mine are:

1. The values of sh:in (for the PropertyShape declaration) and dash:object (in the sh:target declaration) need to be resources, rather than strings as in your example.

That should be fine

1. 
   
2. My sh:target statement would need to be more complex, because I want to invoke the special shape (analogous to states:AUAddressShape) not when the instance has a certain value for the “other property,” but when its value has a certain rdf:type.

This would require a different component and a different SHACL target type etc.

 

Is this doable, either in an out-of-the box way or in a customized way? (Feel free to reach out to me off of the list if that’s more appropriate.)

As an example of what would be involved, I am attaching the source code of the current implementation (for the sh:in pattern that I mentioned). A new implementation can borrow from this, but would need to swap out the SPARQL queries. Then there is the surrounding infrastructure such as installing the JavaScript component. This is a non-trivial undertaking. We could help doing this on something like Premium Support - this would better become an off-list discussion then.

BTW are you sure you can use sh:in here? Your original message sounded more like the concepts under a given skos:ConceptScheme.

Overall, I cannot tell how important this convenience feature is for your users, but there is a considerable complexity involved here and many variations of the same theme. All of them can be expressed in SHACL for constraint validation after the editing, but it's tricky to build this into editing widgets at edit time. You have (intentionally and rightfully) abstracted away your example into generic names, but if you want us to build this into the main product it would help us understand some real-world examples, with realistic triples and class names.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/MWHPR19MB15988C0BB6456EFF61E327D0B7F99%40MWHPR19MB1598.namprd19.prod.outlook.com.