Today we added a plug-in to the 2.1 ver­sion of the com­mu­nity edi­tion of GraphDB which is called “FastIm­port”. It’s basi­cally a bulk import plug-in which takes a pro­pri­etary XML for­mat as input and imports ver­tices and edges into a run­ning GraphDB instance.

In order to use this new plug-in and import fea­ture you need to know that an import basi­cally splits into a two-stage process:

1. scheme setup
2. fast-import

So first you’ll have to define which ver­tex and edge types get imported by the fol­low­ing step 2 – you nor­mally do this using the GraphQL and spec­i­fy­ing sev­eral ver­tex types. For demon­stra­tion pur­poses we take a small social net­work with only one ver­tex type:

CREATE VERTEX TYPE User ATTRIBUTES (String Name, Int64 Age, Set<User> Friends)

After hav­ing set-up the scheme the only thing left is to actu­ally call the import plug-in using another short GraphQL query:

IMPORT FROM ‘file:\\100k_import.xml’ FORMAT FastImport

This will, for exam­ple, take the 100.000 user dataset and import it into the cur­rent GraphDB instance. Of course we did that already for you so here are the com­par­i­son results between a GraphQL and FastIm­port and the per­sis­tent and In-Memory ver­sion of GraphDB:

Of course you can also down­load the data-sets used in this small bench­mark here:

10.000 Users / 592.374 edges : GraphQL Import , FastIm­port

100.000 Users / 5.944.332 edges : GraphQL Import, FastIm­port

No comments

DBPe­dia data is pro­vided in sev­eral RDF triple files. Each line in each file gives a “com­plete” infor­ma­tion set – based on pred­i­cate, sub­ject and object, e.g.

mappingbased_properties_en.nt: (some line)
<http://dbpedia.org/resource/12_Monkeys>
<http://dbpedia.org/ontology/editing>
<http://dbpedia.org/resource/Mick_Audsley> .       
stands for:  “12 Mon­keys” has a “edi­tor” “Mick Audsley”.

In other files there is addi­tional infor­ma­tion avail­able, e.g. that

• “12 Mon­keys” is a film
• “Mick Aud­s­ley” is a person
• … prob­a­bly more infor­ma­tion about “12 Mon­keys” and “Mick Audsley”

What we want to do in sones GraphDB is to cre­ate a VERTEX for the film “12 Mon­keys”. This includes

• type infor­ma­tion – 12 Mon­keys is a film
• a set of prop­er­ties – e.g. its budget
• EDGES to related infor­ma­tion, e.g. the edi­tor Mick Audsley.

There is a sin­gle point of infor­ma­tion (The VERTEX “12 Mon­keys”) that holds all infor­ma­tion and rela­tion in a sin­gle instance. To import the VERTEX “12 mon­keys”, we had to write a parser over all avail­able triple files that gives us all related infor­ma­tion from DBPe­dia data set.
At this point we’ve had two options imple­ment­ing this parser. The first one was to read all triple files in a ded­i­cated order to ensure data valid­ity (we need to know that “12 Mon­keys” is a movie, to be able to assign the pred­i­cate “edi­tor” unam­bigu­ous) or do an inter­me­di­ate step by cre­at­ing a tem­po­rary file that col­lects all data with­out val­i­da­tion and to do the import after­wards.
Our deci­sion was to do the inter­me­di­ate step, because of that it allows some syn­chro­niza­tion dur­ing read­ing the triple files and avoids cre­at­ing invalid data since exported data can be cross-checked eas­ily.
This step is rep­re­sented by project “2_ParseAndConvertTripleDataFiles” in solu­tion GraphDB­Pe­dia avail­able at http://github.com/sones/sones-dbpedia.  The parser reads only a sub­set of offered data-files to show func­tion­al­ity and focus on the added val­ues.
The result of the export for “Apollo 8” looks like this:

