Is it possible for a propertyShape to filter values (IRI's) shown on an EDG form from a set to only show IRI's of specific rdf:type objects ?

[Simon Opper]

Hi brains trust,

We have a model for document part instances ( more detail below), where a resource "contains" other rdf:type(s) of object instances.

Our question is: Can a sh:PropertyShape for a form filter the values of objects e.g. IRIs rendered to only show IRI's from objects of a certain type?

A form drop down list can be constrained easily, but we can't seem to get a label or IRI list to constrain in the same manner.

The out-of-the-box sh:NodeShape method for declaring a label/detailsview/iri property shape slot on a form only says "apply a rule on this class or node and show the result on that classes form"... so it gets all labels or IRIs from the sh:path <IRI> no matter what object types they are. We can't get it to filter to a subset of the available values.

We could just use different object properties for the different references of course. But that's not the issue here. The question about whether it is a good design to have multiple object type instances related via the same object property is a side question which we are assessing. 

We got interested in how to solve this filtering issue regardless.

e.g. 

A section contains another section

but also contains another type of object such as a paragraph

for example

data:node-65837cf4-b533-5ca7-a3e5-b7856278616b

  a doco:Section ;

po:contains data:node-539b227b-1499-59bc-8393-113a03b39b37 ;

 po:contains _:b22620 ;

.

In the case above and all through our data we have contained blank nodes i.e.  _:b22620.

But whether they are a blank node or not isn't yet the crux as far as we can see.

e.g. 

_:b22620

  a doco:Paragraph ;

  co:firstItem [

      co:itemContent data:node-45abae98-e417-5f24-bf73-d1e7ee187818 ;

    ] ;

etc etc etc

.

Currently, we have all instance types using the same object property slot po:contains

doco:Doco

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:label "Doco" ;

  rdfs:subClassOf owl:Thing ;

  sh:property doco:Doco-contains ;

  sh:property <https://data.surroundaustralia.com/def/spar.shapes_mini/doc-items> ;

  sh:property <https://data.surroundaustralia.com/def/spar.shapes_mini/label> ;

.

doco:Doco-contains

  a sh:PropertyShape ;

  sh:path po:contains ;

  sh:class doco:Section ;

  sh:name "contains parts" ;

  sh:nodeKind sh:IRI ;

.

With the example data and the nodeshape above, despite the fact that the blank node (or named resource) is a doco:Paragraph it's IRI is still shown in the form slot.

We've tried various node targets and shacl properties but can't make headway.

Is there a shacl advanced feature, tosh, dash or other function we are missing?

Perhaps we need a triple rule ?  But we are looking for simple answers first..

FYI our data and model for document parts is derived from an implementation of the Spar Ontologies but that's of no real concern for the filtering - except that it impacts whether we have to maintain a single object property for different object types to keep in line with the SPAR vocab set.

Example files are attached to help.

Cheers

Simon

For a given document 

[Holger Knublauch]

If you are asking about a filtered display that shows only some property values (based on their type) but drops others, we have no out-of-the-box solution beside inferring a new property using sh:values rules.

So for example define a new property

sh:property [
    a sh:PropertyShape ;
    sh:path ex:paragraph ;
    sh:values [
        sh:nodes [ sh:path ex:contains ] ;  # start with all values of ex:contains
        sh:filterShape [ sh:class ex:Paragraph ] ; # but only keep those that are instances of ex:Paragraph [1]
   ]
]

and for display purposes mark ex:contains as dash:hidden true. You can produce any number of other virtual "view" properties this way, and our APIs such as GraphQL and ADS/JavaScript provide easy access to them.

Is this on the right track or what else did you have in mind?

Holger

[1] https://w3c.github.io/shacl/shacl-af/#node-expressions-filter-shape

--
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/6491d7a1-0567-42e8-b310-e66bfcd63fd3n%40googlegroups.com.

[Holger Knublauch]

BTW looking at your example, you seem to have two ways of attaching the children - one in a list-like sequence and one as direct property values. An alternative to that is to use reification and dash:indexed, e.g.

ext:RootClass-orderedChildren
  rdf:type sh:PropertyShape ;
  sh:path ext:orderedChildren ;
  dash:indexed true ;
  sh:class ext:Person ;
  sh:name "ordered children" ;
.

and then

ex:Parent1
    ex:contains ex:Child1 [[ dash:index 0 ]] ;
    ex:contains ex:Child2 [[ dash:index 1 ]] ;
...

Holger