It uses a new feature of Sparnatural : the ability to act as a single UI facade to multiple SPARQL endpoints. The user visually writes a single query, the query is sent to multiple data sources, and results are aggregated to be presented to the user in a single result set, that includes each result provenance.

This is depicted in the diagram below:

The user writes his query visually in Sparnatural, here « All archaelogical sites where burials have been found, with the name of their discoverer, if known » :

The visual query is translated into SPARQL, and that SPARQL query is sent to each data source in the federation (actually, the user can select the ones he wants to query). This is depicted by the green arrows in the diagram, numbered « 1 ».

The SPARQL query looks like the following; note how it uses complex CIDOC-CRM property paths, such as the highlighted one, while the visual user query was simple:

Each SPARQL service returns a result. This is depicted by the orange arrows in the diagram, numbered « 2 ».

When every endpoint have answered, their results are aggregated into a single result set. This is number « 3 » in the diagram. During this aggregation, an extra column is added in the result set, containing the name of the source from which the result was retrieved.

The user sees the aggregated result; here, the name of the site, the name of its discovered when known, and the source in which the result was found:

This is possible thanks to the catalog configuration of Sparnatural.

Sparnatural can be passed a catalog of SPARQL endpoints in a federation, and in this case, it will send the same SPARQL query to each, and will aggregate the results. This happens for the final query of course, but also during selection of values in the query UI.

There are two main limits of this approach:

• Limit 1 : all sources in the federation must share the same data model, as the same query is sent to every source
• Limit 2 : each source must be independant : there should be no links from one source to another source so that the query can be solved by each endpoint independantly (so actually, no truly distributed linked data)

Those are the reasons I have entitled the post « simple federation facade ». Those 2 hypothesis are met in OpenArchaeo, and they were also met in the case of the (never released) prototype of the Europeana Linked Data taskforce. If you know other cases of data federation in which this is also true, tell us ! (we could actually try the same on a few DBPedia endpoints using the dbo ontology as a pivot model)

Now guess what ? in Sparnatural we have a « query UI to SPARQL » transformation step, thanks to the SHACL configuration of Sparnatural. Basically we can map a UI property on an underlying property path. Then it would not be too difficult to do this mapping on a source-by-source basis, to have different queries sent to each source, from a single query in the UI. The result set structure would be the same, and result set aggregation can still happen. We would then overcome the first limit described above. That’s the next step !

Cet article Sparnatural as a simple data federation facade est apparu en premier sur Sparna Blog.

The possible entities, connections and properties that are shown to the user need to be specified to Sparnatural. This configuration is written in a SHACL specification. This specification encodes both the structure of the knowledge graph (as we want it to be presented to the user), plus some additionnal UI-oriented information, like icons, order of entries, or value selection widgets to use.

How can the SHACL configuration of Sparnatural be produced ? we faced 3 different situations : either we do it manually, or (semi-)automatically, or with an off-the-shelf specification complemented with manual annotations. We will give you a brief description of each possibility below.

Write your SHACL manually (in Excel)

SHACL has one main disadvantage : there is no widely available, free-to-use SHACL editor to create/edit these specs (while Protégé, for example, allows anyone to edit an OWL ontology). To overcome this lack of tool, we are using an Excel-to-SHACL conversion tool, xls2rdf. We (and our users) write the specification in an Excel template, that is then turned in SHACL by an API call to xls2rdf. This is what we described in a previous post.

We have a good documentation on how to design your Sparnatural documentation in Excel, if you want to try it (but see the Hello Sparnatural tutorial first to setup your working test page). And we are here to help if you need to ! (ask questions on the Github repository).

If you are looking for a general-purpose SHACL Excel template, there is one in SHACL Play.

Get your SHACL automatically (statistics included)

SHACL is machine-readable and also writable, so we can use our SHACL generation algorithm to produce a SHACL « profile » of an RDF dataset. The algorithm sends SPARQL queries to identify all classes and properties, with their range, cardinalities, datatype, etc. This SHACL profile can be fed to Sparnatural directly. With an additionnal bonus : it is also very useful to gather statistics of the dataset at this stage. Number of instances of each class, number of occurrences of each property and number of distinct values. Why is it useful ? first because Sparnatural is able to show them in the UI, giving a hint to the user on how many entities of each type exist in the dataset:

