Comment utiliser les entrées/sorties RDF de Jena

Ceci est un guide pour le sous-système d'entrée/sortie de Jena. Tous les utilisateurs de Jena ont besoin de savoir utiliser InputStream et OutputStream plutôt que Reader et Writer. La première section donne une rapide introduction pour le sous-système d'entrée/sortie. Les autres sections sont destinées aux utilisateurs souhaitant utiliser des fonctionnalités avancées dans le sous-système d'entrée/sortie.

Notez qu'un nouveau sous-système d'entrée/sortie pour Jena, nommé RIOT, est actuellement en développement. Voir la documentation de RIOT pour plus de détails.

Commentez Donner une note à l'article (5)

Article lu   fois.

L'auteur

Traducteur : Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Présentation rapide

Les principales méthodes d'entrée/sortie dans Jena utilisent InputStream et OutputStream. Ces méthodes se trouvent dans l'interface Model. Ce sont :

  • Modelread(java.io.InputStream in, java.lang.String base)
    ajoute des déclarations à partir d'une sérialisation RDF / XML ;
  • Modelread(java.io.InputStream in, java.lang.String base, java.lang.String lang)
    ajoute des déclarations RDF représentées dans la langue lang du modèle ;
  • Modelread(java.lang.String url)
    ajoute les déclarations RDF à partir d'un document XML ;
  • Modelwrite(java.io.OutputStream out)
    écrit le modèle comme un document XML ;
  • Modelwrite(java.io.OutputStream out, java.lang.String lang)
    écrit une représentation sérialisée d'un modèle dans une langue spécifiée ;
  • Modelwrite(java.io.OutputStream out, java.lang.String lang, java.lang.String base)
    écrit une représentation sérialisée d'un modèle dans une langue spécifiée.

Les langages intégrés sont : « RDF/XML », « RDF/XML-ABBREV », « N-TRIPLE », « N3 » et « TURTLE ». En plus, pour la sortie Turtle, la langue peut être spécifiée comme : « N3-PP », « N3-PLAIN » ou « N3-TRIPLE » qui contrôle le style de N3 produit.

Il y a aussi des méthodes qui utilisent Reader et Writer, mais à n'employer que si vous êtes sûr qu'il est correct de les utiliser. Dans les applications avancées, elles sont utiles (voir la suite ci-dessous) et l'objectif est bien de les maintenir. L'analyseur RDF/XML maintenant vérifie pour voir si les appels à Model.read(Reader…) sont abusifs, et dans ce cas, les sanctionne par les erreurs ERR_ENCODING_MISMATCH et WARN_ENCODING_MISMATCH. La plupart des utilisations incorrectes des Reader pour l'entrée RDF/XML se traduiront par ce genre d'erreur. Par contre, la plupart des utilisations incorrectes des Writer pour la sortie RDF/XML, produiront du XML correct en utilisant une déclaration XML appropriée donnant l'encodage - par exemple :

 
Sélectionnez
<?xml version='1.0'
    encoding='ISO-8859-15'?>

Cependant, un tel XML est moins portable qu'un XML en UTF-8. Utiliser les méthodes Model.write(OutputStream…) permet au code du système de Jena de choisir l'encodage UTF-8, qui est le meilleur choix.

I-A. RDF/XML, RDF/XML-ABBREV

Pour l'entrée, ces deux formats sont identiques, implémentant complètement la recommandation de la syntaxe RDF, voir paragraphe : VIII Conformité.

Pour la sortie, « RDF/XML » produit une sortie régulière raisonnablement efficace, mais elle n'est pas lisible. En revanche, « RDF/XML-ABBREV », produit une sortie lisible sans trop se préoccuper de l'efficacité.

Tous les modules de lecture et les modules d'écriture pour RDF/XML sont configurables, voir plus bas, l'entrée et la sortie.

I-B. Turtle

Le module de lecture de N3 accepte tout Turtle valide. Notez que les modules d'écriture de N3 et Turtle produisent des qnames internationalisés, avec le jeu de caractères des espaces de noms de XML (sauf pour « : » ), et ne sont pas limités à l'ASCII, comme l'est la définition de N3 et de Turtle.

