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 <[email protected]> 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
>>
>
