Re: CG Recommendation

agreed. I don't think the syntax is very important at all right now. But 
any property graph structure in RDF can use any potential serialization 
as long as that serialization supports quads.


On 1/6/2014 1:09 PM, Alan Wu wrote:
> Hi Kelvin,
>
> Yes we should discuss this on a call.
>
> I should make myself clear. Actually I was not talking about the exact 
> N-TRIPLES or N-QUADS format.
> Those were defined for RDF anyway. The very simple one-edge-per-line 
> structure is what I like.
>
> Thanks,
>
> Zhe
>
> On 1/6/2014 12:57 PM, Kelvin Lawrence wrote:
>> We should have this discussion on a call but I don't see N-Triples as 
>> a good fit for arbitrary property graphs. What is more interesting to 
>> me is the intersection of the graph world and things like schema.org. 
>> That discussion came up at the workshop and also intersects with the 
>> JASON-LD conversation.
>>
>> Cheers
>> Kelvin
>>
>> Kelvin R. Lawrence
>> Distinguished Engineer & CTO, Software Standards
>> Member of the IBM Academy of Technology (http://www.ibm.com/ibm/academy)
>>
>>
>> -----Alan Wu <alan.wu@oracle.com> wrote: -----
>> To: Jans Aasman <ja@franz.com>
>> From: Alan Wu <alan.wu@oracle.com>
>> Date: 01/06/2014 01:45PM
>> Cc: public-propertygraphs@w3.org
>> Subject: Re: CG Recommendation
>>
>> Yes :)
>>
>> Zhe
>>
>> On 1/6/2014 11:43 AM, Jans Aasman wrote:
>>> or NQUADS
>>>
>>> On 1/6/2014 9:07 AM, Alan Wu 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> 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-----
>>>>> >
>>>>>
>>>>
>>>
>>> -- 
>>> -------------------
>>> Jans Aasman
>>> CEO Franz Inc
>>> Office : 510 452 2000 x 119
>>> Cell : +1 925 878 1444
>>> Skype: jansaasman
>>
>

-- 
-------------------
Jans Aasman
CEO Franz Inc
Office : 510 452 2000 x 119
Cell : +1 925 878 1444
Skype: jansaasman