Re: CG Recommendation

-----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-----

Received on Friday, 3 January 2014 16:12:36 UTC