In order to perform any operation in an RDF graph, it is recommendable to know the expected topology of the targeted information. Some technologies have been developed in the last years to describe the expected shapes in an RDF graph, such as ShEx or SHACL. In general, a domain expert can de ne the expected shapes in a graph, but there are some scenarios in which the schema cannot be predicted a priori, but it emerges at the same time that the graph is lled with new information (the shapes are latent). We have developed a prototype which is able to infer shapes of classes in a knowledge graph and used it with classes of DBpedia ontology. We serialize our results using ShEx.
The most common way to perform queries against any Resource Description Framework (RDF) store is using SPARQL. In order to perform an e ective SPARQL query against a Knowledge Graph (KG), one may need to know the expected topology of the KG. A wrong pick of properties, data-types or classes may cause a certain query to ignore relevant information or to update data in a way that does not t with the current KG's topology.
Ontologies de ne the meaning and the correct usage of properties and classes,
but they are not intended to specify the expected shape of a group of nodes in
the context of a speci c KG. In the RDF world, Shape Expressions (ShEx) [
Usually, the topology of a KG can be designed or predicted by domain experts
in controlled scenarios. However, there are situations in which a KG does not
have a planned schema, but the shapes emerge while the content keeps growing.
Insightful examples of that are community-driven approaches such as DBpedia
or Wikidata. In those cases, as suggested in [
We implemented a prototype which is able to infer Shape Expressions
associated to the classes in a KG and applied it on the English chapter of DBpedia3.
Our prototype calculates a score of how trustworthy the constraints inferred
in the shapes are, i.e., how many of the total of instances really conform to it.
Then, it serializes the results using ShEx. Some other works have already studied
emergent schemata in RDF sources[
Our prototype receives as input a list of class URIs from a KG and infers a shape for each class. It works with the following work ow: 1) Find all the instances of the target classes; 2) For each class, nd all the triples whose subject is one of its instances and use them all to build a pro le of the class, consisting of a list of triple constraints4; and 3) turn each pro le into a ShEx. Some con guration can be provided to lter some tripe constraints from the results.
Our prototype has a linear complexity related to the total number of triples of the target classes' instances. However, the underlying algorithm can be parallelized or even adapted to a server process, triggering some changes in a limited number of schemata when there is some update.
Listing 1.1 shows an example of a small RDF graph about countries, and Listing 1.2 presents the shape that our prototype infers from it5. Every triple constraint induced in a shape is associated with a percentage that indicates how many instances of the target class conform with the constraint. The common case 3 The used source code as well as an extended explanation of our experiments is available at https://github.com/DaniFdezAlvarez/dbpedia-shexer 4 Triple constraints are the basic building block in ShEx. They are composed of a property, a node constraint and a cardinality. 5 The pre xes employed in this paper are the common ones that can be resolved by the service http://pre x.cc/ in real scenarios is that not all of the instances conform with a given constraint rule, with the exception of the constraint rdf:type [:nameOfTheClass], which they all share.
Listing 1.1. RDF example graph dbr : Spain rdf : type dbo : Country ; dbp : capital dbr : Madrid ; rdfs : label " Spain " ; rdfs : label " Kingdom of Spain " . dbr : France rdf : type dbo : Country ; dbp : capital dbr : Paris ; rdfs : label " France " .
Listing 1.2. Example Country Shape : Country { } rdf : type [ dbo : Country ] ; # 100% dbp : capital IRI ; # 100% rdfs : label xsd : string + # 100% # 50% have cardinality {1}
Listing 1.3 shows an example of Country Shape inferred by analyzing the actual content of DBpedia.
: Country g
Listing 1.3. Country Shape (trustworthiness of 80%) r dff : type [ dbo : Country ] ; # 1 0 0 . 0 % dbo : wikiPageID xsd : i n t e g e r ; # 9 7 . 1 0 8 % owl : sameAs IRI +; # 9 6 . 9 3 3 % f o a f : name xsd : s t r i n g +; # 9 6 . 7 5 8 % dcterms : s u b j e c t IRI +; # 9 6 . 0 2 8 % dbo : d i s s o l u t i o n Y e a r xsd : gYear +; # 8 3 . 1 4 8 %
# 8 2 . 5 9 3 % have c a r d i n a l i t y f1g dbo : foundingYear xsd : gYear +; # 8 2 . 0 0 9 %
# 8 1 . 4 5 4 % have c a r d i n a l i t y f1g dbp : c o n t i n e n t r d f : l a n g S t r i n g + # 8 0 . 6 0 7 %
# 8 0 . 3 4 4 % have c a r d i n a l i t y f1g
The main features of our prototype are the following: Trustworthiness score. Every triple constraint inferred is associated with the relative amount of instances that t with it. We provide that information in a comment. That allows for sorting the constraint w.r.t. its trustworthiness, as well as ltering constraints that are not frequent enough. The threshold to accept or reject a constraint w.r.t how trustworthy it is can be con gured. Literals and IRIs recognition. All kinds of literals are recognized and treated separately when inferring the constraints. In case a literal is not explicitly associated with a type in the original KG, xsd:string is assumed. If the object of a triple is an IRI, the macro IRI is used to represent it in the inferred constraints. Special treatment of rdf:type. The only exception to the previous feature happens when analyzing triples whose predicate is rdf:type. In those cases, we create a triple constraint whose object is a value set containing a single element, which is the actual object of the original triple. We introduced this exception just for rdf:type because we consider that the information related to typing is specially relevant for the context. Two classes with a high number of overlapped instances may have also a highly overlapped schema. Future versions of this prototype will allow to customize which properties point to value sets.
Cardinality management. Some of the triples of a given instance may t in an in nite number of constraint triples with the same predicate and object but di erent cardinalities. For example, if an instance has a single label, that makes it t with in nite triple constraints of the form frdfs:label xsd:string Cg, where C can be f1g, +, f1,2g, f1,3g,... At this stage, our prototype considers rules with exact cardinality or + closure. We avoid using rules with * closure because every triple constraint with that cardinality will match with 100% of the instances, not mattering the predicate or the object of the constraint.
When serializing the shapes, our prototype can be con gured to prioritize the least speci c cardinality or the most speci c one if its trustworthiness is high enough. Information about cardinality which is not given in the constraint itself is provided through comments. 3
We have applied automatic inference over DBpedia to discover latent Shapes associated to classes of the DBpedia ontology using a statistical approach. We have serialized the latent shapes using ShEx, which can be useful as a guideline on how to manipulate the data. Our approach associates a score of trustworthiness to each rule, so it can also be used as a metric of homogeneity of the dataset.
We are presenting a work in progress research. The algorithm underlying our prototype can be extended with extra features, including more complex inferences, such as inter-shape referencing or more precise cardinalities; regular expressions for some literals; or generation of serializations di erent to ShEx, such as SHACL or example SPARQL queries associated to each class. Acknowledgments. This work is partially funded by the Spanish Ministry of Economy and Competitiveness (Society challenges: TIN2017-88877-R)