Le module d'écriture Turtle est le module d'écriture N3 configuré avec : usePropertySymbols=false, useTripleQuotedStrings=false, useDoubles=false.

I-C. N-TRIPLE

Les modules de lecture et d'écriture de N-TRIPLE implémentent le langage RDF de base en N-Triples.

I-D. N3

Les modules de lecture et d'écriture implémentent le langage N3 de Tim Berners-Lee.

Il y a actuellement quatre modules d'écriture :

  • N3 : le module d'écriture standard qui choisit l'un des trois autres ;
  • N3-PP : un module d'écriture N3 complet produisant une sortie lisible ;
  • N3-PLAINE : un module d'écriture N3 qui ne niche pas des structures bNode, mais écrit des groupes d'enregistrements de toutes les propriétés pour un objet ;
  • N3-TRIPLE : un module d'écriture d'une déclaration par ligne, comme le N-TRIPLES, mais aussi la conversion de qname des URIref.

Le module d'écriture standard Jena « N3 »  choisit quel module d'écriture utiliser basé sur la propriété système com.hp.hpl.jena.n3.N3JenaWriter.Writer.

Si aucun de ces modules ne produit du N3 à votre goût, il est possible de continuer à la sortie.

II. Les problème d'encodage de caractères

La meilleure méthode pour ne pas avoir besoin de lire ou de comprendre cette section est de toujours utiliser les InputStream et OutputStream avec Jena et de ne jamais utiliser les Reader et les Writer. Ainsi, Jena fera les bons choix pour la grande majorité des utilisateurs. Si vous avez du code hérité qui utilise des Reader et des Writer, ou si vous avez des besoins spéciaux avec le respect de l'encodage, alors cette section peut être utile. La dernière partie de cette section résume les encodages de caractères supportés par Jena.

L'approche de Java pour les encodages est conçue pour la facilité d'utilisation sur une seule machine, qui utilise un seul encodage ; celui-ci est souvent sur un octet, par exemple pour les langues européennes qui n'ont pas besoin de milliers de caractères différents.

L'approche XML est conçue pour le Web qui utilise de multiples encodages, et certains d'entre eux exigent des milliers de caractères.

Sur le Web, les fichiers XML, incluant les fichiers RDF/XML, sont par défaut encodés en « UTF-8 »  (Unicode). C'est toujours un bon choix pour la création de contenu, et c'est celui utilisé par Jena par défaut. D'autres encodages peuvent être utilisés, mais peuvent avoir une interopérabilité moins sûre . Ceux-ci doivent être nommés en utilisant le nom canonique inscrit à l'IANA, mais les systèmes n'ont pas d'obligation à les supporter. Seuls UTF-8 et UTF-16 sont standards (et, de ce fait, obligatoires).

Dans Java, les encodages apparaissent principalement avec les classes InputStreamReader et OutputStreamWriter, qui convertissent les octets en caractères utilisant un codage nommé, et avec leurs sous-classes, FileReader et FileWriter, qui convertissent les octets en caractères dans le fichier et les caractères utilisant l'encodage par défaut de la plate-forme. Il n'est pas possible de changer l'encodage utilisé par un Reader ou un Writer tant qu'il est en train d'être utilisé. L'encodage par défaut de la plate-forme dépend d'un large éventail de facteurs. Cet encodage par défaut peut être utile pour communiquer avec d'autres programmes sur la même plate-forme. Quelquefois, l'encodage par défaut n'est pas inscrit à l'IANA et,dans ce cas, les développeurs d'applications Jena ne doivent l'utiliser par défaut pour le contenu Web, mais utiliser UTF-8.

II-A. Encodages supportés par Jena 2.2 et ultérieurs

Sur l'entrée RDF/XML n'importe quel encodage supporté par Java peut être utilisé. Si ce n'est pas un nom canonique inscrit à l'IANA un message d'avertissement est affiché. Certains encodages ont un meilleur support dans Java 1.5 que dans Java 1.4 ; pour de tels encodages un message d'avertissement est généré sur Java 1.4 qui suggère la mise à niveau.

