W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > June 2020

Re: How to refer to individual SHACL shapes to which a data graph conforms?

From: Irene Polikoff <irene@topquadrant.com>
Date: Wed, 17 Jun 2020 14:55:58 -0400
Cc: public-rdf-shapes@w3.org
Message-Id: <008034BE-FDA3-4F0D-B156-392F65D6F96A@topquadrant.com>
To: Christoph LANGE <math.semantic.web@gmail.com>
It is expected that owl:imports in a data graph is used to refer to a shapes graph data is based on. 

Of course, the shapes graph could contain shapes that go beyond what is in the data e.g., data may be about people and the shapes graph has shapes for people as well as companies. But typically ontologies (by ontologies, I broadly mean schema definitions in SHACL) are modular and organized based on the domain of interest.

Further, shapes target data and the most common target uses classes. Thus, it is easy to figure out the relationship between shapes and instance data and vice versa - simply follow the target. 

A shape like the one below does not “do” anything without the target. One very pattern is to specify targets together with the shape - either explicitly or implicitly be declaring a node shape to also be a class. 

When shapes are re-used for different data, you can declare your class as a subclass of the target class.  This would look as follows:

Shapes Graph 1:

> ex:TemperatureDataShape
>  a sh:NodeShape , owl:Class; #or rtfs:Class and/oryou could also say sh:targetClass ex:Temperature where ex:Temperature is a class that is not a node shape if, for some reason, it is important to separate the two
>  sh:property [
>    sh:path ex:unit ;
>    sh:datatype xsd:string ;
>    sh:in ( "C" "K" "F" ) ;
>  ] .

Shapes Graph 2 owl:imports Shape Graph 1 and adds:

> ex:TemperatureDatapoint
>  rdfs:subClassOf ex:TemperatureDataShape. #or subclass of ex:Temperature

Data Graph 1 owl:imports Shapes Graph 2 and contains data that corresponds to the shape.


If this is deemed to be "too close of the binding”, then second re-use pattern recommended by the working group is to layer the target definitions in a separate graph. With this pattern, shapes would have no targets and different targets could be specified by different communities.

Thus you would have something like:

Shapes Graph 1:

> ex:TemperatureDataShape
>  a sh:NodeShape ;
>  sh:property [
>    sh:path ex:unit ;
>    sh:datatype xsd:string ;
>    sh:in ( "C" "K" "F" ) ;
>  ] .

Shapes Graph 2 owl:imports Shape Graph 1 and adds:

> ex:TemperatureDataShape
>  sh:targetClass ex:TemperatureDatapoint.

Data Graph 1 owl:imports Shapes Graph 2 and contains data that corresponds to the shape.



> On Jun 17, 2020, at 1:59 PM, Christoph LANGE <math.semantic.web@gmail.com> wrote:
> 
> Dear all,
> 
> tl;dr: rather than pointing to an entire _graph_ of SHACL shapes (i.e., using sh:shapesGraph), is there a standard way of pointing to a few individual shapes?  The use case is to retrieve datasets that match a given shape or a small set of shapes – because the maintainer of the dataset asserted so (and, say, this assertion was confirmed by validation), or because a graph matching algorithm found a match, or whatever, we don't care.
> 
> Long version: this question has come up in the context of the International Data Spaces (IDS, https://www.internationaldataspaces.org/), an architecture for trusted, secure and of course semantic data exchange.  The IDS Information Model (https://github.com/International-Data-Spaces-Association/InformationModel/), which I am maintaining, is an ontology based on various W3C standards, including DCAT, ODRL, SHACL, etc.
> 
> The IDS Information Model goes beyond metadata for datasets-as-a-whole (dcat:Dataset) in that it also supports talking about the structure and semantics of the _content_ of datasets.  Not by re-inventing the wheel, but by recommending best practices of how to reuse VoID, Data Cube and SHACL (cf. https://github.com/International-Data-Spaces-Association/InformationModel/tree/develop/examples/domain-specific-semantics-using-SHACL).
> 
> E.g., when a dataset contains data points with temperature measurements, whose unit is expressed as a string out of { "C", "K", "F" }, we can say that the dataset has a sh:shapesGraph, which contains a shape like this:
> 
> ex:TemperatureDataShape
>  a sh:NodeShape ;
>  sh:property [
>    sh:path ex:unit ;
>    sh:datatype xsd:string ;
>    sh:in ( "C" "K" "F" ) ;
>  ] .
> 
> (My point here is not to discuss the best way of modelling such data, but to provide a simple example.)
> 
> More recently, we have thought about _retrieving_ from, well, think of a dcat:Catalog, datasets that match a given shape.  See https://github.com/International-Data-Spaces-Association/InformationModel/tree/develop/examples/queries-using-sparql for the overall idea, https://github.com/International-Data-Spaces-Association/InformationModel/blob/develop/examples/queries-using-sparql/SparqlQueries/src/main/resources/1_LIFE_EXPECTANCY_RESOURCE.ttl#L301 for the SHACL shapes, and https://github.com/International-Data-Spaces-Association/InformationModel/blob/develop/examples/queries-using-sparql/SparqlQueries/src/main/resources/1_LIFE_EXPECTANCY_RESOURCE.ttl#L61 for how we are linking the dataset to them.
> 
> Rather than inventing our own property ids:relatesToShape, we would like to use something that conforms to the SHACL standard.  At the very least, we would like to align our own property with the standard, e.g., saying that, whenever a dataset ?d has a sh:shapesGraph, which contains (*) a resource ?r of rdf:type sh:Shape, then ?d ids:relatesToShape ?r. But even for expressing the situation (*), i.e., a graph containing a resource, I am not aware of any standard property.  There is rdfg:subGraphOf, but not, say, rdfg:memberOf.
> 
> It should be possible to perform the given retrieval task with a SPARQL query over the dataset's metadata and the SHACL shape(s).
> 
> What would you recommend?
> 
> Many thanks in advance for your help,
> 
> Christoph
> 
> -- 
> Dr. Christoph Lange
> Fraunhofer FIT: Head of Knowledge Pipelines Department
> http://langec.wordpress.com/about/, Skype duke4701
> 
Received on Wednesday, 17 June 2020 18:56:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 17 June 2020 18:56:14 UTC