bio4j / angulillos

Java 8 library for strongly typed graph data

Angulillos<?>

Angulillos is a Java 8 library for strongly typed graph data.

You write graph schemas using the Java type system, and graph traversals are statically checked. The same schemas and traversals can then be used with any implementation of the Angulillos API, such as bio4j/angulillos-titan.

Why not TinkerPop?

Angulillos fixes the untypedness of TinkerPop at two different levels that we could call structural and model-specific:

• Structural You can write nonsensical traversals like "source of a vertex"
• Model No notion of graph schema. You can write "give me users followed by tweet"

Where to start

The tests include a simple Twitter graph schema and some generic traversals:

• TwitterGraph
• TwitterGraphTestSuite

For something more complex take a look at bio4j/bio4j, which includes several interconnected graph schemas with hundreds of types.

angulillos's Issues

Restructure methods for adjacent edges/vertices

I have rough an idea on how to improve all these inOneE, inOptionalE, inManyE, etc. For that we'll need to make arities useful:

• split arity on two: in-arity and out-arity (there already are separate traits for this)
• add representation type to arity (E, Optional<E>, Stream<E>)
• put those arity specific in/out methods to the arity traits
• call them from the typed graph/vertex interfaces

Something like

    sealed trait Arity { 

      type C[E]
      def narrow(edges: Stream[E]): C[E]
    }

    trait ExactlyOne extends Arity { type C[E] = E; ... }
    trait AtMostOne  extends Arity { type C[E] = Option[E]; ... }
    trait ManyOrNone extends Arity { type C[E] = Stream[E]; ... }


    trait InArity extends Arity
    trait OutArity extends Arity

    trait FromExactlyOne extends InArity with ExactlyOne
    trait FromAtMostOne  extends InArity with AtMostOne
    trait FromManyOrNone extends InArity with ManyOrNone

    trait ToExactlyOne extends OutArity with ExactlyOne
    trait ToAtMostOne  extends OutArity with AtMostOne
    trait ToManyOrNone extends OutArity with ManyOrNone

then in the TypedVertex:

  default <
    // src
    S extends TypedVertex<S,ST,SG,I,RV,RE>,
    ST extends TypedVertex.Type<S,ST,SG,I,RV,RE>,
    SG extends TypedGraph<SG,I,RV,RE>,
    // rel
    R extends TypedEdge<S,ST,SG, R,RT,RTA, RG,I,RV,RE, N,NT,G>,
    RT extends TypedEdge.Type<S,ST,SG, R,RT,RTA, RG,I,RV,RE, N,NT,G>,
    RTA extends TypedEdge.Type.Arity<...>,       // some magic here, please???
    RG extends TypedGraph<RG,I,RV,RE>
  >
  RTA<E> inE(RT relType) { return relType.arity.narrow(graph().inE(relType, self()); }

@eparejatobes WDYT?
Sorry for using scala here, but I think you got the idea. Do you think it's doable in Java?

Consider supporting OrderBy, Limit

add full support for Titan indexes

See

• https://github.com/thinkaurelius/titan/wiki/Indexing-Backend-Overview
• https://github.com/thinkaurelius/titan/wiki/Type-Definition-Overview

Deprecate AtLeastOne arity

There are only three types of outE/inE methods, they return

• E for arity One
• Optional<E> for arity AtMostOne
• Stream<E> for arity Any (Many)

As there is no NonEmptyStream<> in Java, let's deprecate the AtLeastOne arity.

Problem with Index stuff in TypedGraphs

I just ran into this:

SEVERE: Exception retrieving protein P0DM41
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: null
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.ohnosequences.typedGraphs.titan.TitanTypedVertexIndex$Default.query(TitanTypedVertexIndex.java:67)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.ohnosequences.typedGraphs.TypedElementIndex$Unique.getElement(TypedElementIndex.java:38)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.ohnosequences.typedGraphs.TypedVertexIndex$Unique.getVertex(TypedVertexIndex.java:41)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.bio4j.model.uniprot.programs.ImportUniprot.importUniprot(ImportUniprot.java:337)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.bio4j.titan.model.uniprot.programs.ImportUniprotTitan.execute(ImportUniprotTitan.java:56)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.ohnosequences.util.ExecuteFromFile.main(ExecuteFromFile.java:66)
Sep 04, 2014 10:38:32 AM com.bio4j.model.uniprot.programs.ImportUniprot importUniprot
SEVERE: com.bio4j.titan.programs.ImportTitanDB.main(ImportTitanDB.java:11)

It seems to be some internal null value exception thrown in TitanTypedVertexIndex class.
@eparejatobes Any ideas why?

Bio4j induced requirements

@pablopareja I did some general clean up and implemented some extra stuff for Titan; all this is in 0.2.0-SNAPSHOT. Please use this issue for feature requests that you surely will be identifying as the work in bio4j/bio4j-titan#14 progresses. The idea is that you shouldn't need to use anything from the raw Titan API.

OrientDB implementation

are access modifiers for raw too wide?

test with sample data for Titan

What I started for GO could work

Titan 0.5 implementation

add support for vertex-centric indexes

Advanced schema graph

Not only creating types/labels in the DB, but also creating a real graph, i.e. connecting DB-specific edge-type presentation with its source/target types with an edge, etc. So that you can query the DB for the schema structure.

In TitanDB this is straightforward, because EdgeLabel implements TitanVertex. This needs some investigation for other possible backends.

Problem when using last version published

Now the following piece of code:

TitanNode.Type

gives the following error:

Error:(55, 34) java: com.ohnosequences.typedGraphs.titan.TitanNode.Type is not public in com.ohnosequences.typedGraphs.titan.TitanNode; cannot be accessed from outside package

Is that normal?

how to specify graphs with dependencies

In the spirit of what is done in Bio4j

method names and arguments order for in/out

Better names for arities

Most of this is being discussed in #40

outOneV method missing in TypedVertex

Also outOne() method seems to have some problem...

IMPORTANT - moving to Bio4j, renaming

Hey @ohnosequences/coders I want to move this to the bio4j org; it makes much more sense there, and we could attract contributors much more easily. The other thing is the name: typed-graphs is just awful. Suggestions?

experiment with typed Tinkerpop3 traversals

examples - several graphs with deps

add default key creation for normal properties

Typed vertex queries

Add support.

---

old

At the moment it's just lying there, without any connection with the rest of the things.

Consider adding locks to Transaction

Neo4j has entity-level locks in the scope of a transaction, which is a really useful feature. I think we could safely add this to the Transaction interface here, throwing UnsupportedOperation if missing from an implementation.

generic Blueprints implementation

Probably would be pretty similar to the Titan one

Split interfaces on read/write-only

I would split typed and untyped graph interfaces on parts with

• writing methods (addVertex/addEdge, setProperty, commit)
• reading methods (the rest)
• and probably indexes-related stuff

In the writing part we can add general methods for schema initialization. Then it's used for importing data.

The reading part is used for working with an instance of already imported data.

@eparejatobes WDYT?