Scarph

[alberskib]

@bio4j/dynamograph I have some questions regarding scarph. Answers for those questions enables me understanding it, so please be patient in case of any stupid questions.

• On scarph code I can see that there are defined some functional objects (link) i.e.

/* Get source/target from this representation */
  abstract class GetSource[S <: AnyVertex.ofType[Tpe#SourceType]](val source: S) {
    def apply(edgeRep: edge.Rep): source.Rep
  }
  abstract class GetTarget[T <: AnyVertex.ofType[Tpe#TargetType]](val target: T) {
    def apply(edgeRep: edge.Rep): target.Rep
  }

and they are used later as an implicits. Is there any special reason why their are created instead of functions? I mean why to use functional objects instead of functions.

• What is the reason for denotation trait existance. I mean why it is important from data model perspective? (I know that it is strange question)

[alberskib]

There is one more thing:

• actually there is no any package for scarph in repository (even SNAPSHOT)

[laughedelic]

I'll try to answer, but I may be wrong on imprecise in something (so maybe @eparejatobes will add something). And don't worry if you don't understand some code — it's really non-trivial, so it's normal to ask questions.

About your first question: as you see in the following part of code (in the same file that you refer), we add such methods to edge.Rep:

def source[S <: Singleton with AnyVertex.ofType[Tpe#SourceType]](implicit getter: GetSource[S]) = getter(edgeRep)

so we want those GetSource things to be implicit objects. The point is that it gives us flexibility, because these part of implementation are detached from each other:

• for example in the titan implementation you can define universal getters
• or in another test, this getter is defined for some other implementation

and it can be defined there, or in any other place. The only requirement is that it should be in scope when you want to use it.

Same applies to retrieving properties and ingoing/outgoing edges for a vertex. For an example of external creation of a target getter see this test.

P.S. I've just published it (0.1.0-SNAPSHOT)

[alberskib]

so we want those GetSource things to be implicit objects

As far as I know you can also create an implicit function which will work similarly

implicit def sourceType2sourceRep( ...

[laughedelic]

Could you extend this piece of code? So far I don't see what you mean.

[laughedelic]

About denotation thing.

I mean why it is important

Well, it's just a generalization which appeared while we were refactoring the code.

First, as it's said in the comments:

This trait represents a mapping between

• members Tpe of a universe of types TYPE

• and Raw a type meant to be a denotation of Tpe thus the name

  Tagging is used for being able to operate on Raw values knowing what they are denotating.

(by the way, the actual comment mixes Rep and Raw (Rep is just a tagged Raw)).

So for example:

• on the abstract level we say that a vertex denotes some vertex type:

  trait AnyVertex extends Denotation[AnyVertexType] ...

  this binds the TYPE type member (think of it just as a type bound for Tpe, which will be a particular vertex type)

• on the implementation level, we say

  trait AnyTVertex extends AnyVertex { ...
  
  type Raw = com.thinkaurelius.titan.core.TitanVertex
  
  ...

  so it binds the Raw type member, meaning, that we want to represent vertices by the TitanVertex type.

• then in the gods graph test we have
  • first a vertex type definition: case object Titan extends VertexType("titan") (in godsSchema)
  • then "an instance" of it: case object titan extends TVertex(Titan) (in godsImplementation) (I'm not sure which terminology to use here)

So with all these layers you can see, that with vertex types we can define the graph schema abstractly (godSchema), and then "implement" it (godsImplementation), defining vertices which denote those vertex types with a particular implementation (Raw = TitanVertex).

The reason why we want to have this "double" types structure, is that we want to deal with a universe of types (i.e. a defined limited set of them), and operate on them as on values, which would be impossible otherwise.

P.S. I hope I understood your questions right. If not, ask again. And I hope @eparejatobes will say something too ")

[eparejatobes]

I have intermittent access to internet, anyway I'll try to answer briefly

• In Scala you need objects for encoding dependently typed functions
• denotation is something like poor man's universes in Scala. Raw is the type you use for denoting tpe, and Rep is just a way of encoding at the type level that Raw is denoting tpe.

[alberskib]

So with all these layers you can see, that with vertex types we can define the graph schema abstractly (godSchema), and then "implement" it (godsImplementation), defining vertices which denote those vertex types with a particular implementation (Raw = TitanVertex).

The reason why we want to have this "double" types structure, is that we want to deal with a universe of types (i.e. a defined limited set of them), and operate on them as on values, which would be impossible otherwise.

Thanks a lot. I think that more or less I understand it - now it is easier for me to use it (but still it is good idea to discuss about it).

[laughedelic]

I'm glad that it helps. In general, I recommend you to start from examples in tests to see how things are used and from there look up how those things are defined.

[eparejatobes]

@bio4j/dynamograph i could prepare a walkthrough for the library, explaining what were my ideas/motivations for it. Tomorrow or the day after? I have a lot of meetings and stuff these days but early morning (7:00AM) US EST is fine for me. Moving this to

[laughedelic]

ok. fine for me

[alberskib]

Unfortunately I cannot take part at suggested time tommorow or day after (11AM - 5PM US EST is ok). Alternatively wednesday at 7:00 AM US EST is ok for me.

[eparejatobes]

@bio4j/dynamograph closing?