Sur la sortie RDF/XML n'importe quel encodage supporté par Java peut être utilisé, en construisant un OutputStreamWriter utilisant cet encodage et en utilisant cela pour la sortie. La problématique de la qualité du support des encodages est identique à celle de l'entrée RDF/XML.

Java peut être configuré avec ou sans un JAR d'encodages supplémentaires dans le classpath. Ce JAR est charsets.jar et siège dans le répertoire lib du Runtime Java. Si ce JAR n'est pas dans votre classpath alors la gamme d'encodages supportés est clairement restreinte.

Les encodages supportés par Java sont listés par Sun, pour 1.5.0. Pour un encodage qui n'est pas dans ces listes, il est possible d'écrire votre propre transcodeur, comme détaillé dans la documentation du paquet java.nio.charset.

Les versions antérieures de Jena supportent moins d'encodages.

III. Quand utiliser Reader et Writer ?

Rarement.

Malgré les problèmes d'encodage de caractères, il est encore parfois approprié d'utiliser les Reader et les Writer avec les entrées/sorties Jena. Un bon exemple est d'utiliser les Reader et les Writer dans les StringBuffer en mémoire. Ceux-là n'ont pas besoin d'être encodés et décodés ; ainsi la spécification d'un quelconque encodage est inutile. Autre exemple : un utilisateur avancé souhaite explicitement contrôler correctement l'encodage.

  • Modelread(java.io.Reader reader, java.lang.String base)
    utiliser cette méthode est souvent une erreur ;
  • Modelread(java.io.Reader reader, java.lang.String base, java.lang.String lang)
    utiliser cette méthode est souvent une erreur ;
  • Modelwrite(java.io.Writer Writer)
    attention ! écrit le modèle comme un document XML ;
  • Modelwrite(java.io.Writer Writer, java.lang.String lang)
    attention ! écrit une représentation sérialisée d'un modèle dans une langue spécifiée ;
  • Modelwrite(java.io.Writer Writer, java.lang.String lang, java.lang.String base)
    Attention ! écrit une représentation sérialisée d'un modèle dans une langue spécifiée.

Une utilisation incorrecte de ces méthodes read(Reader…) aboutit à des avertissements et des erreurs avec RDF/XML et RDF/XML-ABBREV (sauf dans quelques cas où l'utilisation incorrecte ne peut être automatiquement détectée). L'utilisation incorrecte des méthodes write(Writer…) aboutit à de curieuses déclarations XML comme <?xml version="1.0" encoding="WINDOWS-1252"?>. Cela refléterait que l'encodage de caractères que vous utilisiez (probablement sans le réaliser) dans votre Writer est inscrit auprès de l'IANA sous le nom de « Windows-1252 ». Le XML résultant est de portabilité réduite en conséquence.

Depuis que UTF-8 et UTF-16 sont les seuls encodages susceptibles d'être compris par tous les processeurs XML conformes, même l'ISO-8859-1 serait techniquement sur un terrain glissant. Néanmoins, du fait qu'il soit très largement répandu, chaque processeur XML raisonnable le supporte. Avec N-TRIPLE une utilisation incorrecte est habituellement bénigne puisque N-TRIPLE est basé sur ASCII.

Les problèmes d'encodage de caractères de N3 ne sont pas bien définis, d'où l'utilisation de ces méthodes qui peuvent exiger des changements dans le futur. L'utilisation des méthodes InputStream et OutputStream permettra à votre code - quel qu'il soit - de fonctionner avec les futures versions de Jena. Actuellement, les méthodes OutputStream utilisent l'encodage UTF-8.

IV. Introduction aux entrées/sorties Jena avancées

L'entrée et la sortie RDF/XML sont configurables. Toutefois, pour les configurer, il est nécessaire d'accéder à un objet RDFReader ou RDFWriter qui reste caché dans la plus simple interface au dessus.

Les quatre appels vitaux dans l'interface Model sont :

  • RDFReadergetReader()
    retourne une instance de RDFReader pour la langue de sérialisation par défaut ;
  • RDFReadergetReader(java.lang.String lang)
    retourne une instance de RDFReader pour la langue de sérialisation spécifiée ;
  • RDFWritergetWriter()
    retourne une instance de RDFWriter pour la langue de sérialisation par défaut ;
  • RDFWritergetWriter(java.lang.String lang)
    retourne une instance de RDFWriter pour la langue de sérialisation spécifiée.

Chacun de ces appels retourne un RDFReader ou un RDFWriter qui peut être utilisé pour lire ou écrire n'importe quel Model (et pas seulement celui qui l'a créé). Aussi bien que les méthodes nécessaires read et write, ces interfaces fournissent :

  • RDFErrorHandlersetErrorHandler(RDFErrorHandler errHandler)
    définit un gestionnaire d'erreur pour le module de lecture ;
  • java.lang.Object setProperty(java.lang.String propName, java.lang.Object propValue)
    règle la valeur d'une propriété du module de lecture.

