Eero Hyvönen

Norbert E Fuchs

Vanessa Lopez

Eetu Mäkelä

Sébastien Ferré
email: ferre@irisa.fr.

SPARKLIS: An Expressive Query Builder for SPARQL Endpoints with Guidance in Natural Language Editor(s)

Keywords: semantic search, SPARQL endpoint, query builder, faceted search, natural language

SPARKLIS is a Semantic Web tool that helps users explore and query SPARQL endpoints by guiding them in the interactive building of questions and answers, from simple ones to complex ones. It combines the fine-grained guidance of faceted search, most of the expressivity of SPARQL, and the readability of (controlled) natural languages. No knowledge of the vocabulary and schema are required for users. Many SPARQL features are covered: multidimensional queries, union, negation, optional, filters, aggregations, ordering. Queries are verbalized in either English or French, so that no knowledge of SPARQL is ever necessary. All of this is implemented in a portable Web application, SPARKLIS, and has been evaluated on many endpoints and questions. No endpoint-specific configuration is necessary as the data schema is discovered on the fly by the tool. Online since April 2014, thousands of queries have been formed by hundreds of users over more than a hundred endpoints.

Introduction

A wealth of semantic data is accessible through SPARQL endpoints. DBpedia alone contains several billions of triples covering all sorts of topics (e.g., people, places, buildings, species, films, books). Although different endpoints may use different vocabularies and ontologies, they all share a common interface to access and retrieve semantic data: the SPARQL query language [24]. In addition to being a widely-adopted W3C standard, the advantages of SPARQL are its expressivity, especially since version 1.1, and its scalability for large RDF stores thanks to highly optimized SPARQL engines (e.g., Virtuoso, Jena TDB). Its main drawback is that writing SPARQL queries is a tedious and error-prone task, and is largely unaccessible to most potential users of semantic data.

Our motivation in developing SPARKLIS 1 , shared by many other developers of Semantic Web tools and applications, is to unleash access to semantic data by making it easier to define and send SPARQL queries to endpoints. The novelty of SPARKLIS is to combine in an integrated fashion different search paradigms: Faceted Search (FS), Query Builders (QB), and Natural Language Interfaces (NLI). That integration is the key to reconcile properties for which there is generally a trade-off in existing systems: user guidance, expressivity, readability of queries, scalability, and portability to different endpoints.

Section 2 discusses related work on making semantic search more usable. Section 3 presents the principles and architecture of SPARKLIS, and Section 4 illustrates them on a concrete navigation scenario on DBpedia. Section 5 precisely states the capabilities and limitations of SPARKLIS, and Section 6 reports experimental evaluation and impact on real usage worldwide. Finally, Section 7 concludes and draws perspectives. This paper focuses on the functional and nonfunctional properties of SPARKLIS, as perceived by users. Technical details about its internal working can be found in previous papers [6,5].

Related work

There are mainly two approaches to make semantic search more usable: user interaction (UI) and natural language (NL). UI-based systems reuse and adapt UI paradigms to semantic data: hypertext browsing (e.g., Fluidops Information Workbench2 ), query builders (e.g., SemanticCrystal [15]), faceted search (FS) [23], or OLAP [3]. Query builders generally offer more expressivity, but lack readability because they are based on formal languages. Moreover, their guidance is mostly based on syntax, and sometimes on a data schema, but not on actual data, like in FS. Most FS-based systems do not claim for a contribution in term of expressivity, and contribute either to the design of better interfaces and visualizations, or to methods for the rapid or user-centric configuration of faceted views: e.g., Ontogator [18], mSpace 3 , Longwell 4 . Similarly, OLAP-based systems emphasize visualization, and require substantial amount of configuration to extract cubic views over RDF graphs: e.g., Cubix [21], Linked Data Query Wizard [12]. Therefore, their contributions are somewhat orthogonal to ours, and could certainly complement them. A few FS-based systems extend faceted search expressivity: e.g., Slash-Facet [11], BrowseRDF [22], gFacet [9], VisiNav [8], SemFacet [1], OpenLink FS 5 , Vinge Query&Explore 6 . While more expressive than classical FS, those systems are still much less expressive than SPARQL 1.1, and approximately cover basic graph patterns. None of them support union, negation, or aggregation. All except Vinge Query&Explore present only lists of results, rather than tables. That expressivity is reflected by the frequent choice to use trees and graphs to represent the query. Those representations have a good match with SPARQL graph patterns, but do not scale well to express union, negation, or aggregations, unlike natural language.

Natural Language Interfaces (NLI) [16] use NL in various forms, going from full natural language (e.g., PowerAqua [17]) to mere keywords (e.g., NLP-Reduce [15]). In between, there are also controlled natural languages (e.g., Ginseng [15], SQUALL [4]). Systems based on full NL or keywords devote most of their effort to bridging the gap between lexical forms and ontology triples (mapping and disambiguation), and process only the simplest questions, i.e., they generate SPARQL queries with only one or two triples. Most of them support none of aggregations (e.g., counting), comparatives, or superlatives, even though those features are relatively frequent (see QALD-3 challenge [2]).

Some systems integrate the UI approach in NLIs to alleviate the habitability problem [15], in which users have not a precise knowledge about what can be understood by the NLI system, and therefore can be frustrated by syntax errors or empty results. Ginseng [15] uses auto-completion based on the grammar and an ontology. Atomate [25] uses a Controlled Natural Language (CNL) and dynamic forms to guide users in the definition of reactive rules. Those systems can be seen as query builders based on a controlled natural language. They improve the former with readability, and the latter with guidance, but they still lack the finegrained guidance of FS that is necessary to fully solve the habitability problem.

In our objective to reconcile guidance and expressivity, we wanted to avoid some unsatisfactory effects that generally result from the loose integration of two existing approaches. First, we wanted guidance from the beginning, rather than asking users to start with a category (e.g., BrowseRDF), an entity (e.g., Vinge Query&Explore), or a keyword search (e.g., OpenLink FS). Guidance from the beginning avoids the writer's block (blank field with no suggestion), and initial suggestions provide an overview over the whole dataset to users, which is especially valuable when the dataset is unknown. Second, we wanted to directly explore RDF graphs, rather than first extracting a dataset on which standard techniques can then be applied, e.g. faceted search on extracted facets over a selected collection of items (e.g.. Ontogator), OLAP on an extracted data cube (e.g., Linked Data Query Wizard, Cubix). The latter approaches generally require an expert for the extraction part, and strongly limit expressivity for end users. Finally, we want to avoid the habitability problem [15], found in NLIs, in which users have not a pre-

NL query+focus

Fig. 1. The system architecture of SPARKLIS cise knowledge about what can be understood and answered by the system, and therefore can be frustrated by syntax errors or empty results.

Principles and architecture

This section explains how SPARKLIS integrates the principles of Faceted Search (FS), Query Builders (QB), and Natural Language Interfaces (NLI). That integration is summarized by Figure 1, which shows the system architecture of SPARKLIS. The state of the system is determined by the query and focus, where the focus refers to an entity in the query, and is used as an insertion position for applying query transformations. The SPARQL endpoint is used to compute results from the query, and to compute a set of suggestions from the query and results. Each suggestion is a query element that can be inserted at the focus to refine the query: i.e. an entity, a class, a property, or an operator (e.g., an aggregation). The query, suggestions, and results are verbalized in NL for rendering to the user in a readable form. The user can select a suggestion, or activate a control in the query or results, to trigger a query transformation, and reach a new system state.

SPARKLIS re-uses and generalizes the interaction model of FS [23], where users are guided step-bystep in the selection of items. In FS, at each step, the system gives a set of suggestions to refine the current selection, and users only have to pick a suggestion according to their preferences. The suggestions are specific to the selection, and therefore support exploratory search [19] by providing overview and feedback during the search process. To overcome expressivity limitations of FS, and of existing FS extensions for the Semantic Web (e.g., gFacet [9], VisiNav [8], SemFacet [1]), we have generalized it to Query-based Faceted Search (QFS) [6], where the selection of items is replaced by a structured query. The latter is built step-by-step through the successive choices of the user. This makes SPARKLIS a kind of Query Builder (QB), like SemanticCrystal [15]. QBs have the advantage to allow for a high expressivity while assisting users about syntax by listing eligible constructs at each step. In particular, this enables to completely avoid syntax errors. However, the FS-based guidance of SPARKLIS is more fine-grained than in QBs. In fact, SPARKLIS only allows the building of queries that do return results, preventing users to fall on empty results. Note that non-empty results necessarily imply no syntax error, and no vocabulary error as a consequence. That is because system suggestions are computed for the individual results, not for their common class. In fact, SPARKLIS is as much about building answers as about building questions: e.g., adding columns to the table of results by selecting a property, filtering out rows by selecting a value.

