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] Last call for feedback on XDI Core 1.0 ABNF


On Sat, Oct 10, 2015 at 1:45 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I agree with your wording and list of nodes/arcs.

The XDI/RDF mapping will be a bit ugly this way, because in order to model XDI relational arcs to/from literal nodes, we would have to express an XDI literal either as an RDF resource, or a reified RDF statement. But this is of course a deficiency of RDF :)

Yes, I was thinking about that. I've noted several times in the past few years that some in the RDF community have wished that RDF literals could be treated as subjects (I can't remember the reasons why). And it's not surprising to me that, because the XDI graph model provides a uniform way to model context, we have a way of describing a literal node as an XDI subject.

I agree that in the XDI/RDF mapping, I think the & address for a literal node would need to become an RDF resource.

I'm starting to think that we might need a separate spec to specify how an XDI graph maps into an RDF graph—or, if it's short enough, that we could add that to a subsequent draft of the XDI Core 1.0 spec. What do others think?

=Drummond 
 




On 10/10/2015 12:12 AM, =Drummond Reed wrote:
Markus, I stand corrected. I should have called the & symbol a "virtual context node" because I agree there's no actual additional context node in the graph. The & is simply the address of a literal node expressed in an XDI address.

To answer your question, I drew it out the graph and, I agree, it consists of 7 nodes and 7 arcs.

NODES
  1. common root node
  2. entity singleton node =drummond
  3. attribute singleton node <#email>
  4. literal node "drummond@respect.network"
  5. entity singleton node =markus
  6. entity collection node [$msg]
  7. entity singleton node *!:uuid:1234
ARCS
  1. #1 to #2 label =drummond
  2. #2 to #3 label <#email>
  3. #3 to #4 label "&"
  4. #1 to #5 label =markus
  5. #5 to #6 label [$msg]
  6. #6 to #7 label *!:uuid:1234
  7. #7 to #4 label $get
Does this match your expectations?

In this case, do you see an issue with the virtual representation of a literal being able to be represented in the XDI graph?

=Drummond 



The key is that the arc

On Fri, Oct 9, 2015 at 2:02 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Still not sure. How would you draw this statement?
=drummond<#email>/&/"drummond@respect.network"

And then how would you draw this?
=markus[$msg]*!:uuid:1234/$get/=drummond<#email>&

Would you agree that if you have these two statements in a graph, and you draw the graph, it would consist of 7 nodes and 7 arcs ?

Markus


On 10/09/2015 06:56 PM, =Drummond Reed wrote:
On Fri, Oct 9, 2015 at 2:55 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Thanks I think this ABNF can work, but I have to point out that there is a quite significant change to how I had understood the XDI graph model so far.
This is the fact that with this ABNF, both the subject and object of a relational arc may be literal nodes.
While we had definitely agreed that objects may be literal nodes, for subjects this could be a problem.

1. Your XDI Core V1.0 WD05 in section 4.3 probably has to be changed in any case:
"A Relational arc describes any other relationship between two context nodes."

2. I believe literal nodes as subjects would seriously impact our RDF compatibility, e.g. in section 4.3.3 you say:
"XDI relational arcs are the equivalent of RDF properties that describe the relationship between two RDF resources"

So I think this all hinges on the consideration of the & context node. To be specific, I'm talking about the node that has an XDI address that looks like this:

=drummond<#email>&

The final & at the end of that address represents the one and only one literal node that can be present on the attribute

=drummond<#email>

However I submit that the & node is not itself a literal node (and in fact cannot be a literal node). It is the special context node that can be used to represent the literal node as a context.

Thus there is no change to the XDI graph model and the only change I think is needed in the spec is to add text to the Literal Arcs and Literal Statements section further clarifying the answers to precisely the questions Markus raised here.

Markus, if you agree, I will make those changes in Working Draft 05 this weekend.

=Drummond 
 



On 10/09/2015 08:27 AM, =Drummond Reed wrote:
As Joseph and Markus and I head into the final 10 days of editing, I want to make sure anyone who has not looked over the ABNF does so ASAP.


The two questions Markus raised on the last TC call have been answered to his satisfaction (I believe—correct me if I'm wrong, Markus).

I did my own proof-reading tonight and found two small bugs that were an easy fix:
  • peer-root-variable = "{" peer-root "}"          ==>          peer-root-variable = "{" peer-root-instance "}"

  • inner-root-variable = "{" inner-root "}"        ==>          inner-root-variable = "{" inner-root-instance "}"

The one remaining question (that Joseph had poised in the previous version of the ABNF) is whether we should make any adjustments to the whitespace rules in the ABNF we inherit from JSON. My proposed answer is "No" because:
  1. I don't see any reason we should be more restrictive than the ABNF rules that the JSON community has already established.
  2. We will (I assume) normalize out whitespace for any XDI signature or encryption operations anyway.
Does anyone disagree? If so, please speak up now by reply to this thread so we can eliminate this as a topic we need to talk about on next Monday's call.

BTW, I strongly encourage everyone on the TC to attend the next two calls (Monday Oct 12 and Monday Oct 19, both 10-11:30PT) as they are our final two calls before we open the XDI Core 1.0 Committee Specification Draft vote after the October 19 call. It will be an online vote, so it will have to run for a minimum of 1 week to close before IIW, which is why we need to open it on the 19th.

Thanks,

=Drummond  








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