second because by knowing how many distinct values exist for a given property, Sparnatural can show either a dropdown list (if there are less than 500) or an autocomplete search field (if there are more).

Also, as a side effect, seeing the profile and statistics of your dataset can help you spot errors (« why does the statistics tells me that this identifier is not always present ? it should be mandatory ! »).

You can also provide the OWL ontology to Sparnatural along with the SHACL specification. Simply pass the 2 files in the configuration of the component. The ontology can be leveraged for 2 things : the hierarchy of classes and properties from the ontology can be used in the Sparnatural UI, and all labels and comments of classes and properties can be read to be displayed in the UI, giving nice defaults if they are not present in the SHACL spec.
This automated SHACL generation was the one used for the Nakala Sparnatural query interface, and here is how the properties look like, you can see it is organized according to the DublinCore properties hierarchy:

Grab an off-the-shelf SHACL specification

Some clients do write and publish SHACL specifications. Yes. This is the case for example for the European Parliament in their open-data portal. They publish the documentation of their data-model with our SHACL Play documentation generator. The specification existed long before we tried Sparnatural on their data. We simply took their specification, loaded it in Sparnatural and… voilà ! it worked seamlessly, but to make it nicer we added in a separate file additionnal icons and tooltips information.

SHACL Synergies

There is a lot of synergies to find with a SHACL configuration in a model-driven perspective. You can publish the documentation, validate data, power your Sparnatural UI, and generate your API JSON schema from the same specification file. And probably much more – what would YOU do with a SHACL specification of your knowledge graph ?

Cet article Sparnatural SHACL configuration : manual, automated, off-the-shelf est apparu en premier sur Sparna Blog.

Après la conférence les supports seront à retrouver sur la section « bibliographie » du site.

J’en profite pour vous indiquer les 2 dernières démos mises au point avec Sparnatural :

• Recherche sur les partitions musicales de la Cité de la Musique / Philharmonie de Paris, modélisées avec FRBRoo + Doremus, pour le projet ScoreBot (chatbot de recherche sur des partitions musicales)
• Recherche/navigation sur la maquette du référentiel d’interopérabilité du médicament. Ce référentiel est publié sur le SMT de l’ANS.

Cet article Sparnatural à SemWeb.pro 2022 le 8 novembre est apparu en premier sur Sparna Blog.

This guide will describe every step you need to know in order to create a Looker Studio Dashboard from SPARQL queries. All along, an example will be shown to illustrate all the steps with screenshots, code text and quotes.

Step 1 : Getting the SPARQL Connector 

Looker Studio does not provide any native connector for SPARQL. But a community connector exists, called SPARQL Connector, made by Datafabrics LLC, that can be used to create the data source. You can find it by searching for community connectors, or use this link. The code is available in this Github repository.

You have to grant access to your Google account for SPARQL Connector before using it. You will be able to find it in the connectors panel, in the Partner Connectors section, for your next queries.

Step 2 : Connect your knowledge graph

From your report, click on “Add Data” on the bottom right of the screen to open the connector panel. Select the SPARQL Connector in the connector panel (you can also search for it by entering “sparql” in the research field).

Then, follow the steps to create your own data source:

• Enter the URL of the SPARQL endpoint (the endpoint must be publicly accessible, without authentication), for example, with DBPedia:

https://dbpedia.org/sparql

• Then enter the SPARQL query, for example the following selects countries, their capital city label and their total population:
  

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX dbo: <http://dbpedia.org/ontology/>
SELECT ?capital_city_label ?country_label  ?population
WHERE {
?capital_city  dbo:type dbr:Capital_city.
?capital_city rdfs:label ?capital_city_label.
?capital_city dbo:country ?country.
?country rdfs:label ?country_label.
OPTIONAL {?capital_city dbo:populationMetro ?population.}
FILTER (lang(?capital_city_label) = 'en')
FILTER (lang(?country_label) = 'en')
}

• For each field on your query, you have to create one field on your data source and select its type. To do so, you have to build a schema like this one:
  