To overcome the lack of readability of SPARQL queries for most users, SPARKLIS queries, suggestions, and results are verbalized in natural language so that SPARQL queries and variables never need to be shown to users (see [5] for more details). This makes SPARKLIS a kind of Natural Language Interface (NLI), like PowerAqua [17]. The important difference is that questions are built through successive user choices in SPARKLIS instead of being freely input in NLIs. SPARKLIS interaction makes question formulation more constrained, slower, and less spontaneous, but it provides guidance and safeness with intermediate answers and suggestions at each step. Moreover, it avoids the hard problem of NL understanding: i.e., ambiguities, out-of-scope questions. A few NLI systems, like Ginseng [15], are based on a controlled NL and auto-completion to suggest the next words in a question. However, their suggestions are not fine-grained like with FS, and less flexible because they only apply to the end of the question. In SPARKLIS, questions form complete sentences at any step of the search; and suggestions are not words but meaningful phrases (e.g., that has a director), and can be inserted at any position in the current question. That current insertion position is called focus, and suggestions are specific to each insertion position.

In order to address scalability issues, only a limited number of results are retrieved from the query, and only a limited number of suggestions are computed from the partial results. No ranking is applied to either results or suggestions because it would defeat scalability. Indeed, ordering SPARQL results forces the query engine to iterate over all solutions. How- 7 Give me a writer that has nationality Russians and whose birth date is after 1800 and that is the author of something 8 Give me a writer that has nationality Russians and whose birth date is after 1800 and that is the author of a book 9 Give me a writer that has nationality Russians and whose birth date is after 1800 and that is the author of a number of book 10 Give me a writer that has nationality Russians and whose birth date is after 1800 and that is the author of the highest-to-lowest number of book 11 Give me a writer that has nationality Russians or something and whose birth date is after 1800 and that is the author of the highest-to-lowest number of book 12 Give me a writer that has nationality Russians or Russia and whose birth date is after 1800 and that is the author of the highest-to-lowest number of book ever, a SPARQL engine may exploit an internal ranking to produce best-ranking solutions first. Now, even without ranking, the most frequent classes and properties are more likely to belong to the selected suggestions, and this generally produces good enough selections. The negative consequence of partial results and suggestions is that suggestions may be incomplete, making some queries unreachable. To restore some form of completeness, we have designed an intelligent auto-completion. Auto-completion is a wellknown user interface mechanism that provides guidance and feedback, and has already been adapted to semantic contexts [14,7]. SPARKLIS auto-completion is directly available at the top of each suggestion list, and dynamically filters suggestion lists at each keystroke for immediate feedback. It is intelligent in that it uses a cascade of three stages to ensure completeness relative to user input. At stage 1, the partial list of suggestions is filtered on the client side, which can be done efficiently. At stage 2, if the filtered list gets empty, the list of suggestions is re-computed by sending to the SPARQL endpoint a new query that includes the user filter. This means that the same partial query results are used, but a constraint is put on the expected classes and properties. At stage 3, when the filtered list is still empty, new queries are again sent to the SPARQL endpoint, using the full SPARQL query instead of the partial results, in addition to the user filter. This ensures that all query results are used in the computation of suggestions.

To promote portability, SPARKLIS is entirely based on Web standards. It uses SPARQL endpoints for RDF storage and querying, HTTP requests to query them, JavaScript (JS) for the application code, and HTML5/CSS3 for the user interface. SPARKLIS only needs the URL of an endpoint to explore it, without any further required configuration. Users can however customize the number of results to be retrieved, or the labelling properties to verbalize URIs. Queries to SPARQL endpoints are sent directly from the client browser, using AJAX requests. It makes SPARKLIS independent from a server, hence trivial to deploy, and efficient because all application code runs on the client. When a SPARQL endpoint does not enable cross-domain AJAX requests, another endpoint can be used as a proxy, based on the SERVICE feature of SPARQL. For code safety and development speed, the JS code is compiled from a high-level strong-typed language (OCaml using js_of_ocaml7 ). The source code counts about 5000 lines of code, and the minimized JS code weights about 250kB.

Navigation scenario on Core DBpedia

We detail in this section a navigation scenario using SPARKLIS on Core English DBpedia, the subset of DBpedia limited to classes and properties of the DBpedia ontology, and to English labels. The same scenario can be played on the full DBpedia but with more noisy suggestions because it includes all data from Wikipedia infoboxes. When SPARKLIS is loaded, Fig. 2. SPARKLIS screenshot at step 11 of scenario in Table 1 the Core English DBpedia is the default endpoint, and users can switch to DBpedia, Live DBpedia, or a few other predefined endpoints. Users can also enter the URL of the endpoint of their choice (see at the top of Figure 2).

Table 1 shows the successive queries, as verbalized in SPARKLIS, of a navigation scenario that leads the user in 12 steps to a list of "Russian writers born since 1800, and ordered by decreasing number of written books". That scenario is only one of several possible scenarios leading to the same results: e.g., the birth date could have been constrained before the nationality. At each step, the bold part represents the newly inserted query element, chosen by the user at the previous step among system suggestions, and the underlined part represents the query focus that is used for the next query transformation. The query focus is moved simply by clicking on different parts of the query. The query elements that are suggested for insertion at query focus can be entities (e.g., Russians), classes (e.g., a book), properties in both directions (e.g., is the author of, has birth date), filters (e.g., after 1800), and various modifiers (e.g., number of, or).

Figure 2 is a SPARKLIS screenshot at step 11, during the specification of an alternative nationality for the writer (Russia as a synonym nationality of Russians). The user interface is made of three parts: top, middle, bottom. The top part shows the current query, and highlights the current focus, here something. The first branch of disjunction is transparent to reflect the fact that it is ignored during the construction of the second branch. The bottom part is the result table of the current query, with a column for each entity/value in the query (here: writer, nationality, birth date, and number of books). The focus column, here the nationality, is highlighted. The middle part contains relevant query elements for insertion at the query focus. It is split in three lists. The first list contains entities (URIs) and values (literals) found in the focus column. It also enables the construction of filters over values. The second list contains concepts (classes and properties) that apply to entities/values found in the focus column. The third list contains modifiers that are applicable to the query focus, such as Boolean connectors, aggregation operators, and ordering. Each list provides filtering for quickly locating a query element, and auto-completion for retrieving more matching elements from the endpoint. In addition to selecting a query element to insert it at query focus, the query part under focus can be deleted by clicking the red cross in the query.

Figure 3 is another SPARKLIS screenshot at final step 12. The current focus and suggestions have been hidden by clicking on the query head "Give me", in order to emphasize the query results. Figure 4 shows the SPARQL translation of the current query, which is sent to the endpoint, and is displayed at all times at the bottom of the page for the curious users or for reuse in other Semantic Web tools. Note that the layout, URI abbreviations, and variable names have been designed so as to make those SPARQL queries more human-readable. When users want to come back frequently to the current query, they can get a permalink to reach the current query and results in one click (see button above the query in Figure 3). Entities and values in the table of answers can be inserted in the query, at the focus corresponding to their column. For example, selecting the birth date 1968-04-11 in Figure 3 would replace the constraint after 1800 by the value 1968-04-11.

It also works for aggregated values, so that retrieving all writers having written a given number of books is possible.

Capabilities and limitations

We here detail the capabilities and limitations of SPARKLIS w.r.t. five important properties for user experience: expressivity, guidance, readability, scalability, and portability. From a linguistic point of view, SPARKLIS verbalized queries include: noun phrases, verb phrases, and relative clauses for graph patterns; coordinations for relational algebra (UNION, NOT EXISTS, OPTIONAL); superlatives for ordering; determiners for aggregations; prepositions for some filters; and anaphoras for cycles. All 100 training questions over DBpedia of the QALD-3 challenge [2] fall in the expressivity scope of SPARKLIS. In practice, 9 questions could not be built because they are "out of scope", i.e. have no answers in DBpedia.

