Thanks very much for writing this deeper
description of the issue – I mistakenly thought you were talking about
different graph notations and not about the difference between XDI RDF and
conventional RDF. I made this the main agenda item for tomorrow’s telecon
so we could discuss it in person.
However, since I may be late to the
telecon tomorrow, here’s some thoughts to get started.
While I agree that URIs in RDF are opaque,
I don’t think this means that an XDI RDF graph (in which the XRIs are not
opaque) cannot be expressed in a conventional RDF graph. So far I think every XDI
RDF metagraph statement can be rendered in conventional RDF. As covered in earlier
threads, according to both the analysis Bill did and to the one Markus and I did,
the XDI RDF statement +x/$has/+y, which is also represented by the XDI RDF subject
+x+y, can be expressed by the following four RDF statements (where xri: is the
base URI for all XRIs, e.g., http://xri.net/)
A) <xri:+x> <xri:+y>
D) <xri:$is+y> <rdfs:inverseOf>
I believe that these precisely captures
the RDF semantics of the XDI RDF statement +x/$has/+y. It doesn’t matter
that from an RDF standpoint the identifiers xri:+x, xri:+y, xri:+x+y, and
xri:$is+y are completely opaque. I believe they are all still valid RDF
statements – none of them “artificial” than any other RDF
statement – that could be used by any RDF reasoner to act on an RDF translation
of an XDI RDF graph.
My understanding was that our goal in section
8 of the XDI Addressing and RDF Graph Model spec (http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel)
was simply to provide a precise transformation between XDI RDF graphs and
conventional RDF graphs so XDI RDF could be processed by standard RDF
reasoners. I think we have a good start on that, and we need to complete that set
of transformations before we can complete the spec.
So I guess I may still be misunderstanding
what the issue is. I look forward to discussing it on the call. (Again, I may
need to be late, so please do feel free to get started without me.)
Sent: Wednesday, February 11, 2009
To: Drummond Reed
Cc: 'OASIS - XDI TC'; Nick
Nicholas; Barnhill, William [USA]
Subject: Re: [xdi] +x/+y/+x+y
thanks for your reply. In order to properly understand this issue, I've gone
through previous replies you gave to similar questions. I've found the
- "By definition that means
that the XDI subject address +x+y infers the XDI statement +x/+y/+x+y."
- "What $has and $has$a have in common is that both describe an outgoing
arcs on an XDI subject, both are rooted in $has
which is the metagraph predicate representing an outgoing arc."
- "the RDF relationship represented by +x+y has a direct RDF graph that
doesn't require any of the XDI metagraph predicates toe express. In ASCII art
(where  is a node and --- label ---> is an arc): [+x] --- +y --->
[+x+y] Note that all three XRIs are needed to
capture this graph in standard RDF."
Now, all these have in common that they all refer to a notation, the standard
RDF graph notation, in which predicates are expressed through arcs. That
standard notation is born to support RDF statements, but as you correctly
pointed out many times:
"[…] XDI addressing is so foreign to RDF: it requires structured
identifiers to express the semantics, and in
conventional RDF the identifiers are opaque"
The statement +x/+y/+x+y comes from an attempt to express the semantics of a
composite identifier (+x+y) through that conventional RDF graph notation.
However, that notation cannot capture this semantics, as it makes no assumption
about the meaning of the identifiers it uses (identifiers are opaque to
conventional RDF). Though syntactically correct, and as such expressible using
conventional RDF graph notation, I think that +x/+y/+x+y might be, from a
semantic point of view, at least an unnecessary statement (if not even a
dangerous one). Of course we can give it "by definition", but this definition
comes from the fact that we are using the conventional RDF graph notation with
“non conventional” identifiers. That’s exactly what I meant
by saying “+x/+y/+x+y is probably biased by a specific notation”.
I understand that maintain backward compatibility with previous standards is in
general required. However, this time we risk to pay an unjustified price:
introducing artificial statements.
Or maybe I'm missing something? What do you think?
At 08.20 10/02/2009, Drummond Reed wrote:
On the last telecon we discussed the set of XDI RDF statements that
and I concluded are inferred the XDI subject +x+y:
#2) +y/$is$has/+x ;inverse
#4) +x+y/$is+y/+x ;inverse
#6) +x+y/$is$a/+y ;inverse
#8) +y/$is$has$a/+x ;inverse of #7
At the end of the telecon, Giovanni asked "Is #3 above, i.e., +x/+y/+x+y,
really an inference from +x+y, or does that follow from a specific graph
notation?" I had the action item to pen an answer.
My answer is that yes, since the XDI subject +x+y represents the XDI
metagraph statement +x/$has/+y, then it infers all 7 of the other statements
above, irrespective of any particular graph notation. In fact, the RDF
relationship represented by +x+y has a direct RDF graph that doesn't require
any of the XDI metagraph predicates toe express. In ASCII art (where  is a
node and --- label ---> is an arc):
[+x] --- +y ---> [+x+y]
Note that all three XRIs are needed to capture this graph in standard RDF.
In other words, the $has statement +x/$has/+y does not constrain the subject
+x to just having a singleton predicate +y. +x may in fact have any number
of predicates +y (if so, that means +x/$has$a/+y). However the statement
+x/$has/+y is the assertion that +x has EXACTLY ONE +y predicate AND that
the object of that predicate MUST have the identifier +x+y.
Another way to put it is that, in contrast to a $has$a statement, a $has
statement is a way of expressing the English article, "the". So while
+x/$has$a/+y is a way of referring to "a" predicate +y on +x (i.e.,
class of all +y that are predicates on +x), +x/$has/+y is a way of referring
to THE (exactly one) +y that serves as a unique path to the object node,
which by definition has the path (address) +x+y. (Like any XDI subject, it
can also have other XRI synonyms, but this one is know a priori.)
Hope this helps,
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:
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.233 / Virus Database: 270.10.19/1941 - Release Date: 09/02/2009