1

Say that I want to validate insertion of a company promotion in a triple Store using Shex. A possible approach would be to code Shex as in:

:Promotion {
   my-onto:has_person @:Person ;
   my-onto:grants_role @:Role ;
}

:Person {
   a [ foaf:Person ] ;
}

:Role {
   a [ my-onto:CompanyRole ] ;
}

This is a simplification. The problem is that when inserting the data the triple will be something of:

:promotion-123 my-onto:has_person :person-456 ;
               my-onto:grants_role :role-CTO .

and this graph won't pass Shex validation because it lacks all the a triples.

So for defining and documenting what are correct as IRIs in the two relations, it makes sense to have the Shapes but in 90% of all real world scenarios data will come as in the example above without the type (in this example) relation and thus will fail to validate.

What would the correct way of documenting complex and nested shapes for validating RDF but at the same time "disable" some checks a certain points in the graph?

The use case I'm thinking about is when I need to add extra info to "shapes" already existing, using IRIs like owl:NamedIndividuals or constants in an ontology, already existing entities like Persons, companies, etc.

tonicebrian
  • 4,715
  • 5
  • 41
  • 65

1 Answers1

1

You mean that you insert data without rdf:type (a) declarations and the system adds those declarations by some kind of reasoning system.

ShEx doesn't interfere with reasoning systems and doesn't treat rdf:type declarations in any special way. So there could be several approaches for that use case.

One approach is to have add a question mark to the rdf:type declaration as: 

:Promotion {
   my-onto:has_person @:Person ;
   my-onto:grants_role @:Role ;
}

:Person {
   a [ foaf:Person ] ? ;
}

:Role {
   a [ my-onto:CompanyRole ] ? ;
}

which says that a :Person can either not have a rdf:type declaration or if it has a rdf:type declaration, then it must contain the single value foaf:Person.

Another approach could be to have two shapes, one before reasoning to check the input data and another after insertion the data to check the correct behaviour of the insertion process.

Notice that it is possible to have different shapes for the same data that act at different points during the data processing pipeline.

Labra
  • 1,412
  • 1
  • 13
  • 33
  • Let me rephrase the problem. Say that we have geonames loaded in the DB. We want to be sure that a property `:located_in` will only point to a location ALREADY present in the DB. In the Shex validating the insertion we can only say `:located_in IRI;` although we could have a `Location` shape stating that it must contain a relation `a [ geo:Feature];` but somehow the relation between the two has been broken. – tonicebrian May 05 '20 at 06:08