Re: CG Recommendation

Hi Andy:
Good comments!
There is just one point on which we disagree.
I think we need a REST API as well as a data model syntax.

I take your point about optional items.  Do you think we should exclude them from the charter?
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
>
>

Received on Friday, 3 January 2014 14:15:05 UTC