On 12/07/2019 09:49, Rob Atkinson wrote:
Hi - I have been thinking about this too - it seems a challenge in an
"open world" or with large reference data sets.
sh:Class allows you to define an acceptable Class, which all your
country codes belong to - but to use this it means importing all the
content, (with explicit rdf:type declarations) into the graph with the
SHACL rules - this wont scale to a bigger dataset - such as biological
species, or even car models.
I wouldn't see that as a problem. The validation of sh:class happens in
the *data graph*, i.e. instances. The shapes graph only need the class
reference, e.g.
sh:class ex:Country
would suffice in the shapes graph, and only the data graph needs to
owl:import the actual instances of ex:Country.
Regardless of where these instances live, sh:class would be insufficient
to express that *only* those values are permitted for any data graph. So
for example, another data graph may owl:import additional ex:Country
instances, or even just define them itself. The only built-in mechanism
to cover finite enumerations in SHACL core would be sh:in, but that will
not scale for large data sets, and is not very modular.
I believe this indicates the need for another SHACL constraint
component, which could have a syntax such as
ex:Address
sh:property [
sh:path ex:country ;
sh:class ex:Country ;
ext:graph <http://my-dataset.org> ;
ext:classInGraph ex:Country ;
] .
This constraint component would take a graph and a class as arguments,
and then only permit the instances from the given graph. Such a
constraint component is reasonably easy to define in SHACL-SPARQL, and
is thus supported by the official standard, see
https://www.w3.org/TR/shacl/#constraint-components-syntax
The SPARQL query would be something like
ASK {
GRAPH $graph {
$value rdf:type/rdfs:subClassOf* $classInGraph
}
}
(Replacing $graph with the given ext:graph and $classInGraph with the
given ext:classInGraph).
BTW in the example above I left the sh:class statement to help tools
such as input forms to still make sense of the situation - these would
not know much about the semantics of ext:classInGraph.
Maybe if the rules engine is expected to dereference a URI and find
the Class of the instance referenced - but that only works in a Linked
Data world where URIs will return an RDFS profile. This may need a
control on the rule - eg:sh_x:performLookup rdfs:range xsd:Boolean
alternatively maybe a sh_xxx:lookup with options - e.g. a SPARQL query
template that names the graph - or maybe just the graph identifier ?
Yes to the latter, see one such approach above.
Holger
On Friday, 12 July 2019 04:56:44 UTC+10, Fan Li wrote:
For example, if there is an attribute "country code", can I
constraint its value to one of them from the "Country Code"
reference dataset? Thanks!
--
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/1c2bfbbb-4a1d-4630-8b92-7f7d6e54da9f%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/1c2bfbbb-4a1d-4630-8b92-7f7d6e54da9f%40googlegroups.com?utm_medium=email&utm_source=footer>.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/97b14cc9-daa8-eb68-fa44-2333f8304ea5%40topquadrant.com.
For more options, visit https://groups.google.com/d/optout.
