Date
1 - 5 of 5
Janus as an RDF store
|
"Laura Morales" <laur...@...>
Hi all,
I'm relatively new to graph databases, and there seems to be a significant difference among "graph/property stores" and "RDF stores". Not a big difference in theory, but quite a big difference in practice about how these databases are implemented. So my question is, is Janus a graph/property store or an RDF store? Or can Janus do both? Can I, for example, use Janus to load a bunch of RDF dumps such as DBPedia/Wikidata and perform SPARQL queries over it? |
|
|
|
Jason Plurad <plu...@...>
JanusGraph provides native support for the property graph data model exposed by Apache TinkerPop and uses Gremlin as its query language. It does not have native support for RDF or SPARQL. That being said, you could write custom scripts to ingest RDF and transform it into a property graph model. Daniel Kuppitz started work on transforming SPARQL queries into Gremlin, and that effort continues on at https://github.com/LITMUS-Benchmark-Suite/sparql-to-gremlin If you are looking for something that does both, you might want to consider something like Stardog or BlazeGraph. On Thursday, March 30, 2017 at 9:35:11 AM UTC-4, Laura Morales wrote: Hi all, |
|
|
|
谭宇超 <archu...@...>
Hello Jason,I'm new to JanusGraph, and I didn't find any method that could load data-file into hbase. So, how can I load my data-file into hbase? ps: backend=hbase&caching 在 2017年3月30日星期四 UTC-7下午2:25:26，Jason Plurad写道：
|
|
|
|
Jason Plurad <plu...@...>
JanusGraph supports 3 file formats that are provided via Apache TinkerPop -- Gryo, GraphML, and GraphSON. http://tinkerpop.apache.org/docs/current/reference/#_gremlin_i_o You can load it like this: If you have some other format file, you'll need to write code to read it in the data file, and then construct the graph elements based on the data. On Thursday, July 27, 2017 at 9:40:30 AM UTC-4, 谭宇超 wrote:
|
|
|
|
serge...@...
In general Property graph and RDF store have each their own advantage and it's more than a difference in implementation. I used the word general as some vendors are trying to reduce those difference. For example, Stardog extended SPARQL with a PATH operator which allow you to easily traverse a path which would usually be easier in a property graph.
Things to consider are: Do you want to benefit from inference. For example, A isFatherOf B and B isFatherOf C you could add a rule that when you ask who 'isGrandFatherof' C it would return A without really having it in the database. You could load different rules which can be useful. So that clearly an advantage of RDF. However RDF does not support attribute on your relationship directly. While it could be model, it could get complicated and be slow if most relationship requires attribute. There are a few key difference like that that may make a technology better than another. I personally always start with a RDF solution, simply because I really am a fan of inference, and federated solution. If it does not work, it usually very easy to adjust the physical model to load in a property graph database. Therefore I really recommend that you read up on both technology as which one you should use could be dictated by your use case. |
|
|