You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by pieter <pi...@gmail.com> on 2015/08/11 21:35:33 UTC
RE: text search
Hi,
Going through the gremlin Predicates I do not see one that is for doing
full text searches.
Have I missed it or is omitted on purpose?
Having both case sensitive and non case-sensitive searches is a common
requirement.
Thanks
Pieter
Re: text search
Posted by Matt Frantz <ma...@gmail.com>.
I also like that Rob's proposed extensions API translates well across a
client-server barrier, whereas my proposal references specific Java classes
directly. We could go the URI route or the Java package name route, since
both have widely accepted conventions for partitioning the global namespace.
On Thu, Aug 20, 2015 at 1:43 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
> You could do something akin to the SPARQL approach
>
> You specify some limited subset of known functions with well defined
> semantics e.g. contains(), startsWith() etc that are implemented in the
> core language and then define a mechanism via which extension functions
> may be referenced
>
> e.g.
>
> g.V().has('name', Functions.contains('monkey'))
>
> And
>
> g.V().has('name', Functions.extension('http://acme/textSearch', 'monkey'))
>
> The idea being that extension takes the name of the function and then zero
> or more arguments which are interpreted by the specific vendor
> implementation of that extension function
>
> In SPARQL those are named via URIs and each implementation can choose what
> extension function(s) they add to their core implementation, in principal
> at least having a global namespace allows for common useful extension
> functions to be defined by one vendor and adopted by other vendors over
> time. For Gremlim you may want to use some other naming scheme though
> URIs have the advantage that you can take advantage of common conventions
> around domain and thus namespace ownership
>
> Rob
>
> On 20/08/2015 12:36, "Matt Frantz" <ma...@gmail.com> wrote:
>
> >I agree that there is a set of operations on scalar types that should be
> >supported efficiently (i.e. by pushing them down). It would be nice if we
> >could figure out a way to exploit vendor-specific features in some
> >extensible portion of the API. Otherwise, we're just aiming at least
> >common denominator capabilities.
> >
> >Many operations have standard definitions, but something like regular
> >expressions can have variants, so we must be clear about how we would
> >define conforming implementations.
> >
> >Suppose vendor Acme has an exclusive text searching capability that
> >includes case folding, stemming, synonym matching, spelling correction,
> >camel-case splittings, etc. Could there be an API like "P" that could be
> >provided by the vendor, so that Gremlin expressions would reference it?
> >Otherwise, we end up either maintaining a universal catalog of vendor
> >capabilities or fuzzy matching the vendor capabilities to a universal
> >list,
> >which leads to vendor-specific application behavior. We could then
> >migrate
> >capabilities into the core as they become more widespread.
> >
> >g.V().has('name', AcmeP.exclusiveTextSearch('monkey'));
> >
> >As an application writer, I want to know when I can expect vendor-specific
> >behavior, and this sort of API design would remind me of such choices.
> >
> >
> >On Thu, Aug 20, 2015 at 11:17 AM, pieter <pi...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I view Gremlin as a first class query language. As such it is more
> >> concerned with what than how.
> >>
> >> I reckon
> >>
> >> String.contains
> >> String.startsWith
> >> String.endsWith
> >> and some form of regular expression
> >>
> >> is so common it would be expected for any query language.
> >>
> >> A quick check on neo4j cypher and orientdb sql both support the above.
> >> Cypher also has a case sensitive toggle/expression. Not sure about
> >> Orientdb, probably a 'upper() + like %'
> >>
> >> The above predicates have no need for an index. If an index can be used
> >> all the better but either way it should work.
> >>
> >> Thanks
> >> Pieter
> >>
> >>
> >> On 17/08/2015 16:10, Daniel Kuppitz wrote:
> >>
> >>> See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo'
> >>>Face
> >>>
> >>><https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ
> >
> >>>
> >>> On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <me...@gremlin.guru>
> >>>wrote:
> >>>
> >>> Because every vendor handles text comparisons differently. Some allow
> >>>> regular expressions, others don't. Some vendors do case-sensitive
> >>>> matches,
> >>>> others case-insensitive, etc.
> >>>>
> >>>> Cheers,
> >>>> Daniel
> >>>>
> >>>>
> >>>> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette
> >>>><spmallette@gmail.com
> >>>> >
> >>>> wrote:
> >>>>
> >>>> I don't remember why we didn't have predicates for "text" searches?
> >>>>> Marko,
> >>>>> do you remember?
> >>>>>
> >>>>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>>
> >>>>>> Going through the gremlin Predicates I do not see one that is for
> >>>>>>doing
> >>>>>> full text searches.
> >>>>>> Have I missed it or is omitted on purpose?
> >>>>>>
> >>>>>> Having both case sensitive and non case-sensitive searches is a
> >>>>>>common
> >>>>>> requirement.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Pieter
> >>>>>>
> >>>>>>
> >>>>
> >>
>
>
>
>
>
Re: text search
Posted by Rob Vesse <rv...@dotnetrdf.org>.
You could do something akin to the SPARQL approach
You specify some limited subset of known functions with well defined
semantics e.g. contains(), startsWith() etc that are implemented in the
core language and then define a mechanism via which extension functions
may be referenced
e.g.
g.V().has('name', Functions.contains('monkey'))
And
g.V().has('name', Functions.extension('http://acme/textSearch', 'monkey'))
The idea being that extension takes the name of the function and then zero
or more arguments which are interpreted by the specific vendor
implementation of that extension function
In SPARQL those are named via URIs and each implementation can choose what
extension function(s) they add to their core implementation, in principal
at least having a global namespace allows for common useful extension
functions to be defined by one vendor and adopted by other vendors over
time. For Gremlim you may want to use some other naming scheme though
URIs have the advantage that you can take advantage of common conventions
around domain and thus namespace ownership
Rob
On 20/08/2015 12:36, "Matt Frantz" <ma...@gmail.com> wrote:
>I agree that there is a set of operations on scalar types that should be
>supported efficiently (i.e. by pushing them down). It would be nice if we
>could figure out a way to exploit vendor-specific features in some
>extensible portion of the API. Otherwise, we're just aiming at least
>common denominator capabilities.
>
>Many operations have standard definitions, but something like regular
>expressions can have variants, so we must be clear about how we would
>define conforming implementations.
>
>Suppose vendor Acme has an exclusive text searching capability that
>includes case folding, stemming, synonym matching, spelling correction,
>camel-case splittings, etc. Could there be an API like "P" that could be
>provided by the vendor, so that Gremlin expressions would reference it?
>Otherwise, we end up either maintaining a universal catalog of vendor
>capabilities or fuzzy matching the vendor capabilities to a universal
>list,
>which leads to vendor-specific application behavior. We could then
>migrate
>capabilities into the core as they become more widespread.
>
>g.V().has('name', AcmeP.exclusiveTextSearch('monkey'));
>
>As an application writer, I want to know when I can expect vendor-specific
>behavior, and this sort of API design would remind me of such choices.
>
>
>On Thu, Aug 20, 2015 at 11:17 AM, pieter <pi...@gmail.com> wrote:
>
>> Hi,
>>
>> I view Gremlin as a first class query language. As such it is more
>> concerned with what than how.
>>
>> I reckon
>>
>> String.contains
>> String.startsWith
>> String.endsWith
>> and some form of regular expression
>>
>> is so common it would be expected for any query language.
>>
>> A quick check on neo4j cypher and orientdb sql both support the above.
>> Cypher also has a case sensitive toggle/expression. Not sure about
>> Orientdb, probably a 'upper() + like %'
>>
>> The above predicates have no need for an index. If an index can be used
>> all the better but either way it should work.
>>
>> Thanks
>> Pieter
>>
>>
>> On 17/08/2015 16:10, Daniel Kuppitz wrote:
>>
>>> See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo'
>>>Face
>>>
>>><https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ>
>>>
>>> On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <me...@gremlin.guru>
>>>wrote:
>>>
>>> Because every vendor handles text comparisons differently. Some allow
>>>> regular expressions, others don't. Some vendors do case-sensitive
>>>> matches,
>>>> others case-insensitive, etc.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette
>>>><spmallette@gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> I don't remember why we didn't have predicates for "text" searches?
>>>>> Marko,
>>>>> do you remember?
>>>>>
>>>>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> Going through the gremlin Predicates I do not see one that is for
>>>>>>doing
>>>>>> full text searches.
>>>>>> Have I missed it or is omitted on purpose?
>>>>>>
>>>>>> Having both case sensitive and non case-sensitive searches is a
>>>>>>common
>>>>>> requirement.
>>>>>>
>>>>>> Thanks
>>>>>> Pieter
>>>>>>
>>>>>>
>>>>
>>
Re: text search
Posted by Matt Frantz <ma...@gmail.com>.
I agree that there is a set of operations on scalar types that should be
supported efficiently (i.e. by pushing them down). It would be nice if we
could figure out a way to exploit vendor-specific features in some
extensible portion of the API. Otherwise, we're just aiming at least
common denominator capabilities.
Many operations have standard definitions, but something like regular
expressions can have variants, so we must be clear about how we would
define conforming implementations.
Suppose vendor Acme has an exclusive text searching capability that
includes case folding, stemming, synonym matching, spelling correction,
camel-case splittings, etc. Could there be an API like "P" that could be
provided by the vendor, so that Gremlin expressions would reference it?
Otherwise, we end up either maintaining a universal catalog of vendor
capabilities or fuzzy matching the vendor capabilities to a universal list,
which leads to vendor-specific application behavior. We could then migrate
capabilities into the core as they become more widespread.
g.V().has('name', AcmeP.exclusiveTextSearch('monkey'));
As an application writer, I want to know when I can expect vendor-specific
behavior, and this sort of API design would remind me of such choices.
On Thu, Aug 20, 2015 at 11:17 AM, pieter <pi...@gmail.com> wrote:
> Hi,
>
> I view Gremlin as a first class query language. As such it is more
> concerned with what than how.
>
> I reckon
>
> String.contains
> String.startsWith
> String.endsWith
> and some form of regular expression
>
> is so common it would be expected for any query language.
>
> A quick check on neo4j cypher and orientdb sql both support the above.
> Cypher also has a case sensitive toggle/expression. Not sure about
> Orientdb, probably a 'upper() + like %'
>
> The above predicates have no need for an index. If an index can be used
> all the better but either way it should work.
>
> Thanks
> Pieter
>
>
> On 17/08/2015 16:10, Daniel Kuppitz wrote:
>
>> See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo' Face
>> <https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ>
>>
>> On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <me...@gremlin.guru> wrote:
>>
>> Because every vendor handles text comparisons differently. Some allow
>>> regular expressions, others don't. Some vendors do case-sensitive
>>> matches,
>>> others case-insensitive, etc.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette <spmallette@gmail.com
>>> >
>>> wrote:
>>>
>>> I don't remember why we didn't have predicates for "text" searches?
>>>> Marko,
>>>> do you remember?
>>>>
>>>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> Going through the gremlin Predicates I do not see one that is for doing
>>>>> full text searches.
>>>>> Have I missed it or is omitted on purpose?
>>>>>
>>>>> Having both case sensitive and non case-sensitive searches is a common
>>>>> requirement.
>>>>>
>>>>> Thanks
>>>>> Pieter
>>>>>
>>>>>
>>>
>
Re: text search
Posted by pieter <pi...@gmail.com>.
Hi,
I view Gremlin as a first class query language. As such it is more
concerned with what than how.
I reckon
String.contains
String.startsWith
String.endsWith
and some form of regular expression
is so common it would be expected for any query language.
A quick check on neo4j cypher and orientdb sql both support the above.
Cypher also has a case sensitive toggle/expression. Not sure about
Orientdb, probably a 'upper() + like %'
The above predicates have no need for an index. If an index can be used
all the better but either way it should work.
Thanks
Pieter
On 17/08/2015 16:10, Daniel Kuppitz wrote:
> See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo' Face
> <https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ>
>
> On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <me...@gremlin.guru> wrote:
>
>> Because every vendor handles text comparisons differently. Some allow
>> regular expressions, others don't. Some vendors do case-sensitive matches,
>> others case-insensitive, etc.
>>
>> Cheers,
>> Daniel
>>
>>
>> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette <sp...@gmail.com>
>> wrote:
>>
>>> I don't remember why we didn't have predicates for "text" searches?
>>> Marko,
>>> do you remember?
>>>
>>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Going through the gremlin Predicates I do not see one that is for doing
>>>> full text searches.
>>>> Have I missed it or is omitted on purpose?
>>>>
>>>> Having both case sensitive and non case-sensitive searches is a common
>>>> requirement.
>>>>
>>>> Thanks
>>>> Pieter
>>>>
>>
Re: text search
Posted by Daniel Kuppitz <me...@gremlin.guru>.
See: [TinkerPop3] Blueprints3 -- Push Down Predicates All Up in Yo' Face
<https://groups.google.com/d/msg/gremlin-users/ls4FD5r43Iw/AIFFCMyi3EQJ>
On Mon, Aug 17, 2015 at 4:08 PM, Daniel Kuppitz <me...@gremlin.guru> wrote:
> Because every vendor handles text comparisons differently. Some allow
> regular expressions, others don't. Some vendors do case-sensitive matches,
> others case-insensitive, etc.
>
> Cheers,
> Daniel
>
>
> On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
>> I don't remember why we didn't have predicates for "text" searches?
>> Marko,
>> do you remember?
>>
>> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Going through the gremlin Predicates I do not see one that is for doing
>> > full text searches.
>> > Have I missed it or is omitted on purpose?
>> >
>> > Having both case sensitive and non case-sensitive searches is a common
>> > requirement.
>> >
>> > Thanks
>> > Pieter
>> >
>>
>
>
Re: text search
Posted by Daniel Kuppitz <me...@gremlin.guru>.
Because every vendor handles text comparisons differently. Some allow
regular expressions, others don't. Some vendors do case-sensitive matches,
others case-insensitive, etc.
Cheers,
Daniel
On Mon, Aug 17, 2015 at 12:55 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> I don't remember why we didn't have predicates for "text" searches? Marko,
> do you remember?
>
> On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com> wrote:
>
> > Hi,
> >
> > Going through the gremlin Predicates I do not see one that is for doing
> > full text searches.
> > Have I missed it or is omitted on purpose?
> >
> > Having both case sensitive and non case-sensitive searches is a common
> > requirement.
> >
> > Thanks
> > Pieter
> >
>
Re: text search
Posted by Stephen Mallette <sp...@gmail.com>.
I don't remember why we didn't have predicates for "text" searches? Marko,
do you remember?
On Tue, Aug 11, 2015 at 3:35 PM, pieter <pi...@gmail.com> wrote:
> Hi,
>
> Going through the gremlin Predicates I do not see one that is for doing
> full text searches.
> Have I missed it or is omitted on purpose?
>
> Having both case sensitive and non case-sensitive searches is a common
> requirement.
>
> Thanks
> Pieter
>