[{"name": "capital_city_label", "dataType": "STRING"},
    {"name": "country_label", "dataType": "STRING"},
    {"name": "population", "dataType": "NUMBER"}]

Be sure your “name” fields match the fields you have on your query in the same order. You have to select the “dataType” you want for each of your fields, but you can change it later within Google Data Studio. Click here to learn more about data types.

Once every field is completed, you have to click twice on “Add”. If everything goes well, the connector panel will disappear and your new data source will appear on the right of the window and is ready to use. It is defaultly named as “SPARQL Connector”.

If you made a mistake while creating your data source, the SPARQL Connector panel can :

• Show an error message, that will indicate you the error type (endpoint, for example)

• Do nothing and you will have to check on your schema to be sure everything is correct.

• Create a data source as it should do, but Google Data Studio can’t use your data source, and show you this message on your chart :

If you click on “See details” Google Data Studio will show you the error type from the connector :

Step 3 : Transform your data 

First, you can change the name of your data source by clicking on the icon on the left of the data source on Google Data Studio (the icon will change into a pencil) to open the data source edition panel.

Then, click on the top left of the new panel where the name of your data source is to modify it.

Change name of the example data source to “Capital city Data (DBpedia)”

You can also change your data source by modifying your parameters in SPARQL Connector. To do so, click on “EDIT CONNECTION”. The SPARQL Connector panel will open with your current parameters and you can modify them.

In the data source edition panel, you can also change the type of your fields so it fits your needs (numbers can be changed as currency, text can be changed as geographic data, etc.).

Be careful of your fields format, you may not be able to use your data anymore. For example, if you have a “,” as a decimal separator, you can change your data type but you won’t be able to use this field as Google Data Studio uses “.” as a decimal separator.

The connector will also apply default values in query results which don’t have a value for a requested field. The default values are 0 for numbers, “” for strings and false for booleans.

The population field on DBpedia has some null values, but the connector transformed all these values into default values (0 for numbers).

You may need to use calculated fields in order to obtain new fields or to transform data. To create one,  click on “ADD A FIELD” on the right side of the same panel. Check the following page from the documentation to learn more about calculated fields.

By using a calculated field, the population data can be switched back to the original values.

In the new panel, choose the name of your new field, enter the formula. To ensure your formula is correct, a green check appears at the bottom of the panel. If not, it will turn into a red cross.

Enter the new field name: « population_recalculated ». Then enter the formula of the field : « NULLIF(population,0) ». In this case, if any population value is equal to 0 in the population field, it will turn into a null value in the calculated field. 

Step 4 : Improve performance with data extraction

Once you manage to create all your calculated fields, you may have some useless fields in your data source. Those fields may decrease the speed of your dashboard. You can use the “Extract Data” to keep the fields you need in another data source that you will use to make your report.

To use it, click on “Add Data” on the bottom right of the screen and select “Extract Data”.

Then, select your data source and the fields you want to keep in your report. You can make many extractions from one data source if you need. 

Choose the data source and keep only 3 fields : “capital_city_label”, “country_label” and “population_recalculated”.

You can also configure the auto-update tool to make sure your extracted data are up to date with the latest version of your data source from SPARQL Connector. In the bottom right of the panel, switch the auto-update button then choose the occurrence of the update (between daily, weekly and monthly).

A data source defaultly named “Extract Data” appears with the fields you selected from the previous data source.

This method only works for data sources, you won’t be able to use it on blended data. Make sure to do the extraction before blending to improve your performance. To learn more about blending, see this page from the Looker Studio documentation.

Step 5 : Create your dashboard 

Here is a quick guide on how to create a chart in Google Data Studio. Check the chart reference documentation for more information about charts available by default.

To build a dashboard, you will need to select a widget first (pie chart, table, histograms, etc.). Click on “Add a chart” on the top of the screen and select the one you need.

Click on “Add a chart” and select a pie chart.

Select your chart on the report, it will open a panel on the right side of the screen where you can see the chart type and modify it. You can select the data to display in the “SETUP” panel. You can also customize the chart with the “STYLE” panel.

