New Cayley As Library Example w/ homebrew quad Metadata


Hi Cayley folks,

I put together a sample application using Cayley as an embedded library. It’s up on github at Github - Gasket . I’ve seen a few more straight-forward sample applications using Cayley as a library, but perhaps it will help some go-newbies to see a more complete project using cayley as a library.

The application itself is a restful API which accepts JSON objects in the form of

"node": {
    "properties": {
        "id": {"type":"string"},
    "patternProperties": {
            "^(/[^/]+)+$": { "type": "object" }
         * Accept any property without a '/' character

and converts them into rdf quads.

The API will also save metadata about quads using a similar JSON format. There’s more information about this in the README on github.

If you have the time to check it out, I’d love any feedback you have.


Hi @gkontos!

You might be interested in reification branch. It will support quad metadata natively. And schema lib may help loading/saving complex objects from/into Cayley, but it’s less flexible then using raw iterators, of course.

But as for now (with current stable release in mind) library looks really good - it uses low-level Cayley operations which are most optimal and has less overhead possible. Only one technical suggestion comes to my mind - most complex iterators are not optimized, like And(QuadDirectionA, QuadDirectionB). Depending on QS implementation, some will be able to flatten this iterator into a single iterator. Thus, it makes sense to call qs.OptimizeIterator before running it. You may find an optimization step slow, but it will get better. You will be able to “prepare” iterator trees for a specific QS and then build optimized version with different arguments fast.


Very cool. Thank you for the feedback. I went ahead and added optimization to the iterators.

The schema lib looks like it has an identical goal to what I was shooting for. I like the annotation approach and establishing the structs from within the API. My approach pushes more of the responsibility of defining and validating objects onto the frontend.

The reification branch looks a bit mysterious to me. I see a Primitive type that appears new. It appears that the primitive is handling multiple versions of a quad? Also, I poked through the new bolt2 quadstore. Honestly, around that point things get fuzzy for me :). It appears that bolt2 is using an identifier for each node of the quad. And getting a Primitive (and the quad) based on that identifier. But, I don’t see how I could get the identifier directly, or set metadata for the quad.


It does not store a version of the quad. Primitive is an object that can be a node or a quad (or both). In bolt2 identifiers for quad are similar to identifiers for nodes. Thus, you can get an ID for quad and use it as a subject in another quad to add metadata. But this functionality is not exposed yet.


Thank you for the clarification. I suppose I saw the Replaces field on the Primitive struct and started making assumptions.