- From: Patrick Durusau <patrick@durusau.net>
- Date: Fri, 03 Jan 2014 19:05:27 -0500
- To: public-propertygraphs@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy, Sorry, I didn't mean to imply a rush to deliverables but on the other hand, I'm not terribly interested in a boil the ocean agenda that starts from scratch. That we should think about tweaking some existing format (DOT was just the first one that came to mind, no endorsement or opposition implied) seemed like a point that needed to be made. That was all that I meant. Hope you are at the start of a great weekend! Patrick On 01/03/2014 04:36 PM, Andy Seaborne wrote: > On 03/01/14 16:45, 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. > > I share that worry. There are many formats and with each an > implicit or explicit data model, with many similarities but also > differences. xsd:dateTimes? > > Andy > >> >> 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: >> > 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/ iQIcBAEBAgAGBQJSx1BAAAoJEAudyeI2QFGohGwP/ihy2DEB3Tn7N8vGjfA5sh/v G1BQZ7jyVxFn3aFPBpyKScdl5XbzjyT5CG6YRbOJKDuYmB1uEKkwducecJ7qQDUq 5qcxpFz5JDp9oVHLLbcDr6yO8EgplGZTpmMEEwJ0UoZ9TCkqLGupOXZ8/7vjVS4T cJY+Svr7pOxNZOBRxcvxlvfuYQuTZTcAm3jBhZvHYg8qb4p7dwDGteZOFN2F/iYZ uPO3KN2lo0SPp/oPZvVYAgoTJSvECGmQ4GZLy3w9REMCB7t/5diDMh8MnC/TF/6C q9HDGdCOwP21LWH9mHZ87KzPXk6NtKpEuw42c03qjpqUE3pDKA67D1lf7UIk14MO QllE8Ji00NBttUIUBwgbVU2u0Slj2H0l6XSZNUWEhQg5FlFctf5aVwatM7GWv3c0 EQqUjVeirP0nWO/kX0Ot0JxpFS16CtpELGZqS5il/9CFIGO9UPNNKakyb4VZQYH0 4R+STEg8qio+HBSHXMwH0WNv6mSaRY8BMj/g+1mgjyBbsNHm5pjKoAnur19SDhVZ sRuAO2jq8y/ebsB9Sy8qXHIlY2S23IWif0wjYVBV2LTaeUEdg1djGnLKbjFQ3YIn SJSA02nHEzAZrEMdxiy0EFJ9q03e8l+pvkh1kzGzAjRyH9mUcaO1cbg4ynMkvFBU X5V981EPdMkfzHVkY0Wr =JP8v -----END PGP SIGNATURE-----
Received on Saturday, 4 January 2014 00:06:06 UTC