Place the chart on your dashboard anywhere you want to see it. Google Data Studio will automatically choose the data source and some fields which fit the charts, but you can choose to modify them in the “SETUP” panel on the right.

Choose “capital_city_label” as dimension and “population recalculated” as metric.

Here is the result of this configuration :

In the “STYLE” panel, you can choose to modify some options in the chart to customize it.

Change the number of slices from 10 to 6 to see the 5 top values + others value.

The chart will change automatically with your new parameters as you change them.

Congratulations, you have successfully made your first chart!Try to get your own data sources with SPARQL Connector, make your own dashboards with Looker Studio, and send us the links !

Cet article Dashboards from SPARQL knowledge graphs using Looker Studio (Google Data Studio) est apparu en premier sur Sparna Blog.

So what you need is to produce a clean JSON structure from your raw RDF triples. And when I mean “clean”, I mean :

• no URIs. Nowhere. No URIs in JSON keys, No URIs in types of entities, no URIs in the value of properties controlled by a closed list; the only places where it is acceptable to see a URI are : to give the id of the entities, and when making a reference to such an id of entity within the graph; even in these cases the URIs can be shortened.
• no fancy JSON-LD keys like @type, @value, @datatype, @id, etc.
• indented.

You have 2 possibilities to do that :

1. You develop a custom script, to either generate a JSON export of your data, or to implement the API that will query the knowledge graph, parse the triples, and generate that clean JSON output.
2. You use JSON-LD framing to automate the production of a clean JSON(-LD) from RDF.

There are 2 nice things about the solution with JSON-LD framing :

1. it can be automated
2. you automatically retain the RDF compatibility – because your JSON will necessarily be JSON-LD. This means you can import your nice JSON directly in a triplestore.

The principle of JSON-LD framing is that you provide a JSON-LD @context with an additionnal frame specification that defines how the JSON should be structured (indented), which entity to include at each level (entities can be filtered based on some criteria), and also which properties to include in each entity.

To start with JSON-LD framing, what you need is JSON-LD. Any JSON-LD. Typically the raw JSON-LD serialization that any RDF library or triplestore will produce; that kind of ugly, messy, full-of-URIs-and-@language kind of JSON. So something like:

(Brrr, scary, no ?)

And then what you need is the JSON-LD playground with the “Framed” tab. This will allow you to test your context and frame specification.

And when deployed in production, what you will need is a JSON-LD library that is capable of implementing the JSON-LD framing algorithm. Implementations are listed here, and you need an implementation compatible with JSON-LD 1.1.

Example files

As an example, I use a JSON-LD file from the French National Library, the one from Les Misérables here : https://data.bnf.fr/fr/13516296/victor_hugo_les_miserables/ (download link at the bottom of the page).

You can download the initial JSON example, the frame specification, and the result in a zip. The zip also contains intermediate frame specifications.

The @context

We’ll start by specifying the JSON-LD context part.

Map @type to type and @id to id

Average developer will wonder what are those @type and @id keys. Re-map them straight away to type and id:

"type" : "@type",
"id" : "@id",


Schema.org and lot of other specifications do that.

What about @graph ?

If you have a named graph at the top, introduced by @graph, my suggestion would be to simply remap it to a fixed key, like « data », or « entities » :

"data" : "@graph",


Map RDF properties URIs to JSON keys

