Re: CG Recommendation

Hello everyone,

Best wishes to all of you for a nice happy year!

I am also in favour of something similar to RDF serialisations rather than xml, mostly JSON based.
Specially with the great boost of JSON storages like mongodb, couchbase, and many others it would be a nice practice.

Regards,
Michael.

On Jan 6, 2014, at 7:07 PM, Alan Wu <alan.wu@oracle.com<mailto:alan.wu@oracle.com>> wrote:

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><mailto: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<mailto: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<http://tm.durusau.net/>
> Homepage: http://www.durusau.net<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-----
>