Serialisation d'individus - librairie trop orientée ontologie ?

[Bloodbee]

Bonjour à vous,

J'ai pour besoin de sérialiser des individus, mais pas leur classes correspondantes. Je m'explique:

Mon entreprise possède une cinquantaine d'ontologies privées et chacunes de ces ontologies définies des classes, des propriétés, et sont généralement inter-dépendantes.

Avec owlready2 et l'outil que j'ai mis en place, je peux charger une ontologie, ses dépendances/sous-dépendances, et proposer aux développeur les classes et propriétés correspondantes.

Le développeur peut donc faire ce genre de chose dans son code :

from profile_foo import Foo
from rdflib import URIRef

stuff = Foo.Stuff(URIRef('http://www.mycompany.com/profile/foo/resource/21cd5ca0-60d9-47cc-8cdb-20861a24f118'))

stuff.dataproperty1 = 42
stuff.dataproperty2 = "Toto"

print(Foo.base_iri) # http://www.mycompany.com/ontology/foo/1.1
print(stuff.iri) # http://www.mycompany.com/profile/foo/resource/21cd5ca0-60d9-47cc-8cdb-20861a24f118

...

Tout cela fonctionne très bien, et quand je veux récupèrer le graph complet de mon ontologie Foo, c'est parfait.

J'aimerais savoir si c'est possible (en prenant en compte mon example précédent), de ne pouvoir récupèrer le graph que d'un individu précédemment instancié ?

Par exemple

print(stuff.as_rdflib_graph().serialize())  # methode serialize de rdflib

afficherait :

@prefix ns1: <http://www.mycompany.com/ontology/foo/1.1#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.mycompany.com/profile/foo/resource/21cd5ca0-60d9-47cc-8cdb-20861a24f118> a ns1:Stuff ;
ns1:dataproperty1 42 ;
ns1:dataproperty2 "Toto"^^xsd:string .

C'est à dire, compartimenter la récupèration de graph sur un individu, une classe ou une propriété. Non sur toute l'ontologie. Tout en gardant la fonctionnalité de base aussi.

Une idée ou des pistes pour réaliser ce genre de chose ?

Merci et bravo pour cette lib en tout cas !

[Jiba]

Bonjour,

Une possibilité est de créer chaque individu dans une ontologie à part. On peut alors lister les triplets d'une seule ontologie-individu, ou bien concaténer les triplets de toutes les ontologies-individus pour les avoir toutes.

Extraire les triplets concernant un individu n'est pas si facile que cela, par exemple faut-il inclure les relations inverses, lorsque l'individu est donc l'objet d'une relation ?

Vous pouvez utiliser l'argument optionnel "filter" de la méthode save() pour filtrer les triplets à enregistrer, par exemple le code suivant permet d'enregistrer uniquement les triplets ayant pour sujet l'individu "stuff" :

onto.save("/tmp/t.nt", format="ntriples", filter = lambda graph, s, p, o, d: s == stuff.storid)

Jiba

[Bloodbee]

Bonjour,

Merci pour votre réponse.

J'ai vu dans la documentation que la méthode .save peut prendre en argument un nom de fichier ou un file-like object.

Je suis donc partit sur ce début de solution, en passant un fichier temporaire à .save:

from owlready2 import *
from rdflib import Graph
import tempfile

onto = get_ontology('http://mycompany.com/ontology/foo/1.1)

class Stuff(Thing):
     namespace = onto

     def graph(self):
        print('Storid', self.storid)
        with tempfile.TemporaryFile() as fp:
            onto.save(fp, format="ntriples", filter = lambda graph, s, p, o, d: s == self.storid)

            print('Content file', fp.read())
            graph = Graph()
            graph.parse(fp, format='nt')

            return graph

Cependant, lorsque j'essaye d'utiliser cette méthode, je n'ai pas un output concluant. J'ai l'impression qu'il n'arrive pas à filtrer correctement les triplets et relations liés via le storid. Voici ce que j'ai sur ma sortie standard :

Storid 389
Content file b''

Avez-vous une piste ?
Merci à vous !

[Jiba]

Bonjour,

Je pense que le problème est dans l'utilisation du fichier temporaire : c'est le même objet fichier qui est utilisé pour écrire puis pour lire. Mais la lecture commence à la position courante dans le fichier, c'est à dire... la position APRES l'écriture !

Pour résoudre le problème, il faut revenir au début du fichier en ajoutant  fp.seek(0)  juste avant la lecture.

Jiba

[Bloodbee]

Bonjour,

Vous avez raison, il faut procéder à un déplacement de la tête de lecture en début de fichier.

Merci à vous, ce thread peut-être fermé.