Get rid of any trace of URI or short URIs in JSON keys. Declare a term for every property in your graph. The simplest way to do this is to use the local part of the URI (after last “#” or “/”) as the term. Order the context by the alphabetical order of the terms. Terms for properties will usually start with a lowercase letter.

In corner cases you may end up with the same term (such as in the example bnf-onto:subject and dcterms:subject), so in that case you need a different key, I chose “bnf-subject” here for bnf-onto:subject and kept “subject” for dcterms:subject.

"creator" : "dcterms:creator",
"date" : "dcterms:date",
"dateOfWork" : "rdagroup1elements:dateOfWork",
"depiction" : "foaf:depiction",
"description" : "dcterms:description",


Map classes URIs to JSON terms

Now you want to do the same thing to get rid of any trace of URIs in the “type” of entities. Declare a term for every class in your ontology/application profile. List the classes in a different section than the properties. Terms for classes will usually start with an uppercase.

"Concept" : "skos:Concept",
"Document" : "foaf:Document",
"ExpositionVirtuelle" : "bnf-onto:ExpositionVirtuelle",


 Declare object properties with “@type”: “@id”

Now you want to get rid of all those ugly “id”, we are only interested in listing the values. To do that, modify the mapping of the property (here “depiction”) to state its values are URIs. You need to change the mapping from

"depiction" : "foaf:depiction",

to

"depiction" : { "@value" : "foaf:depiction", "@type":"@id" },

And so parts like this :

"depiction": [
{
"id": "https://gallica.bnf.fr/ark:/12148/btv1b8438568p.thumbnail"
},
{
"id": "https://gallica.bnf.fr/ark:/12148/btv1b9004781d.thumbnail"
},
{
"id": "https://gallica.bnf.fr/ark:/12148/bpt6k5545348q.thumbnail"
}
]

Will be turned into

"depiction": [
"https://gallica.bnf.fr/ark:/12148/btv1b8438568p.thumbnail",
"https://gallica.bnf.fr/ark:/12148/btv1b9004781d.thumbnail",
"https://gallica.bnf.fr/ark:/12148/bpt6k5545348q.thumbnail",
"https://gallica.bnf.fr/ark:/12148/btv1b8438570r.thumbnail"
]

Map datatypes

Now you want to get rid of the @datatype information for literals. If the value of a property always uses the same datatype, which is the case 99,9% of the time, then you can change the mapping from

"property" : "http://myproperty",

to

"property" : { “@id”: "http://myproperty", “@type”:”xsd:date” }

(The example used does not have datatype properties.)

Map languages, with fixed language or when multilingual

Now let’s get rid of the @language. For this you have 2 choices : when the language is always the same for the value, you can indicate it in the context, the same way that you would do for the datatype but with the @language key. So you change from

"description" : "dcterms:description",

to

"description" : { “@id” : "dcterms:description", “@language” : “fr” }

You could even have different terms for different languages, such as :

"title_fr" : { "@id" : "dcterms:title", "@language" : "fr" },
"title_en" : { "@id" : "dcterms:title", "@language" : "en" },
"title" : { "@id" : "dcterms:title" },

or when you have multilingual multiple values, you can make the property a language map by declaring it this way:

"editorialNote" : { "@id" : "skos:editorialNote", "@container" : "@language" },

Which will turn the language code as a key in the JSON output:

"editorialNote": {
"fr": [
"BN Cat. gén. (sous : Hugo, comte Victor-Marie) : Les misérables. - . - BN Cat. gén. 1960-1969 (sous : Hugo, Victor) : idem. - . -",
"Laffont-Bompiani, Oeuvres, 1994. - . - GDEL. - . -"
] },

In that case, watch out for cases where there is a value without language, it will generate a @none key.

Map controlled list values to JSON terms

By now you already get a much cleaner JSON and almost all “unnecessary” URIs have disappeared. But we still have some URI references that we can clean up : the ones that are references to controlled lists with a finite number of values.

We can declare term mappings for those values just like we did to map properties and classes. BUT – and this is the trick, we need to change the property declaration from “@id” to “@vocab” for the replacement to happen. This is documented in the « Type coercion » section of the spec.

In our example, the mapping to languages and subjects are good candidates to be mapped to JSON terms. So we change

"language" : { "@id" : "dcterms:language", "@type":"@id" },
"subject" : { "@id" : "dcterms:subject", "@type":"@id" },


to

"language" : { "@id" : "dcterms:language", "@type":"@vocab" },
"subject" : { "@id" : "dcterms:subject", "@type":"@vocab" },
“fre” : “http://id.loc.gov/vocabulary/iso639-2/fre”,
“eng” : “http://id.loc.gov/vocabulary/iso639-2/eng”,

Shorten remaining URI references

Now the only URIs left are the ids of the main entities in our graph, and references to those ids. Reference to controlled vocabularies with a limited number of values have been mapped to JSON terms. Although we cannot turn all the remaining URIs to JSON terms (because we can’t declare all possible entity URIs in the context), we can shorten them by adding a prefix mapping in the context, in our case:

"ark-https": "https://data.bnf.fr/ark:/12148/",


(I note that there are http:// and https:// URIs in the data, I don’t know why)

The frame specification

So now we have clean values, no URIs, no fancy JSON-LD keys. But we still don’t have a structure indented the way the average developer would expect it; and this is where the frame specification comes into play.

Define indentation and filters (and reverse properties if needed)

The frame specification acts as both a filter/selection mechanism and as a structure definition. At each level you indicate the criterias for the object to be included. In our example we have a skos:Concept (the entry in the library catalog) that is foaf:focus a Work (the Book « in the real world »), and that skos:Concept is the subject of many virtual exhibits. We want to have the Concept and the Work at first level, and under the concept the exhibits. But there is a trick : it is the virtual exhibits that points to the concept with a dcterms:subject, and we want it the other direction : Concept is_subject_of Exhibit, so we need a @reverse property.

To do that, add the following reverse mapping declaration: (don’t modify the existing one):

"subject_of" : { "@reverse" : "dcterms:subject" },

Note the use of « @reverse » to indicate that JSON key is to be interpreted from object to subject when turned into triples.

With that in place, we can write our frame specification, which goes right after the @context we have designed before:

"type" : ["Concept", "Work"],
"subject_of" : {
"type" : "ExpositionVirtuelle"
}

Note how we use the terms defined in the context previously. This is to be understood the following way : « at the first level, take any entity with a type of either Concept or Work, then insert a subject_of key and put inside any value that has a type ExpositionVirtuelle ». This garantees the virtual exhibits objects will go under the Concept, and not above or at the same level. But this is not sufficient, as you will notice if you apply that framing that the Work is repeated under the « focus » property of the Concept, and at the root level. This is because of the default behavior of the JSON-LD playground regarding object embedding (objects are always embeded when they are referenced)

Avoid embedding

To avoid embedding when it is undesired, we can set the « @embed » option to « @never » on the « focus » property, like so :

"type" : ["Concept", "Work"],
"subject_of" : {
"type" : "ExpositionVirtuelle"
},
"focus" : {
"@embed" : "@never",
"@omitDefault": true
}


This tells the framing algorithm to never embed the complete entity inside the focus property, just reference the URI instead.

Also, you will notice the use of « @omitDefault » to true; this tells the framing algorithm to omit the focus property when it has no value. Otherwise, since the Work does not have a foaf:focus property (only the Concept), then it will get a « focus » key set to null.

What about order of keys in the JSON ?

Well, I am sure this can be controlled, either by specifying explicitely all the keys you want, in the order you want them, in the frame specification, or by using an « ordered » parameter to the JSON-LD API, but that is not available in the playground.

If you list all keys explicitely in the frame specification, don’t forget to use wildcards so that any value will match; wildcards are empty objects with « {} »:

"myProperty" : {}

The result

Much nicer no ? This is something you can put into the hand of an average developer.

Automate context generation from SHACL

Do you have a SHACL specification of the structure of your graph ? wouldn’t it be nice to automate the generation of the JSON-LD context from SHACL ? Maybe we could do that in SHACL-Play ? stay tuned !

Probably what we can automate is the context part, which can be global and unique for all your graph, but the framing specification should probably be different for each different API you need; each framing specification will then reference the same context by its URL.

Image : [Encadrement ornemental] ([1er état]) / .Io. MIGon 1544. [Jean Mignon] ; [d’après Le Primatice] https://gallica.bnf.fr/ark:/12148/btv1b53230250h

Cet article Clean JSON(-LD) from RDF using Framing est apparu en premier sur Sparna Blog.

1. développer une nouvelle version de Sparnatural (http://sparnatural.eu/), un éditeur open source de requêtes SPARQL (qui est le langage utilisé pour faire des recherches dans des graphes RDF) ;
2. mettre en place deux démonstrateurs web pleinement opérationnels, pour permettre l’exploration et la recherche intuitives dans des graphes de métadonnées culturelles grâce à des interfaces construites à l’aide de cet outil.

La BnF a donc construit avec Sparna un démonstrateur web pour interroger l’ensemble de ses données RDF, soit tout le contenu de data.bnf.fr. Les Archives nationales (le Lab, en concertation avec le Département du Minutier central des notaires des Paris) ont construit avec Sparna un démonstrateur web qui permet d’interroger les métadonnées décrivant un tiers des archives notariales conservées aux Archives nationales, qu’elles ont préalablement converties en RDF conformément à l’ontologie RiC-O.

Une demi-journée le 17 juin après-midi permettra de présenter en détail les travaux réalisés et les résultats obtenus, puis d’évoquer les perspectives qu’ils ouvrent pour les institutions partenaires et pour d’autres projets.

Elle aura lieu à l’auditorium des Archives nationales sur le site de Pierrefitte-sur-Seine (voir https://www.archives-nationales.culture.gouv.fr/fr/web/guest/site-de-pierrefitte-sur-seine), et sera également accessible à distance via une plateforme de visioconférence.

Le programme de la demi-journée de présentation du projet Sparnatural est désormais téléchargeable depuis l’agenda des Archives nationales (https://www.archives-nationales.culture.gouv.fr/fr/web/guest/235?sia-agenda-parameter=0010111111111) ou directement à https://www.archives-nationales.culture.gouv.fr/documents/10157/277814/Programme+Sparnatural+2022/.

La demi-journée est accessible à tous gratuitement, sur inscription. Pour vous inscrire vous pouvez, soit utiliser le formulaire disponible à https://framaforms.org/inscription-a-la-demi-journee-de-restitution-du-projet-sparnatural-17-juin-2022-1652342598), soit écrire à l’adresse  le-lab.archives-nationales@culture.gouv.fr en précisant si vous viendrez sur place ou si vous participerez à distance.

Cet article Evènement : Sparnatural et les démonstrateurs Archives Nationales + BNF est apparu en premier sur Sparna Blog.

Cet article Supports de formation SPARQL CC-BY-SA est apparu en premier sur Sparna Blog.

Les démonstrateurs qui sont présentés dans cette ne sont pas finalisés (en date du 01/03/2022). D’autres publications, évènements et communication devraient suivre à la fin de ce projet, à partir mai 2022.

Cet article Vidéo Sparnatural : prototypes BNF et AN est apparu en premier sur Sparna Blog.

Here is also nice video showing how to visualize such a SKOS vocabulary in SKOS Play visualization tools.

Thanks to Nikola Vasiljevic and John Graybeal from FAIR Data Collective for this nice integration !

You can check out the Fair Data Collective page on LinkedIn : « Making practical and easy-to-use FAIR data solutions ».

Cet article Fair Data Collective is doing cool things with SKOS Play and xls2rdf est apparu en premier sur Sparna Blog.

Le principe est simple : arriver à exécuter une requête SPARQL puis traiter les résultats correspondants pour en faire un tableau de données. Ce tableau de données pourra ensuite être exporté, combiné, enregistré, comme vous le souhaitez.

Pour illustrer cela nous allons interroger Wikidata au travers de son service d’interrogation SPARQL en utilisant sa première requête d’exemple qui récupère… les chats !

La requête est la suivante, et voici le lien direct pour l’exécuter dans Wikidata :

SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P31 wd:Q146.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 10

Vous pouvez télécharger le job présenté ici dans ce repository Github d’exemple, et l’importer directement dans Talend.

Nous allons utiliser les composants Talend suivant :

• tRESTClient envoie des requêtes HTTP à un service REST et retourne les réponses; en effet, un service SPARQL n’est ni plus ni moins qu’une URL où on passe un paramètre “query”, comme spécifié par le protocole SPARQL.
• tExtractXMLField pour traiter le format XML de réponse SPARQL; en effet, le format de réponse d’un service SPARQL est lui-aussi standardisé, en XML ou en JSON;
• tFileOutputDelimited pour simplement écrire le résultat dans un fichier de sortie.

Création d’un Job

Pour commencer, vous devez créer un nouveau job.

• Faite un clic droit sur Jobs dans le panneau de gauche. choisissez l’option Créer un Job.

•  Remplissez les champs nécessaires de la fenêtre Nouveau Job et cliquez sur le bouton finish.

 Appel SPARQL avec tRESTClient

• Ajoutez au job le composant tRESTClient.
• Cliquez deux fois sur le composant tRESTClient, allez à la propriété Paramètres simple et remplissez les paramètres suivants:

1. URL: L’URL du service SPARQL de Wikidata est https://query.wikidata.org/sparql .
2. Méthode HTTP: Choisissez la méthode HTTP GET
3. Paramètre de la Requête: Nous devons ajouter le paramètre “query”, cliquez sur le bouton plus [+], et dans la colonne Nom entrez “query”. Dans la colonne Valeur vous allez saisir la requête SPARQL.

Attention!  La requête SPARQL est une chaîne de caractères Java, vous devez donc : 1/ L’entourer avec des guillemets doubles 2/ ajouter le caractère d’échappement \ avant les guillemets dans la requête et 3/ écrire la requête sur une seule ligne. Voici la chaîne de caractères correspondante :

“SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q146. SERVICE wikibase:label { bd:serviceParam wikibase:language \"[AUTO_LANGUAGE],en\". } } LIMIT 10”

Transformation des résultats SPARQL avec tExtractXMLField

• Ajoutez dans le projet un composant tExtractXMLField.
• Connectez le composant tRESTClient au tExtractXMLField.

Nous allons paramétrer le tExtractXMLField :

1. Cliquez sur le bouton Modifier le schéma pour ouvrir la fenêtre des colonnes d’entrée et sortie du composant tExtractXMLField.
2. Ajoutez deux nouvelles colonnes Uri et Label de type String avec le bouton plus [+] et cliquez sur le bouton Ok. 
3. Allez à Paramètres simple et modifiez les options suivantes:

• Champ XML: Choisissez le champs “body”, qui est le champ qui contient la réponse à l’appel SPARQL du composant précédent;
• Requête XPath boucle: Saisissez « /sparql/results/result » qui est d’après la spec du format de résultat SPARQL le chemin vers chaque ligne de résultats dans la réponse.
• La table Mapping : c’est ici que tout se joue !!! ce mapping va vous permettre d’associer les colonnes de votre résultat SPARQL au champs de sortie du composant, par le biais de chemins XPath:
  1. Pour la colonne Uri la valeur de la colonne Requête Xpath sera « binding[@name=’item’]/uri »
  2. pour la colonne Label la valeur de la colonne Requête Xpath sera « binding[@name=’itemLabel’]/literal ».
  3. Si la requête SPARQL retournait plus de colonnes, il faudrait ajouter ici les mappings correspondants pour alimenter les autres colonnes du résultat.

 Génération du fichier de sortie

• Ajoutez le composant de sortie tFileOutputDelimited.
• Connectez le composant tExtractXMLField au composant tFileOutputDelimited.
• Paramétrez le composant dans la section de Paramètres simple → Nom de fichier: le chemin dans lequel vous souhaitez sauvegarder le fichier de sortie.

 Lancer le Job

• Allez à la section Exécuter.
• Cliquez sur le bouton Exécuter.

 Profitez !

Naviguez vers l’emplacement du fichier pour le récupérer.

Et voilà le résultat :

Uri;Label
 http://www.wikidata.org/entity/Q378619;CC
 http://www.wikidata.org/entity/Q498787;Muezza
 http://www.wikidata.org/entity/Q677525;Orangey
 http://www.wikidata.org/entity/Q851190;Mrs. Chippy
 http://www.wikidata.org/entity/Q1050083;Catmando
 http://www.wikidata.org/entity/Q1201902;Tama
 http://www.wikidata.org/entity/Q1207136;Dewey Readmore Books
 http://www.wikidata.org/entity/Q1371145;Socks
 http://www.wikidata.org/entity/Q1386318;F. D. C. Willard
 http://www.wikidata.org/entity/Q1413628;Nora

Vous savez donc maintenant comment alimenter Talend à partir d’une base accessible en SPARQL, en quelques clics et sans code ! Cela permet de valoriser votre graphe de connaissances pour l’intégrer dans le reste du système d’information.

Cet article Alimenter Talend avec SPARQL (sur Wikidata) est apparu en premier sur Sparna Blog.