SPARKLIS does not address SPARQL updates, nor queries that return graphs (CONSTRUCT). We have proposed a guidance for those, based on query relaxation [10], but it cannot be made scalable on top of a SPARQL endpoint, unless some kind of RELAX operator is added to the SPARQL language [13]. The SPARQL query features that are not yet covered are: GRAPH patterns to select named graphs; nested queries, and in particular nested aggregations; expres-sions to perform computations; and transitive closures of property paths. Nested queries are useful for doing analytics, i.e. to answer questions like "Give me the average number of children per woman, in each country" or "Give me the number of countries per number of official languages". They are difficult because, to avoid ambiguity, one has to specify for each aggregator its nesting level, and its grouping variables (e.g., "per woman", "for each country"). Expressions are also useful for analytical queries, as well as for spatio-temporal queries (e.g., computing distances and durations). For alll uncovered features, it is difficult to make their NL verbalization readable, especially transitivity. We think that transitivity may be best handled by defining new properties with rules: e.g., "An ancestor of a person is a parent of the person or an ancestor of a parent of the person".

Guidance: safeness and completeness

There are two important properties for guidance in query building: safeness and completeness. A safe guidance avoids dead-ends (i.e., empty results) by providing only relevant suggestions, i.e. suggestions that match actual data. A complete guidance fulfills the expressivity potential by providing all relevant suggestions. In a previous work [6], we formally proved the theoretical safeness and completeness of Querybased Faceted Search (QFS), on which SPARKLIS is founded. For scalability reasons, only a subset of results and suggestions might be computed and displayed in SPARKLIS. Guidance completeness is restored through the intelligent auto-completion mechanism (see Section 3). The query focus plays a crucial role in combining high expressivity (see Section 5.1) and guidance completeness. It determines an insertion position, and the suggestions that are relevant to it. It also provides flexibility in the query construction process, allowing query elements to be inserted in many orderings. When the focus is in the scope of an opaque operator (e.g., negation, aggregation), that operator is temporarily ignored in the translation of the query in SPARQL so that results and suggestions can be computed.

The main limitation to guidance completeness lies at the lexical level. If a suggestion (e.g., property spouse) is out of the selected subset, and the user uses autocompletion with a synonym (e.g., "married with"), then the desired query becomes unreachable from the point of view of the user. The schema can have a similar impact when there are several possible representa-tions: e.g., a class is a German vs a property and value has nationality Germany. For best experience, we encourage data designers to limite the number of classes and properties, e.g., by factorizing classes like Ameri-canChristianScientists into descriptions like a person whose occupation is Scientist and whose nationality is America and whose religion is Christianism; and we encourage users to start by freely exploring an unfamiliar dataset in order to get accustomed to its schema and vocabulary.

Another limitation in guidance is that, for a given query, it gives the same suggestions in the same order to everybody, ignoring any user preferences or past usage. This can be a difficulty when the vocabulary is large, like in DBpedia. One could imagine that suggestions that have been selected by the user (or another user of his community) in similar circumstances were ranked higher in the list of suggestions.

Readability: verbalization in natural language

All content elements of the user interface of SPARK-LIS are verbalized in natural language for readability by users unaware of RDF and SPARQL: the query, the suggestions, the column headers, and the entities in the table of answers. By default, URIs are verbalized by uncamelizing their local name (e.g., dbo:birthDate birth date), or by replacing underscores by spaces (e.g., dbr:Barack_Obama Barack Obama). Alternately, users can specify in the configuration panel a property, typically rdfs:label, and a language tag to retrieve URI verbalizations from the endpoint. Class and property local names or labels are assumed to be nouns, but a few common patterns are taken into account: e.g., hasParent parent, partOf (inverse of) part. To verbalize queries, each query construct is first verbalized locally using a fixed syntactic pattern, and syntactic transformations are then applied globally to make the verbalization look more natural. For example, the first verbalization that has a birth date that is after 1800 is transformed into whose birth date is after 1800. In case of cyclic graph patterns, it is necessary for one part of the query to refer to another part of the query. In order to completely avoid the use of unnatural variables, we verbalize variables as anaphoras. For example, in the SPARKLIS query Give me a film whose director is an actor of the film, the noun phrase the film is implicitly the SPARQL variable used for a film. The same variable verbalizations are used to label column headers. SPARKLIS so far offers verbalization in both English and French, and it should be relatively easy to extend it to other languages that have the same syntactic categories, and no declensions (e.g., Spanish, Italian).

It is certainly possible to improve verbalization at the syntactic level, but the main room for improvement lies at the lexical level. For a real improvement, it is necessary to know for each URI all its possible lexical forms, along with their syntactic category (e.g., noun, verb), number (singular/plural), and gender when relevant. The LEMON vocabulary [20] has been defined to that purpose, but lexicons are rarely available. We think that SPARQL endpoint should include their ontology and lexicon so that lexical information can be retrieved along with data, and so that better readability does not come at the price of lesser portability.

Scalability: billions of triples

SPARKLIS is responsive on the largest well-known endpoint, DBpedia, which has a few billions of triples. For a language as expressive as SPARQL, short response times cannot be guaranteed, but from our experience, time-outs are rarely encountered. Among the 91 QALD-3 questions having answers, half can be answered in less than 30s, and the worst one required 109s (wall-clock time including user interaction and system computations but not user thinking). Only one question could not be answered because of a time-out when searching for a YAGO class by auto-completion.

In fact, the scalability of SPARKLIS is mostly limited by the scalability of the endpoint, because SPARQL requests account for most of the computation time. In particular, the lack of a standard way to perform state-of-the-art full-text search over resources, rather than using FILTER, is an important limitation for efficient auto-completion. Note that it may also be possible to optimize SPARQL engines for the particular kind of queries used by SPARKLIS, especially in the case where many users use it on a same endpoint. So far, federated search is not supported by SPARK-LIS, i.e. a single endpoint can be queried at any given time. Distributed evaluation of queries over several endpoints, although supported by the SERVICE feature of SPARQL, raises the scalability issue one order higher.

Portability: no required configuration

SPARKLIS conforms to the SPARQL standard, and requires no preprocessing or configuration to explore an endpoint. It entirely relies on the endpoint to discover data and its schema. However, a few settings can be configured to adapt to differences between endpoints. When an endpoint does not allow cross-domain requests from Web browsers (same-origin policy), a default endpoint located at our institution IRISA is used as a proxy. The use of a proxy can be deactivated, and another proxy endpoint can be specified. By default, results to SPARQL queries are cached for improved performance, but caching can be deactivated, for example in case of frequently changing data. The default limit for query results is 200 and can be changed to adapt to the responsiveness of the endpoint. Similarly for the number of suggested classes and properties. The default language of the interface and verbalization is English, and can be changed to French. By default, URIs are verbalized from their local names. For each of entities, classes, and properties, a label property and language tag can be specified for the verbalization of URIs. The latter is more demanding on the endpoint, and requires it to support BIND patterns.

The limits that we have encountered by trying SPARKLIS on many endpoints come either from the implementation of the endpoint, or from its contents. Some endpoints do not support HTTP requests with the POST method or do not support some essential SPARQL features, such as UNION or BIND. A number of endpoints only contain terminological knowledge, and no instances. We recall that SPARKLIS heavily relies on instances for guidance. Another limitation is when the endpoint does not apply RDFS or OWL inference, so that some suggestions are missing. From its client side, SPARKLIS has no easy way to compensate for this lack of inference.

Evaluation and impact

In previous papers [6,5], we have presented controlled experiments about the expressivity, scalability, and portability of SPARKLIS, and the guidance of query-based faceted search. The main results are recalled in Section 5. A user study in [6] has shown that students without any prior knowledge of semantic technologies and data were able to answer questions involving several classes and properties, disjunction and negation, tree-shape patterns, and cycles in patterns.

In this paper, we analyze real usage of SPARKLIS worldwide. SPARKLIS has been developed since December 2013, and was put online and publicized since April 2014. It continues to evolve -the last version was released in September 2015 -but its user interface has remained very stable over time. Several people became regular users, and provided valuable feedback and suggestions. Important improvement came from needs expressed by those people, e.g., support of blank nodes in answers, use of labelling properties for verbalizing URIs. We collected an anonymous usage log8 from 19/06/2014 to 16/08/2015, where entries are navigation steps. Each step is described by the timestamp, the endpoint URL, the current query, and the user IP. Because IPs are not reliable to identify users and sessions, especially from wireless connection, we also include since 29/10/2014 a session ID that is randomly generated when the application page is loaded. For privacy sake, the user can deactivate the logging (checkbox in the configuration panel), so that the following analysis may underestimate real usage.

As an additional proof of the capabilities of SPARK-LIS, we want to emphasize that SPARKLIS itself was used to explore its own log, and to produce most results below. The log was translated into RDF, and loaded in a local SPARQL endpoint using the Fuseki server. The most useful features were filters, ordering, and aggregation. What we found missing sometimes are nested aggregations (e.g., the average number of steps per session), and the direct visualization of results by charts rather than numeric tables.