Définir les propriétés, ou le gestionnaire d'erreur, sur un RDFReader ou un RDFWriter permet au programmeur d'accéder au comportement qui n'est pas celui par défaut. Par ailleurs, depuis le RDFReader et le RDFWriter le développeur n'est pas lié à un Model spécifique. Un idiome typique est créé par les RDFReader ou les RDFWriter à l'initialisation du système, pour définir les propriétés appropriées de sorte qu'il se comporte exactement comme requis dans votre application, et ensuite pour faire toutes les subséquentes entrées/sorties à travers lui.

 
Sélectionnez
Model m = Modelfactory.createDefaultModel();
RDFWriter writer = m.getRDFWriter();
m = null; // m n'est plus nécessaire.
writer.setErrorHandler(myErrorHandler);
writer.setProperty("showXmlDeclaration","true");
writer.setProperty("tab","8");
writer.setProperty("relativeURIs","same-document,relative");
&#8230;
Model marray[];
&#8230;
for (int i=0; i<marray.length; i++) {
&#8230;
    OutputStream out = new FileOutputStream("foo" + i + ".rdf");
    writer.write(marray[i],
                       out,
      "http://example.org/");
    out.close();
}

Notez que toutes les implémentations courantes sont synchronisées, de sorte qu'un RDFReader spécifique ne peut être en train de lire deux documents différents au même moment. Dans une application en "multithreading" cela peut suggérer un besoin pour un groupement de RDFReaders et/ou de RDFWriter, ou alternativement de les créer, les initialiser, les utiliser et les jeter si nécessaire.

Pour le N-TRIPLE il n'y a actuellement pas de propriétés supportées pour soit le RDFReader, soit le RDFWriter. D'où il découle que l'idiome ci-dessus n'est pas très utile, et simplement utiliser la méthode Model.write() peut se révéler plus facile.

Pour le RDF/XML et le RDF/XML-ABBREV, il y a de nombreuses options à la fois dans le RDFReader et le RDFWriter. N3 fournit des options sur le RDFWriter. Ces options sont détaillées ci-dessous. Pour RDF/XML elles sont également présentes dans la javadoc pour JenaReader.setProperty(String, Object) et RDFXMLWriterI.setProperty(String, Object).

V. Entrée RDF/XML avancée

Pour accéder à ces fonctionnalités avancées, d'abord obtenir un objet RDFReader qui est une instance d'un analyseur ARP, en utilisant la méthode getReader() sur n'importe quel Model. Il est alors configuré en utilisant la méthode setProperty(String, Object). Cela change les propriétés pour analyser le RDF/XML. Beaucoup de propriétés modifient l'analyseur RDF, certaines modifient l'analyseur XML. L'analyseur RDF/XML de Jena, ARP, implémente la grammaire RDF sur un analyseur XML Xerces2-J. Cependant, changer les caractéristiques et les propriétés de l'analyseur XML n'est pas susceptible d'être utile, mais était facile à implémenter.

setProperty(String, Object) peut être utilisée pour définir et obtenir ce qui suit.

  • Les propriétés ARP
    Ces propriétés permettent un contrôle fin sur les capacités de rapport d'erreur étendue de ARP, et sont détaillées directement ci-dessous.
  • Les fonctionnalités SAX2
    Voir les fonctionnalités SAX2. La valeur doit être donnée comme une chaîne de caractères « true » ou « false » ou un booléen.
  • Les propriétés SAX2
    Voir les propriétés SAX2.
  • Les fonctionnalités Xerces
    Voir les fonctionnalités Xerces. La valeur doit être donnée comme une chaîne de caractères « true » ou « false » ou un booléen.
  • Les propriétés Xerces
    Voir les propriétés Xerces.