1  VertexID=-9223372036854775808
2  http://dbpedia.org/resource/Apollo_8=http://dbpedia.org/ontology/SpaceMission
3  LongAbstract_de=viel text
4  LongAbstract_en=a lot of text
5  http://dbpedia.org/ontology/commandModule_en=CM-103
6  http://dbpedia.org/ontology/missionDuration_en=529242.0
7  http://dbpedia.org/ontology/lunarOrbitTime_en=72613.0
8  http://dbpedia.org/ontology/crewSize_en=3
9  http://dbpedia.org/ontology/lunarModule_en=Ballast: Lunar Test Arti­cle B
10  http://dbpedia.org/ontology/serviceModule_en=SM-103
11  http://dbpedia.org/ontology/nextMission_en=http://dbpedia.org/resource/Apollo-9-patch.png
12   http://dbpedia.org/ontology/booster_en=http://dbpedia.org/resource/Saturn_V
13   http://dbpedia.org/ontology/previousMissions_en= http://dbpedia.org/resource/AP7lucky7.png
14   http://dbpedia.org/ontology/launchPad_en=http://dbpedia.org/resource/Kennedy_Space_Center_Launch_Complex_39
15   ShortAbstract_en=some text
16   Name_en=http://dbpedia.org/resource/Apollo_8
17    http://dbpedia.org/ontology/SpaceMission/lunarOrbitTime_en=20.170277777777777
18   http://dbpedia.org/ontology/SpaceMission/missionDuration_en=6.125486111111111

Apart from one prop­erty, all data had been exported from the triple files. Dur­ing import­ing the ontol­ogy infor­ma­tion (line2 in this exam­ple), we’ve also cre­ated a Ver­texID – unique for the cor­re­spond­ing VERTEX TYPE. This allows us to do a unique and per­for­mant link­ing dur­ing data import (hap­pens later) by refer­ring to this ID.

