Dear Drummond,
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 following sentences:
- "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?
Thanks,
Giovanni
At 08.20 10/02/2009, Drummond Reed wrote:
On the last telecon we discussed
the set of XDI RDF statements that Markus
and I concluded are inferred the XDI subject +x+y:
#1) +x/$has/+y
#2)
+y/$is$has/+x
;inverse
of #1
#3) +x/+y/+x+y
#4)
+x+y/$is+y/+x
;inverse
of #3
#5) +y/$a/+x+y
#6)
+x+y/$is$a/+y
;inverse
of #5
#7) +x/$has$a/+y
#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., the
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,
=Drummond
---------------------------------------------------------------------
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
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 6.50
