Support uniforme de types de données personnalisés dans RDF et SPARQL Maxime Lefrançois, Antoine Zimmermann Univ Lyon, MINES Saint-Étienne, CNRS, Laboratoire Hubert Curien UMR 5516, F-42023 Saint-Étienne, France use cases Faciliter l’accès aux formalismes et outils du Web Sémantique pour les entreprises, services Web, et objets contraints

IRIs, Nœuds anonymes et littéraux dans le web des données IRIs permettent de naviguer dans les données liées, jusqu’à découvrir des littéraux Les littéraux encodent une bonne part des données a UNICODE string "hello"^^<world> any IRI

Questions Bien formés ou non ? "bonjour"^^xsd:string "1.23"^^xsd:decimal "bonjour"^^xsd:decimal "darkturquoise"^^css3:color Même valeur ou non ? "1.2e3"^^xsd:double -- "12000"^^xsd:double "darkturquoise"^^css3:color -- "#00CED1"^^rgb:color Plus grand ou non ? "1 cm"^^ex:length -- "5 mm"^^ex:length

Questions Plus concis ou non? [] <size> [ qudt:quantityValue [ qudt:numericValue "17983.2"^^xsd:double ; qudt:unit qudt-unit:millimetre ] ] . vs [] <size> "17983.2"^^<millimetre> . [] ex:p ( ( -4 1 ) ( 3 2 ) ) . vs [] ex:p "[ [ -4 , 1 ] , [ 3 , 2 ] ]"^^ex:2dmatrix . 13 triplets, 4 littéraux 1 triplet, 1 littéral

Les littéraux RDF 1.1 Le type de données xsd:doubleI L(xsd:double I) "1234" "hello" ∉ L(xsd:double I)

Les littéraux RDF 1.1 Le type de données xsd:doubleI L2V(xsd:double I)("1234" ) reals V(xsd:double I) L(xsd:double I) L2V(xsd:double I) "1234"

Les littéraux RDF 1.1 Le type de données xsd:doubleI L2V(xsd:double I)("1234" ) = L2V(xsd:double I)("12.34e2") reals V(xsd:double I) L(xsd:double I) L2V(xsd:double I) "1234" " 12.34e2"

Les littéraux dans SPARQL "1234"^^xsd:double Le type de données xsd:doubleI L2V(xsd:double I)("1234" ) L2V(xsd:double I)("2000" ) reals V(xsd:double I) L(xsd:double I) "1234" "2000"

Reconnaissance des types de données par les moteurs RDF et SPARQL Les moteurs reconnaissent un ensemble fixé de types de données Principalement les types de données XSD Dépend des implémentations Les nouveaux types de données? peu de types de données personnalisés sur le web des données des moteurs ont des points d’extension spécifiques à leur implem de nouveaux types de données font surface "LINESTRING(0 0, 1 1, 1 2, 2 2)"^^<http://www.opengis.net/ont/geosparql#wktLiteral> "Point(33.95 -83.38)"^^<http://www.opengis.net/ont/geosparql#wktLiteral> "<http://www.opengis.net/def/crs/EPSG/0/4326> Point(33.95 -83.38)"^^geo:wktLiteral

Reconnaissance à la volée de nouveaux types de données ? Besoin d’un accord entre l’éditeur du type de données et le moteur RDF/SPARQL Un registre centralisé de types de données ? Ou bien on se base sur les principes du web des données liées comme le suggère la REC RDF 1.1 semantics utiliser des IRI HTTP pour identifier les types de données Lorsque quelqu’un cherche cette IRI, faire en sorte qu’il récupère la définition du type de données

La définition du type de données ? Pas besoin de définir l’ensemble des valeurs Seulement besoin de mécanismes pour vérifier la bonne-forme, l’égalité, la comparaison Module spécifique à un moteur Des fonctions accessibles sur un service web Functions defined in a script Declarative vocabulary-based description

La définition du type de données ? Pas besoin de définir l’ensemble des valeurs Seulement besoin de mécanismes pour vérifier la bonne-forme, l’égalité, la comparaison Module spécifique à un moteur Des fonctions accessibles sur un service web Des fonctions définies dans un script Un graphe RDF qui décrit le type de données avec une ontologie

Support des types de données personnalisés arbitrairement complexes http://w3id.org/lindt <http://ex.org/unit#watt> 1 – utiliser une IRI HTTP 3, 4 – ce code implémente un API pour traiter les littéraux 2 – servir du code exécutable L(D) comparaison <watt> et <kW> L2V(D)

Spécification http://w3id.org/lindt APIs pour les types de données aux espaces de valeurs disjoints APIs pour les types de données dont les espaces de valeurs s’intersectent Contraintes de conformité intra- et inter- types de données

Publication d’un type de données personnalisé simple http://w3id.org/lindt/custom_datatypes#length "1 mile"^^cdt:length "5280 ft"^^cdt:length "63360 inches"^^cdt:length "1.609344km"^^cdt:length "1609.344 metre"^^cdt:length "1.609344E+6 mm"^^cdt:length http://github.com/thesmartenergy/jena Implémentation au cœur de Apache Jena + ARQ