Global statistics

Over the 424 days of the log period, SPARKLIS has been loaded 7379 times, hence 17.4 times per day on average. Over the 291 days with session IDs, there have been 2970 sessions with at least one non-empty query, hence about 10 effective sessions per day on average. The total number of steps is 26739, hence 63 steps per day on average. Although only seven endpoints are suggested in SPARKLIS, 176 endpoints 9have been explored with SPARKLIS. About 12000 different queries have been built overall, which means that queries are visited about twice on average. Finally, we have counted 950 different user IPs. This is a rough estimate of unique users because several people may hide behind a same IP (e.g., wireless networks), but it is consistent with the number of views of the YouTube

, etc. All those figures demonstrates that SPARK-LIS is effectively usable and portable. Usage has been relatively regular over the log period with spikes when we gave presentation talks at various venues.

User statistics

In this section, we show and discuss the distribution of users according to several criteria: explored endpoints, built queries (size and used features), and number of navigation steps.

Endpoints. Table 2 shows a shortlist of the 10 endpoints (out of 176) that attracted the most users, as counted by the number of user IPs. The most popular endpoint is the default endpoint, the Core English DBpedia hosted at IRISA. It is closely followed by the reference DBpedia endpoint and its live version. Other popular endpoints cover various topics, in particular bioinformatics with many bio2rdf datasets, and are hosted in countries worldwide (e.g., Chile, Japan, France). There are also 19 endpoints with URL http://localhost..., demonstrating that people are using SPARKLIS for their own local datasets. The other way around, 312 users (33%) have explored more than one endpoint, 181 users (19%) three or more endpoints, and 2 users have explored 11 different endpoints. This demonstrates that SPARKLIS is used as a general purpose tool by a significant number of people. Those figures may be overestimated because of shared IPs, but they are consistent with the fact that many sessions (193, 6.5%), which are necessarily associated to a single user, explore several endpoints (up to 6) one after the other. Queries. Figure 5 shows for each query size the percentage of users who have managed to build a query with a size greater of equal. The size of the query is the number of query elements that must be selected to build the query, and is therefore the minimal number of navigation steps to reach it from the empty query (size 0). The query size ranges from 0 to 29, and most queries have a size under 10. The figure shows that about 50% of users have built a query with size 4 or higher, that still nearly 20% users have reached size 7, and 5% (50 users) have reached size 10. Note that 37 queries out of the 50 QALD-4 challenge have a size less or equal to 4, and the longest has size 8. Those figures demonstrate that most users understood how to interact with the tool, and managed to build non-trivial queries (beyond 1 or 2 elements). Here is an example of query with size 3 on DBpedia: Give me a celestial body that is a galaxy and that has a ngc. It retrieves galaxies along with their NGC number. Another more complex example with size 9 built on the bio2rdf endpoint by 11 different users: Give me a drug that has a title and is the drug of a target-relation that has action inhibitor and whose target has a title and has a specific-function. It returns not onlys drugs, but also the related targets and the specific-functions of each target. The query elements that has a title were not used to filter results but to get a readable label for drugs and targets as additional columns in the result table.

Figure 6 shows for each feature of SPARKLIS' query language the percentage of users that have used it at least once. The SPARQL counterpart of most features should be clear from their names. Copula (modifier that is) corresponds to starting a new constraint (triple pattern or filter) with an already used variable. Property variable (modifier has a relation to/from) corresponds to adding a triple pattern with a new variable in predicate position. Hidden column (modifier any) corresponds to omitting a variable in the SELECT clause. Anaphora corresponds to picking an already used variable. The 5 most popular features correspond to basic graph patterns in SPARQL, and make up the main stuff of queries. Then, we observe that filtering, ordering, and optional come next, and are more popular than logical operators and aggregations, which are used by less than 10% of users. Hidden column is hardly used because it is most useful with aggregation to specify groupings. Anaphora is also hardly used because anaphora suggestions can only occur when the query contains two entities of same type (e.g., two persons related to a film), and when those two entities can be made equal. We think that expressive features are hardly used because they rarely occur in search needs, and because most SPARKLIS' users have only tried a few queries so far. However, we think those are essential, and we dare an analogy with the vocabulary of a natural language: most words are rarely used (cf. Zipf law), but without them a language would be badly empoverished.

Navigation steps. Figure 7 shows for each number of step the percentage of users who have performed at least that number of steps (over one or several sessions). It therefore measures the capability of the tool to retain users in the exploration experience, and to encourage them to come back later. We have not used the number of sessions because a session can vary from the mere loading of SPARKLIS to a long sequence of complex queries. The number of steps is a more reliable measure of user activity. The proportion of steps done by bots seems negligible as the number of steps made by Google and MSN bots is only 39 (0.15%), and only consists in loading SPARKLIS or following Fig. 7. Percentage of users having performed at least some number of steps permalinks. More than 50% of users make at least 7 steps, but 12% of users make no step at all. One explanation for the latter is that half endpoints do not allow cross-domain requests from browsers, even though they are public, and other explanations are that some endpoints are not responsive enough or do not support essential SPARQL features or have no instances. The cross-domain issue has been solved with a proxy endpoint on mid-December 2014, and as a result the proportion of no-step users has decreased from 15.3% to 8.6%. At the other end of the spectrum, 10% of users have performed 60 steps or more, and one user has even reached 1400 steps. Those numerous steps are generally partitioned in several sessions over different days: 56 (6%) users have used the tool on 3 different days or more, and one of them has used it on 57 different days! Looking at the queries that they have built, it appears that those active users are clearly human, and pursuing sensible search goals. The above figures show that adoption by users is still relatively low, and that most users have only "played" with the tool. While a few users have adopted it for encyclopedic searches on DBpedia, many adopters use it on domainspecific datasets (e.g., bioinformatics, local datasets). We therefore think that adoption is strongly linked to the availability of endpoints interesting users.

Comparing user profiles

An interesting question is how different kinds of users compare in their usage of the tool. Unfortunately, the anonymous log provides no personal information on users such as sex, age, or technical background. It is also difficult to discriminate users according to their competency because they used the tool with different purposes: just trying the tool, reproducing the given examples, answering simple information needs on en- 4 Statistics about two groups of users: DBpedia and bio2rdf Fig. 9. Compared percentage of users building queries up to some size cyclopedic endpoints, or making professional use on domain-specific endpoints. We have therefore decided to compare two groups of users that differ on a clear criteria: the target endpoint.

We compare users on any DBpedia-related endpoint (hobby usage) with users on any bio2rdf-related endpoint (professional usage). Note that a same person may belong to either group at different times. Table 4 gives a few statistics on the two groups. It shows that users of the two groups made a similar number of steps on average, but that bio2rdf-users built more complex queries: on average, the most complex query each user built had 4.6 elements, compared to 3.8 for DBpediausers. We also performed the same statistics as in previous section for each group, and compared their charts. For the area charts about query size and number of steps, the bio2rdf group is consistently above the DBpedia group. Most notably, Figure 9 shows that the proportion of users producing queries with size 7-9 is double (e.g., from 15% to 31%). Similarly, the proportion of users performing 15-20 steps is 1.5 times higher (e.g., from 26% to 40%); and the proportion of users having used the tool on several days jumps from 12% to 24%. Looking at query features, bio2rdf-users used slightly more properties (which can be explained by the higher query sizes), more filters and disjunctions, but less ordering and aggregation. Note that the frequency of aggregation in the DBpedia group is raised and that has a thumbnail by users reproducing example queries or testing the different modifiers. In total, the differences in the use of features are small, and not much can be concluded from them.

Search profiles and examples

In this section, we analyze more in depth user searches as sequences of queries over time. We de-fine searches as normalized sessions. A search is a maximal subsequence of a session starting with the empty query, and having at least one step. This results in 2353 searches. Some users make long breaks (e.g., lunch break) in their search, so, to ease comparison of searches, we compress breaks to 1 minute. Figure 8 shows the query size as a function of elapsed time (in minutes) for all searches. Most searches cannot be read individually, but the chart clarifies the correlation between user time, and query size, hence query complexity:

queries with size 10 can be generated in less than a minute (short searches); queries with size 20 or more can be generated in 2-5 minutes (complex searches); a number of searches last up to 15 minutes, but generate queries with size less than 10 (long searches); most searches are less than 3 minutes, and generate queries with 5 elements at most.