After this inter­me­di­ate step, the real import step can be done. Sones Graph DB offers GraphQL as sim­ple and intu­itive lan­guage. Based on the data-structure we’ve pre­pared above, with GQL two steps have to be done. At first, cre­ate all VERTICES includ­ing all prop­er­ties and after­wards do the link­ing between all VERTICES.
There­fore, for the exam­ple above, two state­ments would be created:

 INSERT INTO http­wwwdb­pe­diaor­gontol­ogy­Space­Mis­son VALUES (
   VertexID=-9223372036854775808,
   LongAbstract_de=’viel text’,
   LongAbstract_en=’a lot of text’,
   Name_en=’ http://dbpedia.org/resource/Apollo_8’,
   httpdbpediaorgontologycommandModule_en=’CM-103’,
   httpdbpediaorgontologymissionDuration_en=529242.0,
   httpdbpediaorgontologylunarOrbitTime_en=72613.0,
   httpdbpediaorgontologycrewSize_en=3,
   httpdbpediaorgontologylunarModule_en=’Ballast: Lunar Test Arti­cle B’,
   httpdbpediaorgontologyserviceModule_en=’SM-103’,
   ShortAbstract_en=’some text’,
   httpdbpediaorgontologySpaceMissionlunarOrbitTime_en=20.170277777777777,  
   httpdbpediaorgontologySpaceMissionmissionDuration_en=6.125486111111111

UPDATE http­wwwdb­pe­diaor­gontol­ogy­Space­Mis­son SET
(
   httpdbpediaorgontologynextMission_en=SETOF(Name_en=’http://dbpedia.org/resource/Apollo-9’)
   httpdbpediaorgontologybooster_en=SETOF(Name_en=’http://dbpedia.org/resource/Saturn_V’)
httpdbpediaorgontologypreviousMission_en=SETOF( Name_en=’http://dbpedia.org/resource/AP7’)
httpdbpediaorgontologylaunchPad_en=SETOF(Name_en=’http://dbpedia.org/resource/Kennedy_Space_Center_Launch_Complex_39’)
)
WHERE VertexID=-9223372036854775808

The prob­lem of this approach is, that EDGES are set via a WHERE con­di­tion that maybe is not unique or the attribute is not set at all at the tar­get VERTEX. An option to solve this, is to ver­ify the ID of the tar­get ver­tex and do the link­ing via this condition.

Sones GraphDB also offers another option to do the import­ing, Xml­BulkIm­port. It has the advan­tage that it is faster than GraphQL (due to the fact it uses Graph-filesystem inter­faces) and also orga­nizes INSERTING and LINKING of data itself. Instead of cre­at­ing GraphQL, a pro­pri­etary XML struc­ture has to be cre­ated and the import is done via a sin­gle IMPORT GQL state­ment.
A descrip­tion of this for­mat and its usage can be found at: http://developers.sones.de/wiki/doku.php?id=importexport:xmlbulkimport

This Xml­BulkIm­port data file is cre­ated by project “3_ParseAndConvertTripleDataFiles” in solu­tion GraphDB­Pe­dia avail­able at http://github.com/sones/sones-dbpedia”.

No comments

The first step was to trans­fer the ontol­ogy – pro­vided in Web Ontol­ogy Lan­guage (OWL) for­mat – into GraphDB VERTEX TYPES and EDGES. There­fore, a parser had been imple­mented that reads the OWL-file, con­verts it into a class-model and is able to export data into a GQL – CREATE VERTEX TYPES state­ment.
The  ontol­ogy cur­rently con­tains 273 classes (DBPe­dia 3.6.) and thou­sands of datatype prop­er­ties and object prop­er­ties. A short demon­stra­tion of its main struc­tures can be found here:

OWL-Class:

<owl:Class rdf:about="http://dbpedia.org/ontology/Island">
   <rdfs:label xml:lang="en">island</rdfs:label>
    <rdfs:label xml:lang="el">νησί</rdfs:label>
    <rdfs:label xml:lang="fr">île</rdfs:label>
    <rdfs:subClassOf
           rdf:resource="http://dbpedia.org/ontology/PopulatedPlace">
    </rdfs:subClassOf>
</owl:Class>

- rep­re­sents an Island (based on a PopulatedPlace)

OWL-DatatypeProperty:

<owl:DatatypeProperty rdf:about="http://dbpedia.org/ontology/numberOfIslands">
   <rdfs:label xml:lang="en">number of islands</rdfs:label>
    <rdfs:domain rdf:resource="http://dbpedia.org/ontology/Island"></rdfs:domain>
    <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#nonNegativeInteger"></rdfs:range>
</owl:DatatypeProperty>

- describes the non-negative Inte­ger attribute “num­ber of islands” for the class Island.

OWL-ObjectProperty:

 <owl:ObjectProperty rdf:about="http://dbpedia.org/ontology/highestState">
    <rdfs:label xml:lang="en">highest state</rdfs:label>
    <rdfs:domain rdf:resource="http://dbpedia.org/ontology/Island"></rdfs:domain>
    <rdfs:range rdf:resource="http://dbpedia.org/ontology/PopulatedPlace"></rdfs:range>
</owl:ObjectProperty>

rep­re­sents the high­est “Pop­u­lat­ed­Place” on an island.

The con­ver­sion cre­ates a

• VERTEX TYPE  – one for each class,
• hav­ing mul­ti­ple PROPERTIES – from datatype properties
• and mul­ti­ple EDGES – from object-properties

Within the data schema, there is a big amount of multi-lateral depen­den­cies. The CREATE VERTEX TYPES state­ment solves all of them and cre­ates a valid data schema.

Addi­tion­ally to the ontol­ogy from the OWL file, we’ve added some ver­tex types to fix some prob­lems we’ve run at and to enhance the func­tion­al­ity a lit­tle bit:

• At first, the VERTEX TYPE Thing was not described in the Ontol­ogy. It is the base class in the ontol­ogy that all other VERTEX TYPES are base upon.
• To reflect dis­am­bigua­tion, we’ve cre­ated a VERTEX TYPE Instance with an EDGE to a SET of Thing. In case there is a dis­am­bigua­tion, an Instance refers to the cor­re­spond­ing NODEs in the GraphDB.
• Within the RDF-files, labels are saved in ded­i­cated triples. We’ve added a ded­i­cated VERTEX TYPE also, to avoid a mix-up in case one label refers to mul­ti­ple Instances.

Cur­rently, the GraphDB has some lim­i­ta­tions regard­ing the allowed char­ac­ters within VERTEX TYPES, its ATTRIBUTES and EDGES. The OWL and RDF for­mat is gen­er­ally based on URLs as data-definition. GraphDB has lim­i­ta­tions work­ing with colons, dots  and slashes (both slash and back­slash). Our sim­ple workaround was to keep the URL and remove all occur­rences of these char­ac­ters. This leads us from http://dbpedia.org/ontology/Island to httpdbpediaorgontologyIsland.

Another chal­lenge is the type-mapping between OWL and GraphDB. GraphDB sup­ports c# sim­ple data types, in the DBPe­dia OWL we are fac­ing a list of 9 datatypes from an XML schema,  DBPe­dia area units, speed units, den­sity units, time units, vol­ume units, dis­tance units and sev­eral oth­ers. This led us to a huge switch that does the map­ping – all prop­er­ties could be reflected with the C# data types with­out data loss.

Wikipedia is avail­able in mul­ti­ple lan­guages. DBPe­dia export cur­rently is pro­vided in 99 of them.
Some time later (dur­ing the next steps) we’ve found out that data in sev­eral lan­guages dif­fers a lit­tle bit some­times, since there are dif­fer­ent authors. For the data schema, this is rel­e­vant, because there are options how to han­dle this behavior.

One option is to let the data importer appli­ca­tion logic decide how to han­dle this. We’ve decided to make the data schema lan­guage spe­cific and pro­vide a sep­a­rate – lan­guage spe­cific – attrib­utes. This grows up the data schema a lit­tle bit, but does not lead to any data loss. Addi­tion­ally, some appli­ca­tion logic can be imple­mented later on, to check data qual­ity for each node.

The command-line  tool “1_CreateGqlSchemaFromOntology” ‚avail­able at GitHub (https://github.com/sones/sones-dbpedia) Visu­al­Stu­dion solu­tion cre­ates the CREATE VERTEX TYPES state­ments as described above, based on the ontol­ogy of DBPe­dia 3.6. – later ver­sions cur­rently have not yet been tested.
The com­mand line exe­cutable has to be started with 2 parameters:

• .owl file­name (the file­name has either to be an absolute path or located within the exe­cuta­bles directory.
• result .gql file – name of the file, where all queries will be inserted in.

Dur­ing run­time, the user will be requested for all lan­guages that have to be reflected in schema. Our sug­ges­tion is to use 2-letter county-codes like “_en” or “_de”. An empty string exits the iter­a­tion.
After the exe­cu­tion the result .gql file eas­ily can be imported via IMPORT GQL statement.

No comments

DBPe­dia already is saved in a machine read­able for­mat (RDF). We’ve started a proof-of-concept to show that GraphDB is able to solve these require­ments too and to find out dif­fer­ences, advan­tages and dis­ad­van­tages of the dif­fer­ent con­cepts.
In RDF, the data model stands next to the data. Within sones GraphDB there is close con­nec­tion between each object (node) and it’s (Ver­tex) type. For exam­ple the node “Homer Simp­son” knows that he’s a “Fic­tion­alChar­ac­ter”.
Our expec­ta­tion was, that GraphDB requires less hard-disk space and also offers a bet­ter data store, since all infor­ma­tion about an object is saved in a unique node instead of  sev­eral triple-data-files. Besides, any rela­tion­ship between two objects (e.g. a per­son and its birth-place) is saved directly on that object. While load­ing a node, all infor­ma­tion is avail­able from a sin­gle loca­tion.
Dur­ing project run­time we’ve dis­cov­ered sev­eral prob­lems that can be solved with that idea. The aris­ing data net­work enables cus­tomers to find out com­plex rela­tion­ships between any node using graph-algorithms. Dis­am­bigua­tion of words is pos­si­ble, using the schema infor­ma­tion (e.g. Tuareg can be either nomads liv­ing in the Sahara or a vehi­cle built by a Ger­man car vendor).

No comments

We’ve had our first con­tacts with DBPe­dia in May 2010 already. A prospect asked us, whether or not GraphDB is the best way to reflect the data schema and import all data. After get­ting a first impres­sion from the DBPedia-Website:

from www.dbpedia.org/About:

“DBpe­dia is a com­mu­nity effort to extract struc­tured infor­ma­tion from Wikipedia and to make this infor­ma­tion avail­able on the Web. DBpe­dia allows you to ask sophis­ti­cated queries against Wikipedia, and to link other data sets on the Web to Wikipedia data. We hope this will make it eas­ier for the amaz­ing amount of infor­ma­tion in Wikipedia to be used in new and inter­est­ing ways, and that it might inspire new mech­a­nisms for nav­i­gat­ing, link­ing and improv­ing the ency­clopae­dia itself.”

We’ve decided: Yes, it is!.

 from www.dbpedia.org/Datasets:

DBpe­dia uses the Resource Descrip­tion Frame­work (RDF) as a flex­i­ble data model for rep­re­sent­ing extracted infor­ma­tion and for pub­lish­ing it on the Web. We use the SPARQL query lan­guage to query this data. Please refer to the Devel­op­ers Guide to Seman­tic Web Toolk­its to find a devel­op­ment toolkit in your pre­ferred pro­gram­ming lan­guage to process DBpe­dia data.

The DBpe­dia knowl­edge base cur­rently describes more than 3.64 mil­lion things, out of which 1.83 mil­lion are clas­si­fied in a con­sis­tent Ontol­ogy, includ­ing 416,000 per­sons, 526,000 places (includ­ing 360,000 pop­u­lated places), 106,000 music albums, 60,000 films, 17,500 video games, 169,000 orga­ni­za­tions (includ­ing 40,000 com­pa­nies and 38,000 edu­ca­tional insti­tu­tions), 183,000 species and 5,400 diseases.

At this time we’ve not yet had too much expe­ri­ences with the Seman­tic Web, there­fore there was prob­a­bly some work to do.

The fol­low­ing blog arti­cles will describe our work and refer to the source-code avail­able under www.github.com/sones/sones-dbpedia

No comments

In the course of our work at sones GraphDB 2.1 we refac­tored our index inter­faces to make them more suit­able for our needs. Fur­ther­more, we wanted to make it eas­ier for the com­mu­nity to imple­ment cus­tom index struc­tures for their spe­cial needs. For the lat­ter rea­son we set up a tuto­r­ial and pub­lished a sam­ple imple­men­ta­tion on github.

The inter­faces are explained in our devel­oper wiki, the tuto­r­ial can also be found there. The source code regard­ing the tuto­r­ial is located at github.

Source 1: Index Inter­faces at devel­oper wiki
Source 2: Inte­gra­tion tuto­r­ial at devel­oper wiki
Source 3: Source code at github

No comments

We always think about new ways to inte­grate GraphDB into exist­ing envi­ron­ments. And one of those envi­ron­ments our users are work­ing with right now are the sev­eral Enter­prise Ser­vice Busses which are avail­able right now.

One big player in the ESB envi­ron­ment is the Mule Open Source ESB:

“Mule is a light­weight enter­prise ser­vice bus (ESB) and inte­gra­tion frame­work. It can han­dle ser­vices and appli­ca­tions using dis­parate trans­port and mes­sag­ing tech­nolo­gies. The plat­form is Java-based, but can bro­ker inter­ac­tions between other plat­forms such as .NET using web ser­vices or sockets.

The archi­tec­ture is a scal­able, highly-distributable object bro­ker that can seam­lessly han­dle inter­ac­tions across legacy sys­tems, in-house appli­ca­tions and almost all mod­ern trans­ports and protocols.”

In order to show how a GraphDB inte­grates into those typ­i­cal ESB envi­ron­ments we cre­ated a small example.

The archi­tec­ture of this exam­ple is like this:

The idea behind this is that an exam­ple Message-WebApp is post­ing a mes­sage to the Mule ESB and then this mes­sage gets trans­formed and in the last con­se­quence con­sumed by a sones REST­ful web­ser­vice hosted by a GraphDB.

You can read more in this tuto­r­ial here and you can down­load the source­code here.

Source 1: http://www.mulesoft.org/
Source 2: https://github.com/sones/sones-mule
Source 3: http://developers.sones.de/wiki/doku.php?id=tutorials:muleexampleapp

No comments

With ver­sion 2.0 of sones GraphDB we intro­duced an enhanced graph model we call Prop­erty Hyper­graph.

In this Prop­erty Hyper­graph model there are some stan­dard edge types:

• single-edge: an edge between two vertices
• multi-edge: an edge split­ting up into single-edges of the same edge type point­ing towards the same ver­tex type.
• hyper-edge: an edge to a sub­graph made up by all pos­si­ble types of vertices

In order to cre­ate dif­fer­ent ver­tex types since ver­sion 1.0 of sones GraphDB the GraphQL com­mand “CREATE VERTEX TYPE” is avail­able to users. In ver­sion 2.0 we intro­duced edge types but those were only use­able if you would use the API to inter­act with the GraphDB instance.

In ver­sion 2.1 we’ve now added a full edge type man­age­ment to be used either through GraphDBs new edge-type API and of course through the new GraphQL exten­sions which add edge-type handling.

So for exam­ple let’s say you want to cre­ate an edge type “User” and insert a bunch of those. And you want those users to be con­nected by a spe­cific edge type which comes with it’s own attrib­utes – some­thing like this:

The GraphQL Queries to cre­ate the above scheme would be these:

CREATE EDGE TYPE User­Link ATTRIBUTES (Dou­ble weight, String pri­or­ity, LIST<String> tags) COMMENT = ‘This is my edge type named User­Link.’
CREATE VERTEX TYPE User ATTRIBUTES (String name, SET<User(UserLink)> friends)
INSERT INTO User VALUES (name = ‘UserA’)
INSERT INTO User VALUES (name = ‘UserB’, friends = SETOF(name = ‘UserA’ : (weight = 15.5, pri­or­ity = ‘high’, tags = LISTOF(‘best friend’, ‘mate’))))

As you can see it’s easy to actu­ally cre­ate edge types and add attrib­utes to the rela­tion­ships these edges rep­re­sent. It even gets bet­ter: you can also use the inher­i­tance mech­a­nisms you are already used to on ver­tex types as well as unde­fined (scheme­less) attributes.

If you want to dive deeper into edge types you won’t have to wait until the release of GraphDB 2.1 at the end of this year. You can just grab the cur­rent source code on github and get started.

Addi­tional doc­u­men­ta­tion and exam­ples are avail­able in our doc­u­men­ta­tion wiki. Here are some places you will find more information:

• Edges in GraphDB
• GraphQL data def­i­n­i­tion lan­guage (DDL)

No comments

Not long ago we showed off the new capa­bil­i­ties of GraphDB 2.1 (to be released at the end of 2011) regard­ing the visu­al­iza­tion of data. Now we extended that capa­bil­i­ties and added another Out­put Plug-In to the Com­mu­nity Edi­tion. It’s called GraphVis.

And you can down­load it now with our source-code pack­age from our GitHub repos­i­tory.

The best way to show-off the new func­tion­al­ity is by lit­er­ally show­ing it:

A good start for the doc­u­men­ta­tion of the new visu­al­iza­tion options is our ever grow­ing wiki.

5 comments

As you might have noticed by the check-ins on the source code repos­i­tory we are well on the way towards ver­sion 2.1 of sones GraphDB. Besides the many new fea­tures and fixes we just merged a fea­ture branch into the main repos­i­tory which con­tains the first steps of a sim­ple but already pow­er­ful visualization.

For some time now we are look­ing into ways to visu­al­ize the data stored in GraphDB and since todays web browsers come with HTML5 fea­tures the idea was born to inte­grate a future visu­al­iza­tion into the exist­ing inte­grated Web­Shell and the future web admin­is­tra­tion tool.

The Web­Shell is an inte­grated mod­ule of GraphDB which allows the user to access sones GraphDB by just log­ging in using a web browser.

With the abil­ity to run queries and use plug-ins to deter­mine how the out­put will look like the Web­Shell is a per­fect place to enhance user expe­ri­ence. Since there are sev­eral out­put plug-ins avail­able with ver­sion 2.0 already (JSON, XML, Text, HTML,…) we thought it would be a great idea to have a sim­ple visu­al­iza­tion imple­mented just by adding a new out­put plug-in to GraphDB.

And that’s what we did in the first step: We added an addi­tional out­put plug-in called “bar­chart”. This first new out­put plug-in uses the great D3.js library to draw nice charts, plots and graphs in HTML5 and the GraphQL ALIAS fea­ture to map x and y coordinate-axes of those visualizations.

A bit tricky is how multi-level map­pings of x– and y-axes are han­dled, we are still work­ing on that. But cur­rently if your data is in the same level you can already out­put nice graphs like this one:

Just by switch­ing to the bar­chart for­mat using the FORMAT Web­Shell com­mand and then chang­ing a query like this:

FROM Simp­son­Char­ac­ter SELECT Friend.Name, Friend.Friend.Count() WHERE Name = “Homer Simpson”

into

FROM Simp­son­Char­ac­ter SELECT Friend.Name AS x, Friend.Friend.Count() AS y WHERE Name = “Homer Simpson”

Since the cur­rent state is only the begin­ning we will add more visu­al­iza­tion options and fea­tures for the release of GraphDB ver­sion 2.1 at the end of this year.

No comments