...noticed my last example didn't render properly, Should have been:
(dad) {"name":"Nigel"}
(son1) {"name":"Joshua"}
(son2) {"name":"Stephen"}
(dad)-[:FATHER_OF]->(son*)
(son*) {"lastname","Small")
Hope that works this time!
*
*
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige <https://twitter.com/#!/technige>
LinkedIn: http://uk.linkedin.com/in/nigelsmall
On 12 November 2011 11:26, Nigel Small <ni...@nigelsmall.name> wrote:
> Hi Michael
>
> Completely agree on named parameters - I'd like to support both named and
> positional - both have advantages.
>
> I also like the idea of the {foo} syntax as consistency with Cypher is
> what I have tried to provide all along here. I actually don't believe that
> it will be confusing with JSON (even with the composite descriptor syntax)
> but this notation is unfortunately already used by the index entry syntax:
>
> {my_index}->(my_node)
>
> Having said that, this clash doesn't have to give us a major problem. We
> could deprecate the existing index entry syntax (possibly maintaining
> backward compatibility for a while with a bit of regex jiggery-pokery) and
> replace it with something new, such as:
>
> <my_index>->(my_node)
>
> or
>
> |my_index|->(my_node)
>
> Back to parameters. There's an amazing amount of strength in the concept
> of multiple entities specified by a single token so agree that we should
> look further into that. Behind the scenes, it should be simple enough to
> add multiple entries when one of these is encountered, by iterating through
> the items. Even more Interesting with something like:
>
> {parents}-[:PARENT_OF]->{children}
>
> which could break down to:
>
> (father)-[:PARENT_OF]->(child1)
> (father)-[:PARENT_OF]->(child2)
> (mother)-[:PARENT_OF]->(child1)
> (mother)-[:PARENT_OF]->(child2)
>
> The comma syntax, again, looks very useful. Would this lead to us wanting
> some form of pattern matching as well?
>
> *(dad) {"name":"Nigel"}**(son1) {"name":"Joshua"}**(son2)
> {"name":"Stephen"}**(dad)-[:FATHER_OF]->(son*)**(son*) {"lastname","Small")*
>
> *
> *
>
> *Cheers*
>
> *Nigel Small*
> Phone: +44 7814 638 246
> Blog: http://nigelsmall.name/
> GTalk: ni...@nigelsmall.name
> MSN: nasm...@live.co.uk
> Skype: technige
> Twitter: @technige <https://twitter.com/#!/technige>
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>
>
>
> On 12 November 2011 05:44, Michael Hunger <
> michael.hun...@neotechnology.com> wrote:
>
>> Nigel,
>>
>> Sounds good, although I'd rather have named parameters as well, otherwise
>> parameter indexes will easily get unwieldy.
>>
>> I would like to propose to use the same syntax cypher uses for parameters
>> (that's also the syntax used by the batch-inserter)
>>
>> aka. {0} and {name}
>>
>> > (dad)-[:FATHER_OF]->(son2)
>> > {1}-[:FAMILY]->(dad)
>>
>> Might be a bit confusing wrt the json, But I want consistency :)
>>
>> Interesting part would also be when those parameters not only refer to a
>> single node or relationship but an collections of those.
>>
>> So one could take the output of a traversal or cypher query (with aliases
>> or position) and pass them into the geoff reader which then connects or
>> updates all of them appropriately.
>>
>> Allowing us to do mass-updates or structural connections in one go.
>>
>> (dad)-[:FATHER_OF]->{children}
>> {children} {"lastname" : "Small"}
>>
>> Btw. that reminds me of a version of the geoff syntax that might compact
>> many files:
>> > (dad) {"name":"Nigel"}
>> > (son1) {"name":"Joshua"}
>> > (son2) {"name":"Stephen"}
>> > (dad)-[:FATHER_OF]->(son1,son2)
>> > (son1,son2) {"lastname","Small")
>>
>> Michael
>>
>> Am 12.11.2011 um 00:07 schrieb Nigel Small:
>>
>> > Hi Peter
>> >
>> > Imagine we are trying to inject a simple graph, such as the following:
>> >
>> > (dad) {"name":"Nigel"}
>> > (son1) {"name":"Joshua"}
>> > (son2) {"name":"Stephen"}
>> > (dad)-[:FATHER_OF]->(son1)
>> > (dad)-[:FATHER_OF]->(son2)
>> >
>> > Currently, this would be loaded into graphspace without any attachment
>> to
>> > existing structures; a join would have to be made *after* the load.
>> >
>> > If we instead consider parameterising the load, e.g.
>> loadIntoNeo4j(reader,
>> > graphDB, someNode, otherNode, ...), we can reference the supplied nodes
>> > from within the GEOFF data. I think that ($n) notation would be quite
>> > useful here as it is already familiar from bash etc. This might
>> therefore
>> > turn the above subgraph into:
>> > *
>> >
>> > (dad) {"name":"Nigel"}
>> > (son1) {"name":"Joshua"}
>> > (son2) {"name":"Stephen"}
>> > (dad)-[:FATHER_OF]->(son1)
>> > (dad)-[:FATHER_OF]->(son2)
>> > ($1)-[:FAMILY]->(dad)
>> >
>> > ...such that ($1) refers to the first supplied parameter, ($2) would be
>> the
>> > second and so on. ($0) could possibly refer to the reference node of the
>> > destination graph, by definition.
>> >
>> > Hope this makes sense! What do you reckon?
>> >
>> > *
>> > *Nigel Small*
>> > Phone: +44 7814 638 246
>> > Blog: http://nigelsmall.name/
>> > GTalk: ni...@nigelsmall.name
>> > MSN: nasm...@live.co.uk
>> > Skype: technige
>> > Twitter: @technige <https://twitter.com/#!/technige>
>> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
>> >
>> >
>> >
>> > On 11 November 2011 22:10, Peter Neubauer
>> > <peter.neuba...@neotechnology.com>wrote:
>> >
>> >> Nigel,
>> >> On Thu, Nov 10, 2011 at 11:01 PM, Nigel Small <ni...@nigelsmall.name>
>> >> wrote:
>> >>> We could possibly create some form of syntax which would designate a
>> >> "this"
>> >>> node, e.g. (@). This could allow a file to reference it's external
>> >> context,
>> >>> in this case the node to which we are submitting the subgraph.
>> >> What would this look like?
>> >>
>> >> /peter
>> >> _______________________________________________
>> >> Neo4j mailing list
>> >> User@lists.neo4j.org
>> >> https://lists.neo4j.org/mailman/listinfo/user
>> >>
>> > _______________________________________________
>> > Neo4j mailing list
>> > User@lists.neo4j.org
>> > https://lists.neo4j.org/mailman/listinfo/user
>>
>> _______________________________________________
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