The short searches can be interpreted as directed searches, where the user has a clear information need in mind. For example, one of the most frequent users built a query with size 9 in only 9 steps and 17s. The query is in bioinformatics, and searches for "studies where miRNAs show a decreased expression w.r.t. transcripts". The long searches can be interpreted as exploratory searches, where the user either gets familiarized with the dataset or the tool, or is answering a row of related questions. For example, a 3min search explores volcanos in DBpedia, finding their eruption years, ordering them to get the most recent and most ancient eruption years, then looking at places that have a volcano as highest place, and finally retrieving their elevation, and finding the highest ones. The complex searches are directed search, like short searches, but, because of their complexity, they require some exploration, and hence more steps and more time. They only concern domain-specific datasets, and correspond to actual information needs. We contend that the queries generated by those searches would have been very difficult or impossible to produce with other tools. For example, a user has built a query with size 19 in 36 steps and 4 minutes. It is applied to his/her own dataset about real lecturers, students, and courses. The search starts from a lecturer, retrieves the courses it teaches, and then some students of a Semantic Web course, and finally finds PhD students among them along with their thesis subject. Searches less than 3 minutes and less than 5 elements can be either non-complex directed searches or short exploratory searches. They can also be unsuccessful searches with lots of trial-and-errors, and hesitations. Unfortunately, it is difficult to tell apart exploratory searches and unsuccessful searches because they have similar profiles. By examining in detail a number of searches, it appears that user mishandlings are not so frequent during interaction, and that the main obstacles are at start time. There are many void sessions because of unresponsive endpoints, and many very short sessions because users apparently test the tool with only a few random steps. The most common user mishandlings are:

-redundant steps, i.e. steps that does not make the query wrong but unnecessarily complex (e.g., a thing that is a thing that ..., a thing or a thing);

-bad logic, i.e. misinterpretation or wrong combinations of logical operators (e.g., not optionally, optionally not, optionally used to represent uncertainty); -ordering/aggregation confusion, i.e. using the minimum aggregator instead of the lowest-to-highest ordering; -overuse of string filters, i.e. inclination to use the tool like a search engine or a natural language interface.

Based on those observations, we have improved SPARKLIS' guidance with a tighter selection of suggested modifiers based on the query syntax and current focus, in order to eliminate most redundant steps and bad logic. For example, when the focus is on the phrase a thing, the disjunction modifier or is no more suggested; and when the focus is on (or in the context of) a negation or optional, the modifiers not and optionally are no more suggested either. Table 3 details an example session about cars on Core English DBpedia. It shows an untrained user first learning by trial and error, and finally reaching a useful query of size 6 after 14 steps and less than 5 minutes. At step 1, he tries to filter individual entities with keyword "car", which does not work as expected. At step 3, he finds the class that interests him, an automobile. After exploring tentatively from property class, he seems to really get the trick at step 10, from which he reaches the final query in a straight line. He gets the cars he is looking for, along with a picture of them.

Conclusion and perspectives

SPARKLIS provides a stable and working answer to a frequent question in the Semantic Web: "How to explore and query a large unknown endpoint beyond the most simple queries without reading or writing any SPARQL, and without preprocessing or configuration ?". Because of a novel interaction paradigm combining faceted search and query builders, user studies have shown that users need to learn how to use it, but that after a short training, they can answer complex queries. Complex queries such as analytical queries involving multiple dimensions, aggregations, and filters, are only a few clicks away, under safe and complete guidance. Moreover, guidance is entirely mediated through natural language.

In the future, we will continue to maintain and improve SPARKLIS, especially w.r.t. expressivity and readability. For expressivity, we plan to cover almost all of SPARQL 1.1, i.e. to add expressions for computations, nested aggregations for rich analytics, and graphs as results for CONSTRUCT queries and updates. For readability, we plan to improve verbalization with lexicons, to extend multi-lingual support, and to better display results by generating full sentences enriched with multimedia objects (e.g., pictures), and graphical visualizations (e.g., charts, maps).

Fig. 3 .Fig. 4 .

 34 Fig. 3. SPARKLIS screenshot at final step 12, hidding suggestions

5. 1 .

 1 Expressivity: large subset of SPARQL 1.1 SPARKLIS is concerned with the SELECT and ASK forms of SPARQL queries. It covers many features of SPARQL: basic graph patterns, including cycles; simple filters on strings, numbers, dates and times, language tags, and datatypes; UNION patterns; OPTIONAL patterns; NOT EXISTS constraints; ORDER BY clauses; multiple aggregations with GROUP BY and HAVING clauses. Triple patterns with a variable in predicate position are also covered through the suggestions that has a relation to ... and that has a relation from ..., where a relation stands for a property placeholder. The focus can then be put on it, and all kinds of constraints can be applied to it through SPARKLIS navigation. Blank nodes are correclty handled. They are shown in results, and suggestions are given about them, but they cannot be inserted in the query.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Percentage of users building queries up to some size (truncated at size 13, maximum size is 29)

Fig. 8 .

 8 Fig. 8. Query size as a function of elapsed time (min) for all search episodes

Table 1

 1

	Navigation scenario in SPARKLIS over DBpedia
	Step Query
	1 Give me something
	2 Give me a writer
	3 Give me a writer that has a nationality
	4 Give me a writer that has nationality Russians
	5 Give me a writer that has nationality Russians and that has a birth date
	6 Give me a writer that has nationality Russians and whose birth date is after 1800

Table 2

 2 Most popular endpoints (number of user IPs)

	endpoint URL	#user
	demo (612 on 16/08/2015). It is noticeable that the lat-
	ter was seen from 49 countries: France (175), United
	States (82), Germany (45), Italy (37), UK (25), Russia

Online at http://www.irisa.fr/LIS/ferre/sparklis/ 1570-0844/0-1900/$27.50 c 0 -IOS Press and the authors. All rights reserved

http://iwb.fluidops.com/

http://mspace.fm/

http://simile.mit.edu/wiki/Longwell

http://dbpedia.org/fct/facet.vsp

http://www.vingefree.com/querybyexplore/

http://ocsigen.org/js_of_ocaml/

Available online without user IPs, and restricted to DBpedia and bio2rdf endpoints at http://www.irisa.fr/LIS/ferre/pub/sparklis_querylog.dat.

 9 We only count endpoints that were responsive, and for which at least one navigation step could be performed.

Acknowledgements. We thank the reviewers for their insightful suggestions that helped to improve this paper, in particular the evaluation section. We also thank the users who contributed to improve the tool itself with their feedback.

This work is supported by ANR project IDFRAud.


* Doctorant

pour rendre le code informatique apparent)

Dater d'après le cachet » Une approche méthodologique pour les cachets circulaires hittites

Introduction

Utilisés depuis des millénaires, les cachets gravés d'initiales, de titres ou d'emblèmes, en creux ou en relief, servent à sceller des objets pour en attester l'authenticité et en contrôler l'ouverture. Pendant la période du Bronze récent, ce sont les cachets circulaires et les sceaux-bagues qui sont utilisés au nord de la chaîne des monts Taurus, en pays hittite. Les études sigillographiques des cachets hittites, débutées il y a plus d'un siècle, ont largement contribué à la découverte et à la connaissance de cette civilisation.

Chaque cachet est unique, identifiable par sa légende et son iconographie, et témoigne aussi bien de pratiques administratives que du context culturel (figures 1 et 2). Cependant, rares sont les cachets (ou leurs impressions) datés grâce à leur contexte de découverte. Souvent, ils proviennent de couches d'érosion. Leur datation -hormis les sceaux royaux -repose essentiellement sur l'étude iconographique. C'est le mérite, entre autres, de R. M. Boehmer d'avoir classé de manière rigoureuse les sceaux hittites en périodes, grâce à une étude stylistique qui sera reprise et complétée ici 1 . Ces travaux cherchent à cerner un problème de variabilité : quelle typologie établir pour grouper les cachets et les ordonner chronologiquement ?

Le découverte en 1990-1991 d'un lot de plus de 3000 empreintes de sceaux dans la capitale hittite Ḫattuša et publiées de manière remarquable ont renouvelé nos connaissances de la glyptique anatolienne 2 . Une telle masse de documents a brusquement quadruplé le nombre de scellés découvert en un siècle à Boğazköy 3 . Le corpus de Nişantepe a permis d'affiner le classement chronologique et d'attribuer quelques sceaux à deux périodes : le début de la période hittite impériale (ca XIVe s.) et la fin de la période hittite impériale (ca XIIIe s.) 4 . De la même manière, la mise au jour de sceaux dans des provinces de l'empire hittite et les progrès accomplis dans lecture des hiéroglyphes contribuent au renouveau de nos connaissances 5 . En contre partie, en l'absence de synthèse récente et vu les nouvelles découvertes, la remise en question des anciennes interprétations et datations reste difficile. Partant de ce constat, le recours à une approche statistique descriptive multidimensionnelle offre la possibilité d 'observer, d'explorer et de valider (ou d'invalider)