Expérimentation Sur DBpedia 2014 English specific mapping-based properties 819,764 triplets, 21 types de données personnalisés pour des units of measures 223,768 triplets décrivent des longueurs http://dbpedia.org/datatype/millimetre http://dbpedia.org/datatype/centimetre http://dbpedia.org/datatype/metre http://dbpedia.org/datatype/kilometre ( 404) dbpedia:Bathyscaphe_Trieste <http://dbpedia.org/ontology/MeanOfTransportation/length> "17983.2"^^dbpdt:millimetre .

Expérimentation - Datasets Dataset DBPEDIA Dataset CUSTOM Dataset QUDT dbpedia:Bathyscaphe_Trieste <http://dbpedia.org/ontology/MeanOfTransportation/length> "17983.2"^^dbpdt:millimetre . dbpedia:Bathyscaphe_Trieste <http://dbpedia.org/ontology/MeanOfTransportation/length> "17983.2 mm"^^cdt:length . dbpedia:Bathyscaphe_Trieste <http://dbpedia.org/ontology/MeanOfTransportation/length> [ qudt:quantityValue [ qudt:numericValue "17983.2"^^xsd:double ; qudt:unit qudt-unit:millimetre ] ] .

Renvoyer les 100 plus grandes choses Temps de chargement, % full dataset Concision des requêtes, Renvoyer les 100 plus grandes choses Tout en étant plus petites que 5 m, ordonner les résultats du plus grand au plus petit Temps d’exécution des requêtes % full dataset

Support des types de données personnalisés arbitrairement complexes Pour Support des types de données personnalisés arbitrairement complexes Contre Sécurité ? Langage de programmation est surdimensionné ? Précautions Le types de données peuvent mener à de l’indécidabilité ex: L(D) l’ensemble des documents RDF/XML L2V(D) lie un Graphe RDF à l’ensemble des OWL 2 Full ontologies équivalentes

Conclusions Utiliser des types de données personnalisés augmentrait l’interopérabilité sur le web des données Faciliterait la publication de certains jeux de données Première proposition qui vise le support à la volée des types de données arbitrairement complexes Démontré par un type de données pour les longueurs Implémentation sur Apache Jena Spécification et description de l’expérimentation à http://w3id.org/lindt

Perspectives Une bibliothèque de types de données Implémentation sur d’autres moteurs Stratégies pour la comparaison inter types de donnés Explorer d’autres manières de récupérer la définition de types de données Service web Ontologie (e.g., séquence de types primitifs séparés par un caractère)

Supporting Arbitrary Custom Datatypes in RDF and SPARQL Maxime Lefrançois, Antoine Zimmermann Univ Lyon, MINES Saint-Étienne, CNRS, Laboratoire Hubert Curien UMR 5516, F-42023 Saint-Étienne, France use cases Faciliter l’accès aux formalismes et outils du Web Sémantique pour les entreprises, services Web, et objets contraints

Temps de chargement Très proche de QUDT % full dataset Très proche de QUDT Pénalité de 470 ms pour charger le type de données Évalue notre implémentation, pas la démarche

Queries Return the 100 triples that concern the biggest lengths that are lower than 5 m, order the results according to the descending order of the length for DBPEDIA PREFIX dbpdt: <http://dbpedia.org/datatype/> SELECT ?x ?prop ?length ?metres WHERE { VALUES (?factor ?unit) { (0.001 dbpdt:millimetre) (0.01 dbpdt:centimetre) (1 dbpdt:metre) (1000 dbpdt:kilometre) } ?x ?prop ?length . BIND (?factor*xsd:decimal (?length) as ?metres) FILTER(datatype(?length) = ?unit) FILTER( ?metres < 5 ) ORDER BY DESC ( ?metres ) LIMIT 100

Queries for QUDT PREFIX qudt: <http://qudt.org/schema/qudt#> PREFIX qudt-unit: <http://qudt.org/vocab/unit#> SELECT ?x ?prop ?length (?factor*?length as ?metres) WHERE { VALUES (?factor ?unit) { (0.001 qudt-unit:millimetre) (0.01 qudt-unit:centimetre) (1 qudt-unit:metre) (1000 qudt-unit:kilometre) } ?x ?prop [ qudt:quantityValue [ qudt:numericValue ?length ; qudt:unit ?unit ] ] . FILTER( ?factor*?length < 5 ) ORDER BY DESC (?metres) LIMIT 100

Queries for CUSTOM PREFIX cdt: <http://w3id.org/lindt/v1/custom_datatypes#> SELECT ?x ?prop ?length WHERE { ?x ?prop ?length . FILTER(datatype(?length) = cdt:length ) FILTER( ?length < "5m"^^cdt:length ) } ORDER BY DESC (?length) LIMIT 100

Querying time overall better performances % full dataset overall better performances 33% to 47% of DBPEDIA (which hides 4 queries) QUDT has an anchor IRI, to start the search from

Querying time what if we anchor the predicate ? http://dbpedia.org/ontology/Person/height has a greater impact on CUSTOM than QUDT