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] XDI graph model node type diagram


On Tue, Nov 26, 2013 at 8:06 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:
“Global” would be clear than “outer”. I’m not completely satisfied with “peer” and “inner” but don’t have alternative suggestions yet.

Yes, I've been cooking on whether we should return to using "global" for the outer graph. I'll send a separate message on that.
 

Another thing I’ve noticed about entity-relationship modeling:


Entities and relationships can have attributes, but attributes themselves cannot. 

Yes, in conventional EAV, that's true. 
 

In XDI do attributes have attributes, or do all attributes in an address apply to the preceding entity, not any preceding attributes?

Yes, attributes have attributes, e.g., an email attribute for a person can itself have a datestamp.
 

Also, the article provides equivalences of these terms with natural language categories:


Might it be even more intuitive to talk about nouns, verbs, and adjectives in XDI, rather than entities etc.?

My personal opinion is that, while it can be helpful to introduce that analogy in the spec text, those terms are: a) English-language centric, and b) not as technically accurate as the terms in the model.

=Drummond 
 

On Nov 25, 2013, at 12:05 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

Okay, here is an update that reflects moving variable up a level. Note that I didn't change the term "graph" because I believe in this context it works better than either "root" or "start" because it contrasts directly with "subgraph", which is any branch of contexts within a graph. In other words, with a graph, you are always dealing with a whole graph, whereas with a subgraph, you are never dealing with a whole graph.

Note that the only XDI syntax not represented in the model yet is the distinction between authorities and classes. That can easily be added as additional detail at the very bottom layers.

<image.png>



On Mon, Nov 25, 2013 at 8:22 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think I would do the following:

1. Rename Graph to Root (or Start)

2. Put Variable one level up as you suggested.

I agree a variable can stand for pretty much anything. I'd like to spend some time on working out the syntax for constraining variables.

Markus


On Monday, November 25, 2013, Drummond Reed <drummond.reed@xdi.org> wrote:
> On Sun, Nov 24, 2013 at 11:12 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
>>
>> Can you give an example where a variable includes an entire graph?
>
> I was thinking about that when I drew the diagram. Here's one:
> (=drummond){()}<$uri>
> That's an example of a query that uses a typed variable {()} to indicate that nodes satisfying the variable must be a graph—in this case a peer graph of (=drummond).
>  
>>
>> Maybe it would be more appropriate to say it is a placeholder for (part of) a subject, predicate or object in a statement?
>
> I agree a variable can be all of that. But what does that mean about where Variable should appear in the taxonomy? Should it be where I have it now, or should it move up a level and be on the line with Graph and Subgraph?
> =Drummond 
>  
>>
>> On Sun, Nov 24, 2013 at 4:18 PM, Drummond Reed <drummond.reed@xdi.org> wrote:
>>>
>>> Another project on my trip was to draw the diagram illustrating the taxonomy of node types in the XDI graph model that I plan to include in the XDI Core 1.0 spec. The outcome is below. Notes:
>>>
>>> This reflects all the same types as on https://wiki.oasis-open.org/xdi/GraphModelStructure except the classification is slightly different.
>>> The only interesting new placement is Variable. Before I had just classified it as a different type of context. But a variable syntax (curly brackets) has more in common with graph syntax (parentheses) than anything else. And a variable can include an entire graph. So it seems to make sense to include it in the graph tree.
>>>
>>> Thoughts before I move forward with publishing this?
>>> =Drummond 
>>>
>>> </mail/u/0/s/?view=att&th=1428f9d75eb5d5db&attid=0.1&disp=emb&realattid=ii_1428aa72603a1ba6&zw&atsh=1>
>>>
>>>
>>
>
>





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