OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Proposed revisions to XDI graph notation


Excellent discussion! I see the pros and cons of all points being made. See my next message with new examples of both options being discussed.


On Wed, Sep 11, 2013 at 9:00 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think it's still important to draw the literal arc, because
- it is a subject/predicate/object triple and appears as such in our serialization formats
- it may or may not be there

When explaining XDI, I have always found it sexy to talk about the 3 different arc types (contextual, relational, literal).

One advantage I see in your idea however is that it would make it easier to think about the "attribute without a value" situation(s) we have come across.

Markus


On Wed, Sep 11, 2013 at 5:12 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
I think omitting the literal node shape is a good idea, and would go further and say that the literal arc and node do not need to be named as an arc and node. Instead, the value can simply be called a property of the value context node. When only one arc is permitted and can be only one type, this is a trivial case of "graph" and it is complicating and confusing to refer to it as a (sub)graph. Also, the two &s in a row look redundant even to the uninitiated.

Graphically, maybe the value could just appear to the right of the value context node without drawing an arc.

I propose we drop the concepts of literal node and literal arc. The remaining 4 node types are all context nodes, either root, entity, attribute, or value. One way to enumerate context node subtypes is:

root,
entity singleton, entity collection, entity member,
attribute singleton, attribute collection, attribute member,
value undefined, value JSON null, value JSON true, value JSON false,
value JSON number, value JSON string, value JSON array, value JSON object/hash

The 4 subtypes on the last line would have additional properties containing the number, string, array, or object data.
The other subtypes consist only of the type/subtype enum, with no additional data needed.

On Sep 10, 2013, at 11:57 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

> All,
>
> As I get down into the details of editing XDI Core Working Draft 01, the time has come to propose some long-discussed updates to our XDI graph notation.
>
> I have been noodling on this ever since our syntax simplification work last spring. At first I was trying to come up with new shapes for all the different node types (root, entity singleton, entity collection, entity member, attribute singleton, attribute collection, attribute member, value). It was always too complex.
>
> Then I hit on the idea of keeping the symbols to a very small set, and using a single character inside the symbol to indicate the multiplicity. That seemed to work much better, and to quickly teach the concept of multiplicity without a lot of explanation.
>
> In terms of the symbols, it seemed obvious to keep using the open circle for root nodes and the closed circle for entities. Due to our choice of syntax, it also seemed intuitive to use the closed diamond for attribute nodes and the open diamond for value nodes -- essentially the mirror of root/entity nodes.
>
> After playing with it, I also realized that because we now have value nodes, explicitly showing another shape for a literal node seems redundant and overly complex. Much simpler to just show the literal arc going to the value itself (since now there is ALWAYS a value if there is a literal arc, even if the value is null).
>
> The result is below -- both a summary of the graph notation and a simple example graph.
>
> Please do post your comments/suggestions.
>
> =Drummond
>
> <image.png>
>
>
> <image.png>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]