V-A. Les propriétés ARP

Une propriété ARP est appelée soit par son nom de propriété, (voir ci-dessous), soit par une URL absolue de la forme http://jena.hpl.hp.com/arp/properties/<PropertyName>. La valeur doit être une chaîne de caractères, un entier ou un booléen dépendant de la propriété.

Les noms de propriété ARP et les valeurs de la chaîne de caractères sont insensibles à la casse.

Nom de la propriété

Description

Classe de la valeur

Valeurs légales

iri-rules

Définit le moteur pour la vérification et la résolution. « strict » définit le moteur d'IRI avec les règles pour valider les IRI, XLink et RDF ; elles ne permettent pas les espaces dans les IRI. « iri » définit le moteur d'IRI en IRI (RFC 3986, RFC 3987). La valeur par défaut est « lax » (pour la rétrocompatibilité), les règles pour les références URI RDF, qui permettent les espaces bien que l'utilisation des espaces ne soit pas une bonne pratique.

String

lax
strict
iri

error-mode

ARPOptions.setDefaultErrorMode()
ARPOptions.setLaxErrorMode()
ARPOptions.setStrictErrorMode()
ARPOptions.setStrictErrorMode(int)
Cela permet une approche grossière pour contrôler la gestion des erreurs. Définir cette propriété est équivalent à définir beaucoup des propriétés fines de gestion des erreurs.

String

default
lax
strict
strict-ignore
strict-warning
strict-error
strict-fatal

embedding

ARPOptions.setEmbedding(boolean)
Ceci définit ARP pour rechercher du RDF embarqué dans un document XML englobant.

String
ou
Boolean

true
false

ERR_<XXX>
WARN_<XXX>
IGN_<XXX>

Voir ARPErrorNumbers pour une liste complète des conditions de l'erreur détectée. Définir une de ces propriétés est équivalent à la méthode ARPOptions.setErrorMode(int, int). Ainsi on peut avoir un contrôle fin sur le comportement en réponse à des conditions d'erreur possible.

String
ou
Integer

EM_IGNORE
EM_WARNING
EM_ERROR
EM_FATAL

À titre d'exemple, si vous travaillez dans un environnement avec des données RDF héritées qui utilisent des attributs RDF non qualifiés comme « about » au lieu de « rdf:about », alors le code suivant est approprié :

 
Sélectionnez
Model m = Modelfactory.createDefaultModel();
RDFReader arp = m.getReader();
m = null; // m n'est plus nécessaire.
// initialise arp
// ne pas avertir sur l'utilisation d'attributs RDF non qualifiés.
arp.setProperty("WARN_UNQUALIFIED_RDF_ATTRIBUTE","EM_IGNORE");

...

InputStream in = new FileInputStream(fname);
arp.read(m,in,url);
in.close();

À titre de second exemple, on suppose que vous souhaitez travailler en mode strict, mais en autorisant « daml:collection », le code suivant fonctionne :

 
Sélectionnez
...
 arp.setProperty("error-mode", "strict" );
 arp.setProperty("IGN_DAML_COLLECTION","EM_IGNORE");
 ...

Dans l'autre sens, cela ne fonctionne pas.

 
Sélectionnez
...
 arp.setProperty("IGN_DAML_COLLECTION","EM_IGNORE");
 arp.setProperty("error-mode", "strict" );
 ...

C'est parce que, dans le mode strict, IGN_DAML_COLLECTION est traitée comme une erreur, et donc le second appel à setProperty écrase l'effet du premier.

Les règles IRI et le résolveur peuvent être définis sur une base par module de lecture :

 
Sélectionnez
InputStream in = ... ;
String baseURI = ... ;
Model model = Modelfactory.createDefaultModel();
RDFReader r = model.getReader("RDF/XML");
r.setProperty("iri-rules", "strict") ;
r.setProperty("error-mode", "strict") ; // les warnings seront des erreurs.