Exploration multidimensionnelle

L'idée de cette étude est de représenter la variabilité des cachets circulaires hittites afin de souligner l'unicité de chaque sceaux mais aussi leurs caractéristiques communes. J'ai opté pour une étude de différentes variables selon une Analyse en Composantes Principales (A.C.P.) et une Analyse Factorielle Discriminante (A.F.D.)6 . Ces analyses permettent d'étudier des individus décrits par un jeu de variables que l'on résume en « réduisant sa dimensionnalité ». L'objectif de ces méthodes est de mettre en lumière des liens entre les individus, entre les variables et finalement de caractériser les individus par un certains nombre de variables. La variabilité n'est pas un problème à surmonter, mais bien au contraire un caractère à éclairer et à expliquer.

L'étude se fonde sur le corpus de sceaux non royaux et circulaires découverts à Boğazköy. Seul un échantillon du corpus (118 individus) a été sélectionné, intégré dans une base de données et analysé afin d'illustrer le potentiel de ces méthodes. Seuls les cachets circulaires pour obtenir un corpus homogène et analyser leur morphologie. Tous les cachets circulaires ont été réalisés selon le même modèle avec une plage centrale et des bordures circulaires (fig. 1). La plage centrale se compose d'une inscription en louvite hiéroglyphique mentionnant le nom, puis éventuellement le titre du propriétaire accompagné de divers motifs. Les bordures circulaires, simples ou concentriques, peuvent être garnies de hiéroglyphes, de représentations humaines ou bien de motifs décoratifs. Pour cette étude nous avons consigné des variables quantitatives 7 et qualitatives, 8 ainsi que les hiéroglyphes 9 et les symboles 10 . Cette première investigation a été limitée aux sceaux dont la conservation permet de renseigner toutes les variables 11 . L'un des objectifs de cette recherche est de reprendre le problème chronologique. Au sein du corpus de sceaux de Boğazköy, peu de scellements sont datés avec précision et l'essentiel de la documentation archéologique repose sur l'étude stylistique. La découverte du corpus de Nişantepe a permis d'attribuer quelques sceaux à deux périodes : le début de la période hittite impériale (14e siècle) et la fin de la période hittite impériale (13e siècle) 12 . Quelle corrélation existe-t-il entre la variable datation et les autres variables ? Herbordt souligne que la taille et la proportion entre la plage centrale et les bordures circulaires évoluent. Le diamètre de la plage centrale devient de plus en plus important et les bordures circulaires s'amenuisent, voire tendent à disparaitre 13 . L'évolution de la morphologie des sceaux est un aspect qui est particulièrement adapté à une approche statistique. On pourra alors tester la fiabilité de cette hypothèse 14 . Enfin une étude des symboles souligne l'association des symboles entre eux mais aussi leur corrélation avec la chronologie.

Constitution du corpus étudié

À titre exemple, 118 cachets circulaires de fonctionnaires découverts à Boğazköy ont été sélectionnés (voir tableau 1). L'essentiel de la documentation provient du complexe de Nişantepe, où les documents ont été découverts dans les vestiges du Westbau 15 . Quelques sceaux proviennent du complexe découvert dans les années 1930 à Büyükkale 16 , d'autres ont été découverts dans la ville basse et la ville haute 17 . Les datations relatives ou absolues de cachets sont rares et les sceaux ont été classés en quatre groupe selon leur datation. Un premier groupe représente les sceaux appartenant à la période de l'Ancien royaume hittite (ca 16e -15e siècle), un groupe intermédiaire correspond au début de l'Empire hittite (ca 14e siècle), un troisième groupe correspond à la fin de l'Empire hittite (ca 13e siècle). Enfin un dernier groupe comprend les sceaux de datation inconnue.

La période du 16e-15e siècle est problématique : il faut admettre que l'on ne dispose que de peu d'éléments 12 Herbordt 1998; Herbordt et Alkan 2000; Herbordt 2005, 9- pca_var <-c("Nmbr.Plage.ext", "Dm.ext", "Dm.int", "Nmbr.hiero", "Nmbr.Symb", "Datation","Orga.hiero", "Decor", "Del.centre", "Surface", "Titre") Pour compléter le graphique, on peut projeter des variables qualitatives (dites illustratives) pour étudier la corrélation avec la morphologie. La modalité de la variable Datation associée à chaque individu a été représentée par un symbole combiné à une gradation de gris (fig. 3). De plus, pour les trois périodes, une ellipse de confiance (95 %) a été tracée autour du centre de gravité de chaque modalité. Ces trois modalités se différencient sur le plan et s'échelonnent le long du premier axes. On peut en conclure que la morphologie du cachet, surtout la première dimension, est corrélée avec la datation. Ainsi, la taille de la plage centrale a, au fil du temps, tendance à être de plus en plus grande, comme l'avait déjà souligné Herbordt 31 . À cette croissance correspond également une augmentation du nombre de hiéroglyphes différents dans la légende.

Une telle observation n'est guère surprenante. L'augmentation graduelle de la taille des sceaux à été récemment souligné dans le cas des sceaux anonymes des Tabarna 32 tout comme pour les cachets royaux 33 , deux corpus dont les individus peuvent être ordonnées chronologiquement grâce aux données épigraphiques. Il semble nécessaire de souligner que les tailleurs de cachets hittites avaient conscience de la proportion des sceaux, même si les raisons de cette évolution graduelle nous échappent. Trois cachets du roi Suppiluliuma II ont une morphologie similaire à ceux de Suppiluliuma I et se démarquent significativement de l'évolution constatée. Il y a là sans doute une volonté pour ce roi de renouer avec le passé glorifié de son ancêtre éponyme par la reprise d'un ancien canon 34 .

