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
On 2021-09-08 4:43 pm, Holger Knublauch wrote:
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
On 2021-09-08 4:09 pm, Simon Opper wrote:
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
<http://www.sparontologies.net/>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
--
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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/6491d7a1-0567-42e8-b310-e66bfcd63fd3n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/6491d7a1-0567-42e8-b310-e66bfcd63fd3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/e31aa23f-9f65-6418-5404-be1eaee74351%40topquadrant.com.