// Alternative au "error-mode" ci-dessus  : définit un warning spécifique pour être une erreur.
//r.setProperty( "WARN_MALFORMED_URI", ARPErrorNumbers.EM_ERROR) ;
r.read(model, in, baseURI) ;
in.close();

La valeur globale par défaut du moteur IRI peut être définie avec :

 
Sélectionnez
ARPOptions.setIRIFactoryGlobal(IRIFactory.iriImplementation());

ou un autre moteur de règle IRI venant de IRIFactory.

V-B. Interruption de ARP

ARP peut être interrompu en utilisant la méthode Thread.interrupt(). Cela cause une erreur ERR_INTERRUPTED durant l'analyse, qui est habituellement traitée comme une erreur fatale.

Voici un échantillon de code illustratif :

 
Sélectionnez
ARP a = new ARP();
final Thread arpt = Thread.currentThread();
Thread killt = new Thread(new Runnable() {
     public void run() {
       try {
      Thread.sleep(tim);
       } catch (InterruptedException e) {
       }
       arpt.interrupt();
     }
  });
killt.start();
try {
  in = new FileInputStream(fileName);
  a.load(in);
  in.close();
  fail("Thread was not interrupted.");
} catch (SAXParseException e) {
}

VI. Sortie RDF/XML avancée

La première question sur la sortie RDF/XML est de savoir si on doit utiliser le module d'écriture « RDF/XML » ou « RDF/XML-ABBREV ». Alors qu'une partie du code est partagée, ces deux modules d'écriture sont vraiment très différents, provoquant une sortie différente, mais équivalente. RDF/XML-ABBREV est plus lent, mais devrait produire du XML plus lisible.

Pour accéder aux fonctionnalités avancées, d'abord obtenir un objet RDFWriter, de la langue appropriée, par l'utilisation de getWriter("RDF/XML") ou getWriter("RDF/XML-ABBREV") sur n'importe quel Model. Il est alors configuré en utilisant la méthode setProperty(String, Object). Cela change les propriétés pour écrire du RDF/XML.

VI-A. Les propriétés pour contrôler la sortie RDF/XML

Nom de la propriété

Description

Classe de la valeur

Les valeurs légales

xmlbase

La valeur incluse pour un attribut xml:base sur l'élément racine dans le fichier.

String

une chaîne de caractère
d'URI, ou
null
(par défaut)

longId

Utiliser un identifiant long ou short. Les identifiants short sont plus faciles à lire et sont ceux par défaut, mais peuvent provoquer un dépassement de mémoire sur de très grands modèles.

String ou
Boolean

"true",
"false"
(par défaut)

allowBadURIs

Les URI dans le graphe sont, par défaut, vérifiés avant la sérialisation.

String ou
Boolean

"true",
"false"
(par défaut)

relativeURIs

