How do I deploy sh:property?

[Gary Murphy]

This is my first dip into SHACL constraints, and what I'm needing might be easy to do, only I'm stuck at the last step...

My objective is to constrain swa:URIResourceEditor to only offer auto-complete on an rdf:type with classes in the schema.org namespace, which is exactly what the comment on the URIResourceEditor says it can do:

The auto-complete can apply a model-driven filter to the resources. If the subject has SHACL property constraints for the given predicate, then it will filter out all nodes where one of the shapes specified via sh:not is not fulfilled. Among others, this makes it possible to filter out system namespaces (via tosh:SystemNamespaceShape)

Since I want this to apply to all schema.org subjects, I set out to add the sh:property constraint to schema:Thing only rather than the tosh:SystemNamespaceShape it seemed more appropriate to use the dash:StemConstraintComponent and this is where it stopped:  in the list of constraint shapes I find dash:StemConstraintComponent-stem (which would be the value of the IRI stem?) but no where to set the value of that stem.

Am I going in the right direction with this? Do I need to define my own value shape somewhere that would define itself in terms of calling dash:StemConstraintComponent with the -stem parameter? 

Or should I define a new value shape, much like tosh:SystemNamespaceShape and using sparql to just test that the object starts-with the right namespace?

[Gary Murphy]

recklessly moving ahead ;) ... 

would the following class do the trick?

hmapp:SchemaNamespaceShape

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  dash:stem "http://schema.org" ;

  rdfs:subClassOf owl:Thing ;

  sh:nodeKind sh:IRI ;

  sh:severity sh:Violation ;

  sh:targetClass schema:Thing ;

  sh:targetObjectsOf rdf:type ;

.

and having defined the targetClass and targetObjectsOf, would there be no need to do any more to get the effect I'd wanted restricting the URIResourceEditor to schema classes?

[Gary Murphy]

Taking another read of the URIResourceEditor description, I'm understanding a tiny little more about the sh:not reference, leading me to believe that I needed the hmapp:SchemaNamespaceShape to identify those rdf:type values that are IN the set, but then I need a second hmapp:NotSchemaNamespaceShape that simply includes sh:not hmapp:SchemaNamespaceShape, and then, in the rules for schema:Thing sh:not hmapp:NotSchemaNamespaceShape

unfortunately, it didn't work, other classes still appear in the rdf:type auto-complete ...

[Gary Murphy]

I really thought I'd got it ...

hmapp:NotSchemaNamespaceShape

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

  sh:nodeKind sh:IRI ;

  sh:not hmapp:SchemaNamespaceShape ;

  sh:severity sh:Violation ;

  sh:targetObjectsOf rdf:type ;

.

hmapp:SchemaNamespaceShape

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  dash:stem "http://schema.org" ;

  rdfs:subClassOf owl:Thing ;

  sh:nodeKind sh:IRI ;

  sh:severity sh:Violation ;

  sh:targetObjectsOf rdf:type ;

.

schema:Thing

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

...

  rdfs:subClassOf owl:Thing ;

  sh:not hmapp:NotSchemaNamespaceShape ;

.

my apologies if this is something totally obvious, but it's my first shot at shacl constraints and I'm only a few into my sparql adventures.

And I have another naive novice question: why can I not link the shape constraint directly to the property rdf:type?

[Holger Knublauch]

To help my understanding of your use case: Do you want to

a) restrict a property to values that have an rdf:type from the schema.org namespace? (That could probably be achieved via sh:class schema:Thing)
b) restrict a property to classes from the schema.org namespace (i.e. the values itself are classes)

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.
For more options, visit https://groups.google.com/d/optout.

[Gary Murphy]

I think it would be B -- in an edit form I use swa:Objects to allow changing or adding additional rdf:type classes, but would like to restrict the auto-complete listings to only include classes within the schema.org namespace, so I'm restricting a property where the values are classes.

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-users+unsubscribe@googlegroups.com.

[Holger Knublauch]

Hi Gary,

to support solution b), see the attached example. The SWA auto-complete widget currently requires sh:not to be used to point at shapes that the given matches do not conform to. You can exclude any non-schema.org resource by wrapping a dash:stem into another sh:not, as outlined. (I only tested with the upcoming 5.4 release, hoping the version that you have behaves similarly).

HTH
Holger

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

[Gary Murphy]

Thanks for that example; I'm encouraged to see that I was essentially following the right path, however the essential difference is that your method works ;) -- I think I may be limited in this by the TB version as I'm trying to make this work in 5.2.2 where sh:NodeShape and dash:stem are both missing.

[Gary Murphy]

Hoping to break it down, I did try

sh:not [

a sh:Shape ;

sh:not [

sh:property [

sh:class schema:Thing ;

sh:path rdf:type ;

] ;

] ;

]

which does throw constraint violations when the data item is saved, which should prove that the rule works ...

Value does have shape [ a sh:Shape ; sh:not [ sh:property [ sh:class schema:Thing ; sh:path rdf:type ; ] ; ] ; ]

but sadly does not trigger dropping those invalid classes from the auto-complete list.

[Holger Knublauch]

Hi Gary,

it might be best to wait for 5.4 on this. The area around SHACL has evolved quite a bit since 5.2. (We are near the code freeze for 5.4 at this stage).

Holger

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

[Irene Polikoff]

Strongly recommend upgrading. At the time of 5.2.2 some aspects of the standard were still evolving.

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

[Gary Murphy]

Thanks, I am contemplating the upgrade but there were so many asset changes going into 5.3 I still haven't got it completely up to where my 5.2 work is.

sh:stem appears to do what dash:stem does and the constraint will trigger an alert, but I guess I'll wait for the upgrade for auto-complete to tie into that.