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 ... On Wed, Sep 20, 2017 at 2:24 PM, Gary Murphy <[email protected]> wrote: > 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? > > On Wed, Sep 20, 2017 at 1:00 PM, Gary Murphy <[email protected]> wrote: > >> 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? >> > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