Ce dernier exemple rappel de manière éloquente que les seuls critères morphologiques d'un cachet ne permettent pas de proposer une datation. Cette ambivalence se retrouve dans le cas des sceaux de fonctionnaires. On observe sur le graphique (fig. 3) trois cachets (H.206, H.607, H.676) qui datent du 13e siècle mais qui sont représentés juste à côté du groupe du 16e-15e : ils ont une morphologie plus proche de ce groupe que de celle des cachets du 13e siècle (fig. 2). Ces trois cachets sont du point de vue du style, de l'iconographie et de la facture similaires entre eux : ils possèdent le même type de décor extérieur (le titre du fonctionnaire se répète sur la bordure extérieure) 35 , un même répertoire iconographique (l'aigle bicéphale) et l'exécution est semblable 36 . À ce groupe on peut ajouter les sceaux non datés H.253, H.474, qui s'apparentent aux trois exemples précédents par le style, l'iconographie et l'exécution. Au final, on obtient un groupe de sceaux similaires et dont la cohérence interne mais aussi la variabilité vis-à-vis de la majorité des sceaux de cette période transparaît clairement. Si dans le cas du sceau royal de Suppiluliuma II il est possible de suggérer un rattachement à d'anciens canons, il est difficile de comprendre pourquoi ces cinq cachets de fonctionnaires s'écartent de la tendance générale (fig. 2). Néanmoins, il faut y reconnaître une production typée et 27 Husson et al. 2011, 9. 28 Les deux composantes principales représentent 69 % de la variance du tableau de données, 41 % par le premier axe et 28 %. 29 L.340 et L.370 ont été considéré comme des symboles puisqu'ils n'ont pas de rôle sémantique dans la légende. 30 H.222 n'a pas de symbole mais simplement une légende hiéroglyphique : L.326, L.175, L.23, L.390, L.110, *508, L.376. 31 Herbordt 2005, 45-46. 32 Rüster et Wilhelm 2012, 41. 33 Herbordt et al. 2011, 45. 34 Herbordt et al. 2011, 45. 35 Ces cachets sont d'ailleurs regrouper à ce propos par Herbordt (Herbordt 2005, fig. 32d, 32f et 32i). 36 Dans deux cas sur trois, Herbordt souligne la qualité et la précision du travail : H.206 (Herbordt 2005, 149) et H.607 (Herbordt 2005, 220).

restreinte pour ces cinq cachets, dont l'unité pourrait être attribuée à la production d'un atelier, voire à la main d'un artisan.

A.F.D.

Grâce à une A.F.D., on cherche à distinguer des groupes selon les modalités d'une variable qualitative. L'intérêt de cette méthode dans le cas des cachets circulaires est de rechercher si les trois périodes sont discriminantes ; existe-t-il une corrélation entre périodes et caractères exprimés ? Dans le cas de l'A.F.D. les variables sont synthétisées pour obtenir une variance maximale entre les modalités de cette variable, afin de mettre en évidence les dissemblances, tout en rapprochant le plus possible ceux qui appartiennent à un même groupe afin que l'étendue des groupes soit minimale 37 . L'analyse permet d'établir les trois périodes (modalités à discriminer), de les représenter et de projeter les individus dont on ne connait pas la datation grâce aux mesures qui ont généré la discrimination. Il est alors possible d'inférer une datation pour ces sceaux en fonction de leur position sur le graphique. Pour cette analyse nous avons pris en considération des données quantitatives et qualitatives 38 .

library(MASS)

# Extraction des coordonnées avec une ACM SiegSymbMCA <-cachets[ , c("Nmbr.Plage.ext", "Dm.ext", "Dm.int", "Nmbr.hiero", "Nmbr.Symb", "Datation","Orga.hiero","Decor", "Del.centre", "Surface", "Titre")] Outre des variables quantitatives, dont l'importance chronologique a été souligné avec l'A.C.P., quelques variables qualitatives contribuent fortement à la création du graphique. Si l'on détermine les modalités qui ont le plus contribué à la construction des axes, on peut en déduire les modalités qui ont la plus grande influence pour établir une différence chronologique. Parmi celles-ci on retrouve la présence / absence de frises torsadées, la première étant une caractéristique des sceaux du 16e-15e. La forme de la surface (plate / concave) joue un rôle important dans la séparation des groupes. Un diagramme où l'on illustre cette qualité (fig. 5

Conclusion

L'analyse de données multidimensionnelles offre des représentations graphiques parlantes, qui permettent de comprendre la variabilité des individus d'un jeu complexe de données. L'A.C.P., qui n'utilise pas la variable datation à priori, met en évidence des sceaux qui possèdent des caractéristiques similaires et indique la tendance générale de l'évolution morphologique des cachets. L'A.F.D. est un outil qui permet d'aider à la datation et d'étudier quels sont les paramètres qui discriminent les sceaux selon leur chronologie. Même dans un domaine aussi bien étudié que la sigillographie, une telle approche permet d'apporter un regard nouveau sur les données acquises et leur traitement. Dans cette étude de cas, l'expression de la variance a été expliquée grâce à la variable chronologique. Néanmoins, il ne faudrait pas restreindre ce genre d'analyses à l'étude de la chronologie. D'autres questions, qui nécessiteraient un corpus plus large -ou du moins une sélection ne se focalisant pas sur la chronologie -, pourraient être abordées, comme la variation spatiale ou celle des titulatures.

Tableau des individus étudiés

print(xtable::xtable(individus_etudies, caption = "Individus étudiés", label = "tab-indi", align = c("r","p{14cm}") ), comment = FALSE, include.rownames = TRUE, latex.environments = c("center"), 39 Herbordt et al. 2011, 21-23. 40 La modalité « étagé », représenté par deux exemplaires pour les sceaux du 14e siècle (Cf. Herbordt 2005, 77) influence de manière minimale la première dimension. 41 Dinçol et Dinçol 2008, 16. 42 Herbordt et al. 2011, 45. 43 L'absence de l'un ou de l'autre symbole n'a pas de signification chronologique.

booktabs = TRUE, floating = TRUE )

Cachets ca xvie-xve s. B.111, B.117, B.118, B.119, B.120, B.123, B.124, B.125, B.126, B.127, B.131, B.154, D.1, D.2, D.4, D.5a, D.5b, D.6, D.7, D.8, D.9, D.10, D.15, D.16, D.18, D.24, D.38, G.195, H.259, H.726 ca xive s. D.72, G.48, G.53, G.54, G.204, H.108, H.153, H.154, H.207, H.210, H.212, H.592 ca xiiie s. H.94, H.102, H.140, H.145, H.206, H.220, H.229, H.323, H.346, H.347, H.400, H.494, H.501, H.579, H.607, H.619, H.674, H.676 inconnue D.25, D.37b, D.51, D.52, D.65, D.68, D.71, D.73, D.85, D.97, D.105, D.118, G.59, H.2, H.25, H.26, H.28, H.40, H.41, H.43, H.46, H.74, H.79, H.91, H.106, H.124, H.136, H.159, H.160, H.170, H.172, H.178, H.182, H.196, H.216, H.222, H.226, H.246, H.253, H.295, H.297, H.303, H.336, H.351, H.373, H.381, H.408, H.474, H.476, H.491, H.503, H.535, H.598, H.627, H.648, H.694, H.696, H.700 Table 1: Individus étudiés

Figure 1 :

 1 Figure 1: Sceaux D.2, H.153, H.220 datant respectivement des trois périodes définies, 16e-15e, 14e, 13e.

Figure 2 :

 2 Figure 2: Sceaux H.206, H.607, H.676, H.253, H.474.

  Figure 3: Analyse en Composantes Principales illustrée selon la datation

SiegelSymb#

  var.afd <-c("Nmbr.Plage.ext", "Dm.ext", "Dm.int", "Nmbr.hiero", "Nmbr.Symb", "Datation") # Association Coordonnées ACM avec variables pour AFD SiMix <-cbind(SiegelSymb.mca$ind$coord[,c(1:2)], cachets[,var.afd]) var.afd <-c("Dim 1","Dim 2", var.afd) # Création de 2 jeux de données: 1) sceaux datés 2) datation inconnue # 1) sceaux datés SiDat <-SiMix[SiMix$Datation != "Inconnue", var.afd] # AFD selon la variable datation SiDat$Datation <-as.factor(as.character(SiDat$Datation)) ldaSiDat <-lda(Datation ~., SiDat) # 2) datation inconnue SiUnDat <-SiMix[SiMix$Datation == "Inconnue", var.afd] 37 Lebart et al. 1995, 253. 38 L'A.C.P. à mis en évidence qu'une distinction se basant uniquement sur des critères métriques n'est pas adaptée pour aborder le problème de la chronologie. Le codage de l'analyse a eu lieu en deux étapes : tout d'abord en effectuant une Analyse des Correspondances Multiples sur les variables qualitatives dont les coordonnées, assemblées avec les variables quantitatives ont été analysées avec une A.F.D.. Les hiéroglyphes n'ont pas été intégrés dans cette étude.## Faire un nouveau table avec les données de AFD lda.m <-Ajouter les autres variables lda.mixte <-merge(SiegSymbMCA, lda.m, by = "row.names") rownames(lda.mixte) <-lda.mixte$Row.names # Data.frame sans datation inconnue pour les ellipses lda.date <-droplevels.data.frame(lda.mixte[lda.mixte$Datation != "Inconnue",]) # Calculer coordonnées des ellipses ellipse_coord <-coord.ellipse(lda.date[,c("Datation","LD1", "LD2")] , bary = TRUE, npoint = 1000) pca_ellipse <-data.frame(ellipse_coord$res) colnames(pca_ellipse) <-c("datelli", "dim1elli", "dim2elli") (x = labelx, y = labely, title = "LD-Mixte")) + geom_hline(yintercept = 0, linetype = 2) + geom_vline(xintercept = 0, linetype = 2) lda.mixte <-lda.mixte[lda.mixte$Surface != "Etagee",]

Figure 4 :

 4 Figure 4: Analyse Factorielle Discriminante illustrée selon la datation.

Figure 5 :

 5 Figure 5: Analyse Factorielle Discriminante illustrée selon le type de surface.

Figure 6 :

 6 Figure 6: Sélection des individus de l'A.F.D. selon les critères (a) présence du symbole L.369 et (b) présence de griffons et/ou d'aigles bicéphales

  18.13 Herbordt 2005, 45-46.14 Schoop a utilisé des critères morphologiques pour dater la céramique hittite de Boğazköy, dont le principe a inspiré cette étude. Cf.[START_REF] Schoop | Absolute Chronologie in Boğazköy-Ḫattuša : Das Potential der Radiokarbondaten[END_REF] établit une chronologie 18 . Néanmoins, les critères paléographiques et la ressemblance des sceaux avec ceux de la période du Bronze moyen permet de bien isoler ce groupe par rapport aux cachets plus récents dont 30 exemplaires ont été sélectionnés. À Nişantepe, grâce à la découverte d'un lot de scellements associés avec des empreintes de rois hittites du début de la période hittite impériale (Suppiluliuma Ier -Arnuwanda II -Mursili II), des empreintes ont été datées du début du 14e siècle. Celles-ci, découvertes dans le coin sud-est de la pièce 3 19 , proviennent d'un étage qui s'est effondré et certaines intrusions d'empreintes plus récentes ont été constatées. Seuls les sceaux de cet ensemble qui sont attestés par plus d'une empreinte ont été catalogués ; les cachets attestés par une seule empreinte n'ont pas été considéré comme appartenant à ce groupe 20 . Grâce à la corrélation entre les ensembles de Nişantepe et de Büyükkale découverts dans les années 1930, Herbordt attribue une série de sceaux à la même période 21 . Au total 12 sceaux ont pu être attribués au 14e siècle En ce qui concerne les sceaux du 13e siècle de Nişantepe, les contextes de découverte sont moins satisfaisants 22 . Je considère le corpus découvert dans le coin nord-est de la pièce 3 comme datant de la fin du 13e siècle 23 . De plus l'étude prosopographique permet d'attribuer des empreintes au 13e siècle grâce à une correspondance avec les personnes cités dans les textes 24 .

15

Herbordt 2005, 7-19.

16

Güterbock 1942.

17 Boehmer et Güterbock 1987 ; Dinçol et Dinçol 2008.

pour Les princes Ehli-Šarruma, Kuruntiya, Taki-Šarruma et les scribes Mahhuzi, Sahurunuwa, Walwaziti sont à dater de cette période 25 . Finalement, pour étoffer ce groupe, le présence de multiples impressions sur des scellements a permis de regrouper des fonctionnaires contemporains du prince Kuruntiya 26 , portant ce groupe à 18 individus.

A.C.P.

library(knitr) library(FactoMineR) library(ggplot2)

# Lire les données cachets_tsv <-"data/cachets_hittites.tsv" cachets_deconcat_tsv <-"data/cachets_hittites_deconcat.tsv" individus_etudies_tsv <-"data/individus_etudies.tsv" individus_etudies <-read.delim(individus_etudies_tsv, row.names = 1) cachets <-read.delim(cachets_tsv, row.names = 1) cachets_deconcat <-read.delim(cachets_deconcat_tsv, row.names = 1) cachets$Datation <-relevel(cachets$Datation, "14e") cachets$Datation <-relevel(cachets$Datation, "16-15e") cachets$Datation <-relevel(cachets$Datation, "Inconnue") # Analyse en Composantes Principales

(ACP)

  ) montre très bien comment sont repartis les deux groupes qui s'opposent de part et d'autre du graphique. Si l'on compare la discrimination des périodes (fig.4) et la répartition des modalités de la surface -plate ou concave 40 -on en déduit que le passage progressif des sceaux de la surface plane à la surface concave se situe vers la fin du 14e siècle, comme le propose A. et B. Dinçol 41 . Cette datation est par ailleurs confirmée par les sceaux royaux: les plus anciens ont une surface plate, les plus récents sont convexes et la transition se fait progressivement entre les règnes de Tuthaliya II/III, Suppiluliuma, Arnuwanda II et Mursili II 42 .Un dernier diagramme illustre l'importance des symboles dans l'organisation des groupes. Dans la 6, seuls les cachets possédant la croix ansée hittite de type L.369 et les cachets qui ont un aigle bicéphale ou un griffon sont représentés. Il devient aisé d'observer que le symbole L.369 est corrélé avec les sceaux de la période du 16-15e et 14e siècle : la plupart de ces cachets ont des coordonnées négatives sur le premier axe. C'est l'opposé pour les sceaux où l'on trouve un griffon ou un aigle bicéphale. Ceux-ci apparaissent surtout sur les sceaux à dater du 13e siècle 43 .

