Je suis intéressé par la persistance des graphes orientés individuels. Cette question ne demande pas une solution de base de données graphique à grande échelle, mais pour un format de document que je peux utiliser pour sauvegarder et arbitraire individuel graphe orienté. Je ne sais pas ce que la notation et le format de fichier serait le choix le plus intelligent. Strong> p>
Mes principales préoccupations sont: p>
Expressivité / flexibilité strong> - Je veux la capacité d'exprimer des graphiques de différents types. Bien que le cas d'une utilisation standard serait un graphique simple réalisé, il devrait être possible d'exprimer des arbres, , multi-graphiques . Comme un strict minimum, j'attendre un soutien pour l'étiquetage et la pondération des arêtes et des noeuds. Pour décrire higraphs et composition / hyper-bords serait hautement souhaitable, même si je suis conscient que ces solutions ne peuvent pas exister. p> li>
Type de système Indépendance strong> - Je suis intéressé à représenter les qualités structurelles des graphiques. Certaines solutions comprennent un système de type extensible pour les bords dactylographiée et noeuds (par exemple RDF / OWL ). Je ne être intéressé par une telle représentation, il y avait une décomposition canonique clairement défini d'éléments typés en primitives (noeuds / arêtes / attributs). Ce que je suis en train d'éviter ici est la possibilité pour de multiples représentations de graphiques équivalentes, où l'équivalence n'est pas visible. P> li>
Représentation Canonique strong> -. Il devrait y avoir un mécanisme qui permet le graphique à représenter canoniquement (de telle sorte que l'équivalence lexicale des représentations-canoniques pourrait être utilisé pour déterminer l'équivalence) < / p> li>
Présentation indépendant strong> - Je préférerais une notation qui ne dépend pas de la présentation du graphique. Cela inclurait l'orientation spatiale, les couleurs, la police, etc. Je ne suis intéressé à représenter les données. L'une des caractéristiques que je ne aime pas sur le DOT langue , ou href="http://en.wikipedia.org/wiki/Scalable_Vector_Graphics"> SVG (au moins à cet effet particulier) est l'accent mis sur représentation visuelle. p> li>
normalisé / Open / Compatible strong> - Moins de travail de mise en œuvre que je dois faire, le mieux. Si le format est standardisé et des outils fiables existent déjà pour travailler avec le format, il est plus préférable. Accompagnant cette exigence est une autre, que le format devrait être hautement compatible. La nature exclusive de DGML Microsoft est une raison de mon aversion, en dépit de l'outillage Visual Studio et le fait que je travaille principalement avec .NET (maintenant). Le fait que le W3C publie des normes RDF est une motivation pour examiner un sous-ensemble limité de RDF comme outil de représentation. Je vous remercie également GXL et graphml , parce qu'ils ont bien documenté des schémas XML, facilitant ainsi la possibilité d'intégrer leurs données avec un logiciel compatible XML. p> li>
Simplicité / Lisibilité strong> - J'apprécie la syntaxe lisible par l'homme et la facilité d'interprétation. J'apprécie également la représentation qui permet de simplifier l'analyse syntaxique. Pour cette raison, je aime GML , mais je suis préoccupé il ne suffit pas d'être grand public un choix réaliste. Je voudrais également envisager JSON ou YAML la lisibilité, si elles ne l'étaient pas limitées dans leurs capacités respectives à représenter des structures complexes (non-DAG). p> li>
Efficacité / Représentation Concise strong> - Il est intéressant de considérer que quel que soit le format, je finis par choisir devra inévitablement être persisté et transféré sur un certain réseau. Par conséquent, la taille du fichier est une considération pertinente. p> li>
ol>
Je reconnais que je très probablement incapable de trouver une solution qui satisfait tous les critères sur ma liste. Je demande simplement le format de fichier qui est le plus proche de ce que je veux strong> et ne limite pas l'extensibilité strong> pour les cas d'utilisation non pris en charge. P>
Aperçu h2>
3 Réponses :
ObwindyPreamble: Dans le monde RDF, il existe un Gazillion des formats de syntaxe de surface différents à choisir. RDF elle-même est un métamodèle abstrait pour les données, pas directement une "syntaxe de graphique". Vous pouvez bien sûr représenter directement un graphique dans RDF (puisque les modèles RDF sont em> graphs), mais étant donné que vous souhaitez représenter différents types de graphiques, vous risquez de vous retrouver à abstraire et à créer un Vocabulaire RDF pour représenter différents types de graphiques. Dans l'ensemble, je ne suis pas convaincu que RDF est le meilleur moyen d'aller pour vous, mais si vous en choisissez un, je dirais que le RDF est modèles RDF suivez à peu près la sémantique définie, ce qui signifie qu'une représentation de syntaxe canonique ne peut pas vraiment être appliquée: deux fichiers peuvent avoir des informations dans un ordre différent sans qu'il affectant le modèle réel, ni même contenir des informations en double. Toutefois, si vous appliquez un algorithme de tri simple lors de la production de fichiers (quelque chose pour lequel la plupart des analyseurs / écrivains de RDF ont un soutien), vous devriez être capable de s'en tirer avec des comparaisons à base de ligne et de déterminer l'équivalence de graphique basée sur la syntaxe de surface. p> juste comme un exemple simple, supposons que nous avons un graphique très simple, dirigé et étiqueté: p> Vous pouvez le représenter directement dans RDF, comme Suit (Utilisation de la syntaxe de tortue): p> dans une modélisation plus abstraite, vous pouvez faire quelque chose comme ceci: p> Ce qui précède n'est qu'un exemple simpliste bien sûr, mais j'espère qu'il montre que cela répond potentiellement à quelques-unes des choses sur votre liste de souhaits. P> Au fait, si vous voulez même plus simple, N Triples est également une syntaxe RDF, qui est basée sur la ligne et donc facile à traiter de manière en streaming. Il est légèrement plus verbeux que la tortue, mais elle peut faciliter la comparaison de fichiers. p> p>
J'apprécie l'aperçu et c'est l'une des options que j'ai envisagées. Je conviens que la syntaxe de tortues est la saveur RDF qui est la plus cohérente avec mes exigences, cependant, il n'est pas clair de votre réponse Pourquoi RDF est la meilleure alternative, ou même que vous le pensez.
C'est parce que je ne sais pas que c'est :) Je pense que cela pourrait être approprié, mais je ne connais pas les autres alternatives. RDF est une approche plus abstraite de la modélisation des données, ce qui vous donne beaucoup de flexibilité, mais si tout ce que vous cherchez est un format de fichier rapide N-Easy, il pourrait être surchargé.
Mon problème avec RDF est que vous pouvez représenter un seul concept sémantique avec des variations infinies de la syntaxe. Cet attribut ressemble à une recette pour: (1) redondance non intentionnelle; (2) complexité arbitraire; et, (3) des performances terribles avec une ontologie d'une taille importante.
Mes pensées: p>
Ce qui me manque, c'est votre objectif pratique / domaine pratique. P> li>
Vous mentionnez le format JSON Generic JSON à côté de formats spécifiques (par exemple graphml, une application de XML). Donc, je suis laissé avec la question si vous faites ou que vous ne considérez pas de faire votre propre format. P> li>
ne serait pas une représentation canonique 'qui peut être utilisée pour déterminer l'équivalence' em> résoudre le Problème d'isomorphisme graphique ? P> LI>
graphml semble couvrir beaucoup de vos exigences théoriques. Je vous suggère donc de créer une version JSON de ceci. Cela couvrirait alors également les exigences 6. P> li>
Ensuite, vous pouvez créer un convertisseur entre le format JSON et le graphml (et éventuellement d'autres formats). P> li>
Pour votre exigence 7, tout dépend de la taille du graphique pratique. Je veux dire, de nos jours envoyant jusqu'à quelques MB à un périphérique mobile Friggin ne sont pas considérés comme beaucoup. Un graphique de quelques MB dans (environ) n'importe quel format que vous mentionez, est déjà une bête relativement grande avec des dizaines de milliers de nœuds et de bords. P> li>
ul>