Re: CG Recommendation

On Jan 6, 2014, at 9:37 AM, Kelvin Lawrence <klawrenc@us.ibm.com> wrote:

> As I mentioned before a few days ago, there are already plenty of serializations in existence. We should not be looking to create another one.
> 
> I use GraphML (an XML markup) all the time. Their is also a JSON equivalent (GraphSON) and several CSV flavours of graph serializations as well as many other formats like GML, GEFX and GDF.
> 
> I believe we should focus on gaps and not areas where de-facto or better standards already exist.
> 
> Most existing graph technology can consume several of the existing formats.

As I've expressed before, I think there could be a great advantage to using JSON-LD for publishing property graph data; there have been some parallel discussions on how this might be accomplished.

One of the Linked JSON CG's work items to to create a streaming profile for JSON-LD, that would get around the in-memory limitations of the existing algorithms; this could make JSON-LD appropriate for large database dumps. There already is a streaming algorithm for turning an abstract RDF dataset into JSON-LD, so extending this for a property graph mapping should be straight-forward.

Gregg

> Cheers
> Kelvin
> 
> Kelvin R. Lawrence
> Distinguished Engineer & CTO, Software Standards
> IBM Software Group. 11400 
> 
> 
> -----Alan Wu <alan.wu@oracle.com> wrote: -----
> To: public-propertygraphs@w3.org
> From: Alan Wu <alan.wu@oracle.com>
> Date: 01/06/2014 11:08AM
> Subject: Re: CG Recommendation
> 
> Hi Folks,
> 
> Happy New Year!
> 
> I think XML based serialization is a good idea. A problem, though, is when data size
> gets really big, the parsing and serialization can take quite a bit of time. We may
> also want to think about a flat file structure. Something along the line of N-TRIPLES for RDF.
> 
> Cheers,
> 
> Zhe
> 
> On 1/3/2014 8:45 AM, Kelvin Lawrence wrote:
>> There are lots of existing syntaxes/serialization a. I use GraphML a lot. I worry we are trying to move too fast here. I was hoping for a lot more discussion before trying to close on "deliverables". Let's discuss on our next call.
>> 
>> Happy new year to all.
>> 
>> 
>> Cheers, Kelvin
>> DE & CTO Software Standards
>> IBM Software Group
>> Sent from my iPhone
>> 
>> 
>> On Jan 3, 2014, at 10:12 AM, "Patrick Durusau" <patrick@durusau.net> wrote:
>> 
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> > 
>> > Ashok,
>> > 
>> > Since we are talking about property graphs, should we consider an
>> > existing graph syntax?
>> > 
>> > http://www.graphviz.org/doc/info/lang.html
>> > 
>> > DOT has the following advantages:
>> > 
>> > 1) Widely known already
>> > 2) Supported by existing tooling
>> > 3) Supports statements about edges and nodes
>> > 4) Supports identifiers on nodes and the graph (for addressing)
>> > 
>> > I am sure there are others that I am overlooking.
>> > 
>> > Thinking if we don't try to re-invent the wheel, we can move more
>> > quickly towards a finished deliverable.
>> > 
>> > Hope everyone is early into a great new year!
>> > 
>> > Patrick
>> > 
>> > 
>> > On 01/03/2014 10:59 AM, Ashok Malhotra wrote:
>> > > Hi Andy: One other thought.  Should we consider a variant/extension
>> > > of one of the RDF syntaxes for expressing the data model?  This may
>> > > also tie into your thought of mapping RDF to PGs. Can someone float
>> > > a proposal? All the best, Ashok
>> > >
>> > > On 1/3/2014 6:46 AM, Andy Seaborne wrote:
>> > >> On 02/01/14 22:21, Ashok Malhotra wrote:
>> > >>> I took the liberty of creating a Wiki page to discuss what the
>> > >>> CG should recommend:
>> > >>> http://www.w3.org/community/propertygraphs/wiki/Recommendation
>> > >>>
>> > >>> Please comment.  Along with boilerplate this needs a Out of
>> > >>> Scope Bullet.
>> > >>>
>> > >>> Talk to you Tuesday.
>> > >>
>> > >> 1/ Focus
>> > >>
>> > >> In order to start of work on standardised property graphs at W3C,
>> > >> I would suggest aiming to get one thing done promptly.
>> > >>
>> > >> The more that gets added to a WG's charter, the longer it is to
>> > >> first finished document for any piece.  If you want to propose a
>> > >> 2 year WG that might actually finish in 2 years then less is
>> > >> better (most WGs overrun; WGs nearly always address "optional"
>> > >> items so they are not extras really).
>> > >>
>> > >> The most important items are the data model and syntax for
>> > >> writing the data model so it can be exchanged on the web.
>> > >>
>> > >> An important point is the experience of RDF with XML - using an
>> > >> existing data structure language lead to large files and
>> > >> cumbersome expression. Acceptable in the small, not good at
>> > >> scale.  A native property graph syntax should be included (as
>> > >> well as a JSON one if wanted but note JSON has very few datatypes
>> > >> types which makes life interesting in the detail).
>> > >>
>> > >> 2/ Linking
>> > >>
>> > >> There nothing about linking data and linking to places within
>> > >> graphs. Making data relate to other data is both a web issue but
>> > >> also an issue inside an organisation of even moderate size.
>> > >>
>> > >> 3/ Follow-ons
>> > >>
>> > >> Other, focused, WG can be chartered as it becomes clear what a
>> > >> core PG-data WG will achieve, and the community reaction to the
>> > >> work. Hopefully, that reaction includes member submissions to
>> > >> feed into those WGs.  Prototyping is better done outside a formal
>> > >> WG process.
>> > >>
>> > >> So I would remove the REST API from the charter in favor of doing
>> > >> the data model sooner.  A REST API is just one method of access;
>> > >> it does not fit all the use cases.  Rexster is on top of gremlin,
>> > >> albeit an extension, and if you are mentioning query language(s),
>> > >> the access language area is now quite large and mixed with API.
>> > >> The design space isn't clear cut.
>> > >>
>> > >> 4/ Target
>> > >>
>> > >> On the web, we have exchange of property graphs by linking to
>> > >> web resources and representations and linking to points within
>> > >> graphs.
>> > >>
>> > >> Andy
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> > 
>> > - --
>> > Patrick Durusau
>> > patrick@durusau.net
>> > Technical Advisory Board, OASIS (TAB)
>> > Co-Chair, OpenDocument Format TC (OASIS)
>> > Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300
>> > Former Chair, V1 - US TAG to JTC 1/SC 34
>> > Convener, JTC 1/SC 34/WG 3 (Topic Maps)
>> > Co-Editor, ISO 13250-5 (Topic Maps)
>> > 
>> > Another Word For It (blog): http://tm.durusau.net
>> > Homepage: http://www.durusau.net
>> > Twitter: patrickDurusau
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.11 (GNU/Linux)
>> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> > 
>> > iQIcBAEBAgAGBQJSxuFQAAoJEAudyeI2QFGoNYIP/ipgTfGGlLujxnmB6Vqd4Qnj
>> > KlV5zOunPGvy7it9bleng4oXWf4oWSMf/b8kykNM2KdHWz2yExuKl0FvuBzo6ks5
>> > e9NiUz+xIa7o+aLLkkflOnT+y9aw6QY4Zl76UDbZHbi+CBDxcMmSYSrh5uSOAoAw
>> > kEHRF1alMThBT2wotrM5LziK7wruEegGZ4ELg3kuY+ezBu5EmCt6DunHELH/ooaW
>> > Y/dQtlQdBWwFlCU6cC6GD6icc9xwPIDUI8F1FRUkMCK9CJqaV9uF5Ndq5w9uCV1X
>> > TSwsJXUwq2hWqcDYGwLibCLPpiQm6Sk1bbFA8BfIELc3wxEH3qtDo3hz29QlHZjo
>> > A6tvplhyei8LvVSzpYr+W34pLuw4rqJJrvfhT27fY27/MC4KCwsVQkHn6cDY9b6+
>> > WFHuo9XHgYatOlgtGdK8T0n7O3wC+0GBcD7hoIR9MuwpAfjgyXfsOPBZrcgg1P3V
>> > Ezhk0SlpZXLvJ5sieH6p72HuxvCqt0gvdA7Il3f2WCb3HMhfakMWkP1jEj5VkD32
>> > srOpLrVEPpfAhav90l3EWJ47JjdAqudnxGXC0xI9sC2Lrzp0uIWpgFiAl8MvV8Oq
>> > 0mdUcOaTLll+EjSW7OTHcsbDHHY4v4rus4WaM+nzR3enL3gsSHcARU8JQhwS+EDS
>> > HVfnZcrHdnI6UYECRIdk
>> > =pAUH
>> > -----END PGP SIGNATURE-----
>> > 
>> 
>