You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Matthias Broecheler <me...@matthiasb.com> on 2016/01/26 02:26:36 UTC
Geo and Time
Hello everybody,
one of the great features of TinkerPop is that it is extensible. It is
pretty easy for an implementation of TinkerPop Gremlin to add support for a
regular expression predicate, for instance.
In addition, it is also possible to add custom data types based on the
pluggable serialization system. However, unlike a custom predicate, support
for custom data types requires changes both on the server side (i.e. within
a particular implementation) as well as on the client side so that clients
can read and make sense of such types when they are returned.
This makes it fairly impractical for implementations to support custom data
types. While it is easy to make the necessary changes on the server side, a
particular implementation would have to extend each and every driver of the
TinkerPop ecosystem in order to have its data type supported across the
board. The last part is what makes it impractical.
On top of that, since TinkerPop doesn't prescribe what the data type must
look like, implementations can differ in their approach making it
impossible for drivers to support them even if they invested the additional
effort.
Hence, I would like to make the case for including a "Geo" and a "Time"
data type. Both are very common in the database world, very well understood
(i.e. in how they should be represented and what they mean) and likely to
be supported by a non-trivial number of implementations.
If TinkerPop defines what these datatypes should look like, all drivers can
support them.
Note, that I am only advocating to declare the data types - not the
predicates or operations on the types. The latter part could be
controversial and should be left to implementations of TinkerPop. TinkerPop
should only dictate the structure of the datatype and how it is serialized
(both for gryo as well as graphson) to make communication possible.
For time, I suggest we follow the lead of Java's Instant which seems well
thought out:
https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
For geo, I suggest we initially focus on 2D spherical coordinate (latitude,
longitude) and the simple geometries of WKT which is widely supported in
the database world:
https://en.wikipedia.org/wiki/Well-known_text
WDYT?
Cheers,
Matthias
Re: Geo and Time
Posted by pieter-gmail <pi...@gmail.com>.
Hi,
I agree with you, however most dbs have more sophisticated support for
dates. Date, DateTime, Time and time zones.
I would say that TinkerPop might as well implement all the java.time
classes and let the features enable disable what a particular
implementation supports.
As an aside in Sqlg I implemented LocalDateTime, LocalDate, LocalTime,
ZonedDateTime, Duration and Period. Date times are so such a common
problem that having native support makes live way easier. No need for
conversions and custom magic for zones.
As it happens I did not implement Instant, admittedly for no good reason
other than that I have almost always only worked with the above
mentioned classes.
Neo4j only supports java primitives but OrientDB has support for
DateTime and zones and all the TinkerPop implementations via the RDF dbs
have support for Date, DateTime, Time and Zoned DateTimes as it is
specified in the spec.
Cheers
Pieter
On 26/01/2016 03:26, Matthias Broecheler wrote:
> Hello everybody,
>
> one of the great features of TinkerPop is that it is extensible. It is
> pretty easy for an implementation of TinkerPop Gremlin to add support for a
> regular expression predicate, for instance.
>
> In addition, it is also possible to add custom data types based on the
> pluggable serialization system. However, unlike a custom predicate, support
> for custom data types requires changes both on the server side (i.e. within
> a particular implementation) as well as on the client side so that clients
> can read and make sense of such types when they are returned.
>
> This makes it fairly impractical for implementations to support custom data
> types. While it is easy to make the necessary changes on the server side, a
> particular implementation would have to extend each and every driver of the
> TinkerPop ecosystem in order to have its data type supported across the
> board. The last part is what makes it impractical.
> On top of that, since TinkerPop doesn't prescribe what the data type must
> look like, implementations can differ in their approach making it
> impossible for drivers to support them even if they invested the additional
> effort.
>
> Hence, I would like to make the case for including a "Geo" and a "Time"
> data type. Both are very common in the database world, very well understood
> (i.e. in how they should be represented and what they mean) and likely to
> be supported by a non-trivial number of implementations.
> If TinkerPop defines what these datatypes should look like, all drivers can
> support them.
>
> Note, that I am only advocating to declare the data types - not the
> predicates or operations on the types. The latter part could be
> controversial and should be left to implementations of TinkerPop. TinkerPop
> should only dictate the structure of the datatype and how it is serialized
> (both for gryo as well as graphson) to make communication possible.
>
> For time, I suggest we follow the lead of Java's Instant which seems well
> thought out:
> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
> For geo, I suggest we initially focus on 2D spherical coordinate (latitude,
> longitude) and the simple geometries of WKT which is widely supported in
> the database world:
> https://en.wikipedia.org/wiki/Well-known_text
>
> WDYT?
> Cheers,
> Matthias
>
Re: Geo and Time
Posted by Ran Magen <rm...@gmail.com>.
It would probably be best to use some accepted standard for Geo instead of
reinventing one for TP.
This is the first thing that comes up on google: http://www.geoapi.org
On יום ד׳, 27 בינו׳ 2016 at 18:49 Stephen Mallette <sp...@gmail.com>
wrote:
> As of 3.1.1-incubating we will be able to serialize pretty much all of the
> java.time.* classes. Graphs won't have to provide any special serializers
> for those if they return those types.
>
> I'm less sure about how geo would work. TinkerPop creates interfaces for
> Point, Polygon, whatever, with appropriate serializers then if a graph
> wants to support geo, the provider could implement those interfaces in
> whatever way they chose to return as results. Providers could then also
> build their own predicates based on those types. is that what you're
> thinking matthias?
>
>
>
> On Tue, Jan 26, 2016 at 6:52 PM, Matthias Broecheler <me...@matthiasb.com>
> wrote:
>
> > Again, my comment is explicitly NOT about the predicates. Those are
> indeed
> > easy to add and implementors can differ in what they choose to provide
> and
> > how they implement those.
> >
> > I am only talking about providing a data type definition so that the
> server
> > and client can agree on how such data moves between the two. That's where
> > things are currently getting crazy.
> >
> > On Tue, Jan 26, 2016 at 11:51 AM Marko Rodriguez <ok...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I think Pieter echoes my sentiment about supporting Geo and Time in
> > > TinkerPop. A similar predicate people wanted in the past was RegEx. The
> > > problem, ElasticSearch RegEx is different from SQL is different from
> ??…
> > > I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a
> > crazy
> > > rat's nest of standards, competing Java APIs, and the like. I don''t
> > think
> > > TinkerPop should choose. Its really easy for graph system providers to
> > > provide P-predicates for predicates they wish to support (and what is
> > > specific to their database).
> > >
> > >
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java
> > >
> > >
> >
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182
> > >
> > > import static
> > > com.a.super.rich.company.that.hoards.cash.money.GeoP.*
> > > …
> > > g.V().has("location",
> > > inside(circle(12.234,34.235))).out("worksFor").values("name")
> > > g.V().has("location",
> > >
> >
> outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name")
> > >
> > >
> > > …again, I'm not the most knowledgeable here, but when I read Pieter's
> > > response, I was like -- "yea."
> > >
> > > Marko.
> > >
> > > http://markorodriguez.com
> > >
> > > On Jan 26, 2016, at 11:03 AM, pieter-gmail <pi...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Regarding Geo I have no strong opinions. However I thought I'll
> > indicate
> > > > what I have implemented in Sqlg.
> > > >
> > > > Postgres via Postgis has rather sophisticated gis support. In fact it
> > is
> > > > so sophisticated that I realized without spending considerable time
> > > > learning it I don't really know what all is involved. I did however
> add
> > > > partial support for the types that the postgis jdbc driver supports.
> > > > Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being
> on
> > a
> > > > flat earth and geography for a spherical earth. The driver has more
> > > > constructs that I do not yet support.
> > > >
> > > > Further I did not consider adding any gremlin gis support as the gis
> > > > concepts quickly become so complex that I deemed it better to leave
> > this
> > > > at the native sql level. Not sure what gremlin's gis ambitions are
> but
> > > > chances are that a single lowest common denominator Point field will
> > not
> > > > suffice.
> > > >
> > > > Cheers
> > > > Pieter
> > > >
> > > >
> > > > On 26/01/2016 03:26, Matthias Broecheler wrote:
> > > >> Hello everybody,
> > > >>
> > > >> one of the great features of TinkerPop is that it is extensible. It
> is
> > > >> pretty easy for an implementation of TinkerPop Gremlin to add
> support
> > > for a
> > > >> regular expression predicate, for instance.
> > > >>
> > > >> In addition, it is also possible to add custom data types based on
> the
> > > >> pluggable serialization system. However, unlike a custom predicate,
> > > support
> > > >> for custom data types requires changes both on the server side (i.e.
> > > within
> > > >> a particular implementation) as well as on the client side so that
> > > clients
> > > >> can read and make sense of such types when they are returned.
> > > >>
> > > >> This makes it fairly impractical for implementations to support
> custom
> > > data
> > > >> types. While it is easy to make the necessary changes on the server
> > > side, a
> > > >> particular implementation would have to extend each and every driver
> > of
> > > the
> > > >> TinkerPop ecosystem in order to have its data type supported across
> > the
> > > >> board. The last part is what makes it impractical.
> > > >> On top of that, since TinkerPop doesn't prescribe what the data type
> > > must
> > > >> look like, implementations can differ in their approach making it
> > > >> impossible for drivers to support them even if they invested the
> > > additional
> > > >> effort.
> > > >>
> > > >> Hence, I would like to make the case for including a "Geo" and a
> > "Time"
> > > >> data type. Both are very common in the database world, very well
> > > understood
> > > >> (i.e. in how they should be represented and what they mean) and
> likely
> > > to
> > > >> be supported by a non-trivial number of implementations.
> > > >> If TinkerPop defines what these datatypes should look like, all
> > drivers
> > > can
> > > >> support them.
> > > >>
> > > >> Note, that I am only advocating to declare the data types - not the
> > > >> predicates or operations on the types. The latter part could be
> > > >> controversial and should be left to implementations of TinkerPop.
> > > TinkerPop
> > > >> should only dictate the structure of the datatype and how it is
> > > serialized
> > > >> (both for gryo as well as graphson) to make communication possible.
> > > >>
> > > >> For time, I suggest we follow the lead of Java's Instant which seems
> > > well
> > > >> thought out:
> > > >> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
> > > >> For geo, I suggest we initially focus on 2D spherical coordinate
> > > (latitude,
> > > >> longitude) and the simple geometries of WKT which is widely
> supported
> > in
> > > >> the database world:
> > > >> https://en.wikipedia.org/wiki/Well-known_text
> > > >>
> > > >> WDYT?
> > > >> Cheers,
> > > >> Matthias
> > > >>
> > > >
> > >
> > >
> >
>
Re: Geo and Time
Posted by Stephen Mallette <sp...@gmail.com>.
As of 3.1.1-incubating we will be able to serialize pretty much all of the
java.time.* classes. Graphs won't have to provide any special serializers
for those if they return those types.
I'm less sure about how geo would work. TinkerPop creates interfaces for
Point, Polygon, whatever, with appropriate serializers then if a graph
wants to support geo, the provider could implement those interfaces in
whatever way they chose to return as results. Providers could then also
build their own predicates based on those types. is that what you're
thinking matthias?
On Tue, Jan 26, 2016 at 6:52 PM, Matthias Broecheler <me...@matthiasb.com>
wrote:
> Again, my comment is explicitly NOT about the predicates. Those are indeed
> easy to add and implementors can differ in what they choose to provide and
> how they implement those.
>
> I am only talking about providing a data type definition so that the server
> and client can agree on how such data moves between the two. That's where
> things are currently getting crazy.
>
> On Tue, Jan 26, 2016 at 11:51 AM Marko Rodriguez <ok...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I think Pieter echoes my sentiment about supporting Geo and Time in
> > TinkerPop. A similar predicate people wanted in the past was RegEx. The
> > problem, ElasticSearch RegEx is different from SQL is different from ??…
> > I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a
> crazy
> > rat's nest of standards, competing Java APIs, and the like. I don''t
> think
> > TinkerPop should choose. Its really easy for graph system providers to
> > provide P-predicates for predicates they wish to support (and what is
> > specific to their database).
> >
> >
> >
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java
> >
> >
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182
> >
> > import static
> > com.a.super.rich.company.that.hoards.cash.money.GeoP.*
> > …
> > g.V().has("location",
> > inside(circle(12.234,34.235))).out("worksFor").values("name")
> > g.V().has("location",
> >
> outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name")
> >
> >
> > …again, I'm not the most knowledgeable here, but when I read Pieter's
> > response, I was like -- "yea."
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> > On Jan 26, 2016, at 11:03 AM, pieter-gmail <pi...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Regarding Geo I have no strong opinions. However I thought I'll
> indicate
> > > what I have implemented in Sqlg.
> > >
> > > Postgres via Postgis has rather sophisticated gis support. In fact it
> is
> > > so sophisticated that I realized without spending considerable time
> > > learning it I don't really know what all is involved. I did however add
> > > partial support for the types that the postgis jdbc driver supports.
> > > Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being on
> a
> > > flat earth and geography for a spherical earth. The driver has more
> > > constructs that I do not yet support.
> > >
> > > Further I did not consider adding any gremlin gis support as the gis
> > > concepts quickly become so complex that I deemed it better to leave
> this
> > > at the native sql level. Not sure what gremlin's gis ambitions are but
> > > chances are that a single lowest common denominator Point field will
> not
> > > suffice.
> > >
> > > Cheers
> > > Pieter
> > >
> > >
> > > On 26/01/2016 03:26, Matthias Broecheler wrote:
> > >> Hello everybody,
> > >>
> > >> one of the great features of TinkerPop is that it is extensible. It is
> > >> pretty easy for an implementation of TinkerPop Gremlin to add support
> > for a
> > >> regular expression predicate, for instance.
> > >>
> > >> In addition, it is also possible to add custom data types based on the
> > >> pluggable serialization system. However, unlike a custom predicate,
> > support
> > >> for custom data types requires changes both on the server side (i.e.
> > within
> > >> a particular implementation) as well as on the client side so that
> > clients
> > >> can read and make sense of such types when they are returned.
> > >>
> > >> This makes it fairly impractical for implementations to support custom
> > data
> > >> types. While it is easy to make the necessary changes on the server
> > side, a
> > >> particular implementation would have to extend each and every driver
> of
> > the
> > >> TinkerPop ecosystem in order to have its data type supported across
> the
> > >> board. The last part is what makes it impractical.
> > >> On top of that, since TinkerPop doesn't prescribe what the data type
> > must
> > >> look like, implementations can differ in their approach making it
> > >> impossible for drivers to support them even if they invested the
> > additional
> > >> effort.
> > >>
> > >> Hence, I would like to make the case for including a "Geo" and a
> "Time"
> > >> data type. Both are very common in the database world, very well
> > understood
> > >> (i.e. in how they should be represented and what they mean) and likely
> > to
> > >> be supported by a non-trivial number of implementations.
> > >> If TinkerPop defines what these datatypes should look like, all
> drivers
> > can
> > >> support them.
> > >>
> > >> Note, that I am only advocating to declare the data types - not the
> > >> predicates or operations on the types. The latter part could be
> > >> controversial and should be left to implementations of TinkerPop.
> > TinkerPop
> > >> should only dictate the structure of the datatype and how it is
> > serialized
> > >> (both for gryo as well as graphson) to make communication possible.
> > >>
> > >> For time, I suggest we follow the lead of Java's Instant which seems
> > well
> > >> thought out:
> > >> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
> > >> For geo, I suggest we initially focus on 2D spherical coordinate
> > (latitude,
> > >> longitude) and the simple geometries of WKT which is widely supported
> in
> > >> the database world:
> > >> https://en.wikipedia.org/wiki/Well-known_text
> > >>
> > >> WDYT?
> > >> Cheers,
> > >> Matthias
> > >>
> > >
> >
> >
>
Re: Geo and Time
Posted by Matthias Broecheler <me...@matthiasb.com>.
Again, my comment is explicitly NOT about the predicates. Those are indeed
easy to add and implementors can differ in what they choose to provide and
how they implement those.
I am only talking about providing a data type definition so that the server
and client can agree on how such data moves between the two. That's where
things are currently getting crazy.
On Tue, Jan 26, 2016 at 11:51 AM Marko Rodriguez <ok...@gmail.com>
wrote:
> Hi,
>
> I think Pieter echoes my sentiment about supporting Geo and Time in
> TinkerPop. A similar predicate people wanted in the past was RegEx. The
> problem, ElasticSearch RegEx is different from SQL is different from ??…
> I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a crazy
> rat's nest of standards, competing Java APIs, and the like. I don''t think
> TinkerPop should choose. Its really easy for graph system providers to
> provide P-predicates for predicates they wish to support (and what is
> specific to their database).
>
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java
>
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182
>
> import static
> com.a.super.rich.company.that.hoards.cash.money.GeoP.*
> …
> g.V().has("location",
> inside(circle(12.234,34.235))).out("worksFor").values("name")
> g.V().has("location",
> outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name")
>
>
> …again, I'm not the most knowledgeable here, but when I read Pieter's
> response, I was like -- "yea."
>
> Marko.
>
> http://markorodriguez.com
>
> On Jan 26, 2016, at 11:03 AM, pieter-gmail <pi...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Regarding Geo I have no strong opinions. However I thought I'll indicate
> > what I have implemented in Sqlg.
> >
> > Postgres via Postgis has rather sophisticated gis support. In fact it is
> > so sophisticated that I realized without spending considerable time
> > learning it I don't really know what all is involved. I did however add
> > partial support for the types that the postgis jdbc driver supports.
> > Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being on a
> > flat earth and geography for a spherical earth. The driver has more
> > constructs that I do not yet support.
> >
> > Further I did not consider adding any gremlin gis support as the gis
> > concepts quickly become so complex that I deemed it better to leave this
> > at the native sql level. Not sure what gremlin's gis ambitions are but
> > chances are that a single lowest common denominator Point field will not
> > suffice.
> >
> > Cheers
> > Pieter
> >
> >
> > On 26/01/2016 03:26, Matthias Broecheler wrote:
> >> Hello everybody,
> >>
> >> one of the great features of TinkerPop is that it is extensible. It is
> >> pretty easy for an implementation of TinkerPop Gremlin to add support
> for a
> >> regular expression predicate, for instance.
> >>
> >> In addition, it is also possible to add custom data types based on the
> >> pluggable serialization system. However, unlike a custom predicate,
> support
> >> for custom data types requires changes both on the server side (i.e.
> within
> >> a particular implementation) as well as on the client side so that
> clients
> >> can read and make sense of such types when they are returned.
> >>
> >> This makes it fairly impractical for implementations to support custom
> data
> >> types. While it is easy to make the necessary changes on the server
> side, a
> >> particular implementation would have to extend each and every driver of
> the
> >> TinkerPop ecosystem in order to have its data type supported across the
> >> board. The last part is what makes it impractical.
> >> On top of that, since TinkerPop doesn't prescribe what the data type
> must
> >> look like, implementations can differ in their approach making it
> >> impossible for drivers to support them even if they invested the
> additional
> >> effort.
> >>
> >> Hence, I would like to make the case for including a "Geo" and a "Time"
> >> data type. Both are very common in the database world, very well
> understood
> >> (i.e. in how they should be represented and what they mean) and likely
> to
> >> be supported by a non-trivial number of implementations.
> >> If TinkerPop defines what these datatypes should look like, all drivers
> can
> >> support them.
> >>
> >> Note, that I am only advocating to declare the data types - not the
> >> predicates or operations on the types. The latter part could be
> >> controversial and should be left to implementations of TinkerPop.
> TinkerPop
> >> should only dictate the structure of the datatype and how it is
> serialized
> >> (both for gryo as well as graphson) to make communication possible.
> >>
> >> For time, I suggest we follow the lead of Java's Instant which seems
> well
> >> thought out:
> >> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
> >> For geo, I suggest we initially focus on 2D spherical coordinate
> (latitude,
> >> longitude) and the simple geometries of WKT which is widely supported in
> >> the database world:
> >> https://en.wikipedia.org/wiki/Well-known_text
> >>
> >> WDYT?
> >> Cheers,
> >> Matthias
> >>
> >
>
>
Re: Geo and Time
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
I think Pieter echoes my sentiment about supporting Geo and Time in TinkerPop. A similar predicate people wanted in the past was RegEx. The problem, ElasticSearch RegEx is different from SQL is different from ??… I'm not hip to the Geo- and Time-scene, but I suspect that Geo is a crazy rat's nest of standards, competing Java APIs, and the like. I don''t think TinkerPop should choose. Its really easy for graph system providers to provide P-predicates for predicates they wish to support (and what is specific to their database).
https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java
https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/P.java#L122-L182
import static com.a.super.rich.company.that.hoards.cash.money.GeoP.*
…
g.V().has("location", inside(circle(12.234,34.235))).out("worksFor").values("name")
g.V().has("location", outside(rectangle(12.234,34.235,23,11.57))).out("collaboratesWith").values("name")
…again, I'm not the most knowledgeable here, but when I read Pieter's response, I was like -- "yea."
Marko.
http://markorodriguez.com
On Jan 26, 2016, at 11:03 AM, pieter-gmail <pi...@gmail.com> wrote:
> Hi,
>
> Regarding Geo I have no strong opinions. However I thought I'll indicate
> what I have implemented in Sqlg.
>
> Postgres via Postgis has rather sophisticated gis support. In fact it is
> so sophisticated that I realized without spending considerable time
> learning it I don't really know what all is involved. I did however add
> partial support for the types that the postgis jdbc driver supports.
> Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being on a
> flat earth and geography for a spherical earth. The driver has more
> constructs that I do not yet support.
>
> Further I did not consider adding any gremlin gis support as the gis
> concepts quickly become so complex that I deemed it better to leave this
> at the native sql level. Not sure what gremlin's gis ambitions are but
> chances are that a single lowest common denominator Point field will not
> suffice.
>
> Cheers
> Pieter
>
>
> On 26/01/2016 03:26, Matthias Broecheler wrote:
>> Hello everybody,
>>
>> one of the great features of TinkerPop is that it is extensible. It is
>> pretty easy for an implementation of TinkerPop Gremlin to add support for a
>> regular expression predicate, for instance.
>>
>> In addition, it is also possible to add custom data types based on the
>> pluggable serialization system. However, unlike a custom predicate, support
>> for custom data types requires changes both on the server side (i.e. within
>> a particular implementation) as well as on the client side so that clients
>> can read and make sense of such types when they are returned.
>>
>> This makes it fairly impractical for implementations to support custom data
>> types. While it is easy to make the necessary changes on the server side, a
>> particular implementation would have to extend each and every driver of the
>> TinkerPop ecosystem in order to have its data type supported across the
>> board. The last part is what makes it impractical.
>> On top of that, since TinkerPop doesn't prescribe what the data type must
>> look like, implementations can differ in their approach making it
>> impossible for drivers to support them even if they invested the additional
>> effort.
>>
>> Hence, I would like to make the case for including a "Geo" and a "Time"
>> data type. Both are very common in the database world, very well understood
>> (i.e. in how they should be represented and what they mean) and likely to
>> be supported by a non-trivial number of implementations.
>> If TinkerPop defines what these datatypes should look like, all drivers can
>> support them.
>>
>> Note, that I am only advocating to declare the data types - not the
>> predicates or operations on the types. The latter part could be
>> controversial and should be left to implementations of TinkerPop. TinkerPop
>> should only dictate the structure of the datatype and how it is serialized
>> (both for gryo as well as graphson) to make communication possible.
>>
>> For time, I suggest we follow the lead of Java's Instant which seems well
>> thought out:
>> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
>> For geo, I suggest we initially focus on 2D spherical coordinate (latitude,
>> longitude) and the simple geometries of WKT which is widely supported in
>> the database world:
>> https://en.wikipedia.org/wiki/Well-known_text
>>
>> WDYT?
>> Cheers,
>> Matthias
>>
>
Re: Geo and Time
Posted by pieter-gmail <pi...@gmail.com>.
Hi,
Regarding Geo I have no strong opinions. However I thought I'll indicate
what I have implemented in Sqlg.
Postgres via Postgis has rather sophisticated gis support. In fact it is
so sophisticated that I realized without spending considerable time
learning it I don't really know what all is involved. I did however add
partial support for the types that the postgis jdbc driver supports.
Point, Polygon, GeographyPoint and GeographyPolygon. Geometry being on a
flat earth and geography for a spherical earth. The driver has more
constructs that I do not yet support.
Further I did not consider adding any gremlin gis support as the gis
concepts quickly become so complex that I deemed it better to leave this
at the native sql level. Not sure what gremlin's gis ambitions are but
chances are that a single lowest common denominator Point field will not
suffice.
Cheers
Pieter
On 26/01/2016 03:26, Matthias Broecheler wrote:
> Hello everybody,
>
> one of the great features of TinkerPop is that it is extensible. It is
> pretty easy for an implementation of TinkerPop Gremlin to add support for a
> regular expression predicate, for instance.
>
> In addition, it is also possible to add custom data types based on the
> pluggable serialization system. However, unlike a custom predicate, support
> for custom data types requires changes both on the server side (i.e. within
> a particular implementation) as well as on the client side so that clients
> can read and make sense of such types when they are returned.
>
> This makes it fairly impractical for implementations to support custom data
> types. While it is easy to make the necessary changes on the server side, a
> particular implementation would have to extend each and every driver of the
> TinkerPop ecosystem in order to have its data type supported across the
> board. The last part is what makes it impractical.
> On top of that, since TinkerPop doesn't prescribe what the data type must
> look like, implementations can differ in their approach making it
> impossible for drivers to support them even if they invested the additional
> effort.
>
> Hence, I would like to make the case for including a "Geo" and a "Time"
> data type. Both are very common in the database world, very well understood
> (i.e. in how they should be represented and what they mean) and likely to
> be supported by a non-trivial number of implementations.
> If TinkerPop defines what these datatypes should look like, all drivers can
> support them.
>
> Note, that I am only advocating to declare the data types - not the
> predicates or operations on the types. The latter part could be
> controversial and should be left to implementations of TinkerPop. TinkerPop
> should only dictate the structure of the datatype and how it is serialized
> (both for gryo as well as graphson) to make communication possible.
>
> For time, I suggest we follow the lead of Java's Instant which seems well
> thought out:
> https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
> For geo, I suggest we initially focus on 2D spherical coordinate (latitude,
> longitude) and the simple geometries of WKT which is widely supported in
> the database world:
> https://en.wikipedia.org/wiki/Well-known_text
>
> WDYT?
> Cheers,
> Matthias
>