The IdAS-XDI-Mapping is documented here: http://wiki.eclipse.org/IdAS_XDI_Mapping
In theory, the Java XDI CP, the Attribute Service, and the C++ XDI CP should all implement that mapping, however - the wiki page itself may be a bit outdated in a few details - the Java XDI CP (higgins.idas.cp.xdi) implements an older version of the mapping and is therefore not ready for use. I don't really have an overview of what's needed to make it work For a native XDI store, I believe XDI4j's BDB implementation has good performance, but I haven't tested it or compared to other options. Markus On Fri, May 28, 2010 at 11:19 AM, Joseph Boyle <[email protected]>wrote: > I talked a little more about the backend question with Mike today. > > For 4. the only XDI native store I know of is Markus's. It has a context > provider higgins.idas.cp.xdi but Mike was not sure if this was finished and > working. From the XDI folks perspective, of course using an XDI store would > be ideal. Markus, do you think it is ready? > > For 3. (or 2.) writing a context provider could be a joint effort among > Azigo, the 3rd party DB vendor, and others like me. On the other hand, to do > performance testing of Higgins with a new DB, there should be a benchmark or > stress testing app, and Azigo would be best placed to specify and write the > benchmark, which I'm guessing would not be hard. > > Mike said that we would not expect performance problems for another year or > so when bigger deployments are expected. Putting a small amount of work into > evaluating databases now might save much more pain later. Perhaps this could > even be presented as a distinct project - for example I heard Marc Davis > asking if there has been performance testing. The DB vendors might be > persuaded to help with the integration work, and then would have the next > year to work on any performance problems themselves. Mike said that our > current challenge right now is defining API to support adding metadata to > sub-contexts, not performance, so having someone else do performance work > would be an advantage. > > I asked Mike what features we should specify as necessary or desirable in a > graph database. He suggested we need to be able to attach arbitrary > attributes to sub-contexts (subset of attributes from a context) but that I > post to the list as Paul, Sergey and Vitaliy could respond. > > Some of the graph databases offer features like multiple traversal that may > be higher level than can be expressed by the Context Provider API. If we > want to make use of any of these features, of course the sooner we know > about them, the better. Also some of the graph databases claim to provide > distributed storage and to try to optimize access across that distributed > storage; this could also be very useful for large scale deployment, but > needs to be tested in practice. > > > On May 27, 2010, at 7:17 AM, Paul Trevithick wrote: > > > Thanks for the pointers Joe. > > > > On May 26, 2010, at 8:37 PM, Joseph Boyle wrote: > > > >> I continue to hear of more graph databases - just saw > http://www.infinitegraph.com/ today. I also know of > http://www.kobrix.com/hgdb.jsp and > http://www.dekorte.com/projects/opensource/vertexdb/ . > >> > >> There's also a list at http://en.wikipedia.org/wiki/Graph_database > >> > >> On May 25, 2010, at 4:02 PM, Paul Trevithick wrote: > >> > >>> Options: > >>> 1. Get on the NG4Jena mailing list and ask for advice [We should do > this no matter what] > >>> 2. See if there are alternative open source quad stores with better > performance/scalability > >>> 3. Explore non-relational open source graph data bases (e.g. > Infogrid, Neo4j, etc.) > >>> 4. Use an XDI native store > >> > >> _______________________________________________ > >> higgins-dev mailing list > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/higgins-dev > > > > _______________________________________________ > > higgins-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