Pour une description des méthodes, voir[START_REF] Escofier | Analyses factorielles simples et multiples[END_REF][START_REF] Lebart | Statistique exploratoire multidimensionnelle. Visualisation et inférence en fouille de données[END_REF]. Cette étude a été réalisée avec le logiciel R (R Core Team 2015), les librairies FactoMineR[START_REF] Husson | FactoMineR: Multivariate Exploratory Data Analysis and Data Mining with R[END_REF] et MASS[START_REF] Venables | Modern Applied Statistics with S[END_REF] pour les analyses et la librairie ggplot2 pour les graphiques[START_REF] Wickham | Ggplot2: Elegant Graphics for Data Analysis[END_REF]).

Les variables sont les suivantes : Nombre de bordures, Diamètre total, Diamètre de la plage centrale, Nombre de hiéroglyphes différents, Nombre de symboles différents

Les modalités des variables qualitatives sont indiquées entre parenthèses : Disposition des hiéroglyphes de la plage centrale (atypique/ en doublet/ en quinconce/ Titre de part et d'autre du nom), Type de décor des bordures (absence/ ornemental/ animal/ humain), Delimitation de la plage centrale (absence / ligne simple / frise de rectangles), Surface (plate / concave/ étagée), Titre (prince/ absence de titre/ fonctionnaire).

 9 Nous avons suivis la classification traditionnelle, c'est-à-dire la liste de Laroche pour les signes 1 à 497[START_REF] Laroche | Les hiéroglyphes hittites. Première partie, L'écriture[END_REF], augmentée de la liste de Hawkins(Hawkins 1995, 139). Les signes de la liste Laroche sont précédé d'un L, ceux identifiés par Hawkins d'un

astérisque. 10 Les motifs ont été classés en frise torsadée, aigle bicéphale, griffon, vegetaux, rosette, cupule, L369, L440, L441,

L370-BONUS 2 . 11 Par exemple H.153 (fig.1) représente la limite de conservation des sceaux étudiés: même s'il est incomplet, il peut être restitué car la bordure circulaire répète les mêmes motifs. Éviter les données manquantes simplifie le traitement statistique des données. Il existe néanmoins différentes méthodes pour prendre en considération les individus aux données manquantes, qui n'ont pas en elle-même un caractère rédhibitoire.

Pour cette période, il n'existe pratiquement aucun sceau qui provienne d'un contexte fermé. Cf. Boehmer et Güterbock

1987, 33-58.19 Herbordt 2005, 11-13, 75-77. 20 Ont été considérés comme datant du début de la période impériale, les sceaux deHalparuntiya (H.108), Izzummiziti (H.153, H.154; H.155 est incomplet), Luwa (H.210, H.212; H.211 est incomplet). Avis 2 (H.592). x-mi-ti (H.386), Tuwa (H.470) et su+ra/i(-)tà-mi(-)tà(?)... (H.567), attestés chacun par une seule impression, ont été considérés de datation incertaine. Cf. Herbordt 2005, 12, tableau 3. 21 G.47, G.48, G.53, G.54, G.204, H.207 et B.214. Cf. Herbordt 2005, 75-77. 22 Herbordt 2005, 18. 23 Herbordt 2005, 13-14 ; Herbordt et al. 2011, 11. J'ai retenu les exemples les mieux conservés: H.140, H.145, H.206, H.496 (=H.494), H.501, H.579, H.619, H.674, H.676. 24 Herbordt 2005, 77-89. Il faut néanmoins noter la différence dans l'accréditation de l'identification entre Herbordt et Hawkins, qui, lui, utilise toujours le conditionnel (Hawkins 2005). J'ai uniquement sélectionné les personnages proposés par Herbordt et pour lesquels Hawkins exprimait peu de doutes, attribuant une datation incertaine aux personnes suivantes: Aki[ (H.2), Alalimi (H.3 à 10), Ari-Šarruma (H.633), Halpaziti (H.112), Huzziya (H.1313), Kassu (H.158), Mizrimuwa (H.243 à 246), Šauškamuwa (H.365 à 372), Tarhuntapiya (H.418 à 420), MAGNUS-TONITRUS (H.625 à 630). Ini-Teššup (H.150 et 151) est roi et n'a donc pas été étudié. 25 Ce qui correspond, pour les sceaux bien conservé, à H.102, H.400, H.220, H.346 et H.347. Mal conservés, les sceaux de Kuruntiya et de Walwaziti n'ont pu être intégrés dans le corpus. 26 H.94, H.229, H.607, H.674, H.676. Cf. Herbordt 2005, 84, tableau 10, groupe 2. À noter que H.674 et H.676 ont été trouvés au nord-est de la pièce 3 (cf. ci-dessus note 23).