Next in thread →
Next in month →
Re: [xdi] Last call for feedback on XDI Core 1.0 ABNF
On Sat, Oct 10, 2015 at 1:45 AM, Markus Sabadello <> 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
common root node
entity singleton node =drummond
attribute singleton node <#email>
literal node ""
entity singleton node =markus
entity collection node [$msg]
entity singleton node *!:uuid:1234
ARCS
#1 to #2 label =drummond
#2 to #3 label <#email>
#3 to #4 label "&"
#1 to #5 label =markus
#5 to #6 label [$msg]
#6 to #7 label *!:uuid:1234
#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 <>
wrote:
Still not sure. How would you draw this statement?
=drummond<#email>/&/""
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 <>
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.
https://wiki.oasis-open.org/xdi/XdiAbnf
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:
I don't see any reason we
should be more restrictive
than the ABNF rules that the
JSON community has already
established.
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
Next in thread →
Next in month →