Quelles sortes d'URI relatifs doivent être utilisés. Une liste d'options séparées par des virgules  : La valeur par défaut est « same-document, absolute, relative, parent ». Pour désactiver les URI relatifs utilisez la valeur "". Les URI relatifs de tous ces types sont affichés où c'est possible, si et seulement si l'option a été spécifiée.

  • same-document
    les références same-document (par exemple "" ou "#foo" ;
  • network
    chemins du réseau, par exemple « //example.org/foo  » ommettant le schéma d'URI ;
  • absolute
    chemins absolus par exemple « /foo » omettant le schéma et l'autorité ;
  • relative
    chemin relatif ne commençant pas par « ../  » ;
  • parent
    chemin relatif commençant par « ../  » ;
  • grandparent
    chemin relatif commençant par « ../../  ».

String

 

showXmlDeclaration

Si c'est vrai, une déclaration XML est incluse dans la sortie, si elle est fausse aucune déclaration n'est incluse. Le comportement par défaut donne seulement une déclaration XML quand on lui a demandé d'écrire dans un OutputStreamWriter qui utilise quelques encodages autres que UTF-8 ou UTF-16. Dans ce cas, l'encodage est montré dans la déclaration XML. Pour assurer que l'attribut d'encodage est montré dans la déclaration XML, soit :

  • définissez cette option à « true »  et utilisez la variante write(Model,Writer,String) avec un approprié OutputStreamWriter ;
    soit  :
  • définissez cette option à « false  » et écrivez la déclaration dans un OutputStream avant d'appeler write(Model,OutputStream,String).

String ou
Boolean

true, "true", false, "false" ou "default"

showDoctypeDeclaration

Si c'est vrai, une déclaration du doctype XML est incluse dans la sortie. Cette déclaration inclut une déclaration !ENTITY pour chaque préfixe associé dans le modèle, et toute valeur d'attribut qui commence avec l'URI de cette association est écrite comme commençant avec l'invocation de l'entité correspondante.

String ou
Boolean

true,
false,
"true",
"false"

tab

Le nombre d'espaces avec lesquels indenter les éléments enfants XML.

String ou
Integer

entier
positif
"2" est la
valeur par défaut

attributeQuoteChar

Comment écrire des attributs XML.

String

"\"" ou
"'"

blockRules

Une liste de Resource ou une String est une liste, séparée par une virgule, de fragments d'identifiants de http://www.w3.org/TR/rdf-syntax-grammar indiquant les règles de grammaire qui ne sont pas utilisées. Les règles qui peuvent être bloquées sont :  section-Reification( RDFSyntax.sectionReification))   section-List-Expand( RDFSyntax.sectionListExpand))   parseTypeLiteralPropertyElt( RDFSyntax.parseTypeLiteralPropertyElt)   parseTypeResourcePropertyElt( RDFSyntax.parseTypeLiteralPropertyElt)   parseTypeCollectionPropertyElt( RDFSyntax.parseTypeCollectionPropertyElt)   idAttr( RDFSyntax.idAttr) propertyAttr( RDFsyntax.propertyAttr) En outre, « daml:collection » (DAML_OIL.collection) peut être bloqué. Le blocage de idAttr bloque aussi la réification des sections. Par défaut, la règle propertyAttr est bloquée. Pour le module d'écriture (RDF/XML) de base, seul parseTypeLiteralPropertyElt n'a aucun effet, puisque aucune des autres règles n'est implémentée par ce module d'écriture.

Ressource[] ou String

 

prettyTypes

Seulement pour le module d'écriture RDF/XML-ABBREV. Ceci est une liste des types des objets principaux dans le modèle. Le module d'écriture aura tendance à créer du RDF/XML avec les ressources de ces types au niveau supérieur.

Un exemple d'utilisation montre une valeur appropriée pour la sortie DAML+OIL :

 
Sélectionnez
w.setProperty("prettyTypes",
         new Resource[]{
              DAML_OIL.Ontology,
              DAML_OIL.Class,
              DAML_OIL.Datatype,
              DAML_OIL.Property,
              DAML_OIL.ObjectProperty,
              DAML_OIL.DatatypeProperty,
              DAML_OIL.TransitiveProperty,
              DAML_OIL.UnambigousProperty,
              DAML_OIL.UniqueProperty,
              });

Resource[]

 

À titre d'exemple :

 
Sélectionnez
RDFWriter w = m.getWriter("RDF/XML-ABBREV");
w.setProperty("attribtueQuoteChar","'");
w.setProperty("showXMLDeclaration","true");
w.setProperty("tab","1");
w.setProperty("blockRules",
  "daml:collection,parseTypeLiteralPropertyElt,"
  +"parseTypeResourcePropertyElt,parseTypeCollectionPropertyElt");

crée un module d'écriture qui n'utilise pas rdf:parseType (préférant rdf:datatype pour rdf:XMLLiteral), indente seulement un peu et produit la déclaration XML. Les attributs sont utilisés et sont indiqués avec "'".

Notez que les attributs de propriété ne sont pas du tout utilisés par défaut. Toutefois, le module d'écriture RDF/XML-ABBREV inclut une règle pour produire les attributs de propriété lorsque la valeur ne contient pas d'espace. Cette règle est normalement désactivée, mais peut être activée sélectivement en utilisant la propriété blockRules comme détaillé ci-dessus.

VII. Sortie N3 avancée

L'affichage N3 amélioré (qui est utilisé par défaut) et le module d'écriture ordinaire N3 fournissent un grand nombre de propriétés pour contrôler leur sortie. Les propriétés commencent toutes par : http://jena.hpl.hp.com/n3/properties/. Le nom utilisé peut être le nom complet, en commençant avec cette chaîne de caractères, ou juste la forme courte du nom ci-dessous. Toutes les valeurs sont des chaînes de caractères ; elles peuvent être interprétées comme entier, booléen ou chaîne de caractères comme défini ci-dessous.

VII-A. Les sorties N3 avancées

Nom de la propriété

Description

Valeur par défaut

Les valeurs légales de chaîne de caractères

minGap

L'écart minimum entre les éléments sur une ligne.

1

entier positif

objectLists

Imprime les listes d'objets comme des listes séparées par une virgule.

true

booléen "true" ou "false"

subjectColumn

Si le sujet est plus court que cette valeur, la première propriété peut aller sur la même ligne.

indentProperty

entier positif

propertyColumn

Largeur de la propriété colonne.

8

entier positif

indentProperty

Largeur pour indenter les propriétés.

6

entier positif

widePropertyLen

Largeur de la propriété colonne.

20

entier, plus grand que propertyColumn

abbrevBaseURI

Contrôler si vous souhaitez utiliser des abréviations <> ou <#>.

true

booléen "true" ou "false"

usePropertySymbols

Contrôler si vous utilisez "a", "=" et "=\>" dans la sortie.

true

booléen "true" ou "false"

useTripleQuotedStrings

Autoriser l'utilisation de """ pour délimiter les chaînes de caractères longues.

true

booléen "true" ou "false"

useDoubles

Autoriser l'utilisation des doubles comme 123.456.

true

booléen "true" ou "false"

Note : seul l'affichage N3 amélioré affiche les listes d'objets comme des listes séparées par des virgules.

VIII. Conformité

L'entrée/sortie RDF/XML s'efforce de se conformer avec la recommandation de la syntaxe RDF.

L'analyseur doit être défini sur le mode strict. Notez que le comportement conforme aux rdf:parseType="daml:collection" est de transformer silencieusement "daml:collection" en "Literal".

Le module d'écriture RDF/XML est conforme, mais n'exerce pas une grande partie de la grammaire.

Le module d'écriture RDF/XML-ABBREV exerce toute la grammaire et est conforme, sauf qu'il utilise la construction daml:collection pour les ontologies DAML. Ce comportement non conforme peut être désactivé en utilisant la propriété blockRules.

IX. Entrée/sortie RDF/XML plus rapide

Pour optimiser la vitesse d'écriture du RDF/XML il est suggéré que tous les traitements d'URI soient désactivés. Aussi n'utilisez pas RDF/XML-abbrev. Il est difficile de savoir si l'attribut longId est plus rapide ou plus lent ; les identifiants courts doivent être générés à la volée et un tableau maintenu durant l'écriture. Les identifiants plus longs prennent plus de temps à écrire. Ce qui suit crée un module d'écriture plus rapide :

 
Sélectionnez
Model m;
...
...
RDFWriter fasterWriter = m.getWriter("RDF/XML");
fasterWriter.setProperty("allowBadURIs","true");
fasterWriter.setProperty("relativeURIs","");
fasterWriter.setProperty("tab","0");

Lors de la lecture de RDF/XML, la vérification pour la réutilisation de rdf:ID impose une surcharge de mémoire, qui peut être significative pour les très gros fichiers. Dans ce cas, cette vérification peut être supprimée en disant à ARP d'ignorer cette erreur.

 
Sélectionnez
Model m;
...
...
RDFReader bigFileReader = m.getReader("RDF/XML");
bigFileReader.setProperty("WARN_REDEFINITION_OF_ID","EM_IGNORE");
?

X. L'article original

Cet article est la traduction de Jena RDF I/O How-To.

XI. Remerciements

Merci à ALT, ClaudeLeloup, jacques_jean et _Max_ pour leur relecture orthographique ainsi qu'à Thibaut Cuvelier pour ses conseils.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2011-2016 Developpez.com Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.