Bill,
Mea culpa. It’s a classic case of “being
too close to it”. The way I drew the graph (far right) in 2A and 2B, it
looks like the metagraph statement (first column) +x/$has/+y produces the graph
statement +x/+y/+x+y. But the actual graph statement is the one in the third
column: +x+y. (That’s why I evolved the diagrams into a four-column
format – so we could show the metagraph statement and metagraph diagram
in the first two columns, and the graph statement and graph diagram in the last
two columns).
However your message made me stop and
stare at this diagram and figure out why it LOOKS like the diagram is saying the
metagraph statement +x/$has/+y produces a graph that reads +x/+y/+x+y. What I
was trying to depict was simply that +x/$has/+y was saying the node +x has the
arc +y and _the object of that arc has the
XRI +x+y_.
And suddenly the light bulb came on. +x/$has/$y
as a metagraph statement is asserting the existence of a BLANK NODE. It’s
that _blank node_ to which we
assign the XRI +x+y in the graph.
So the drawing of the standard XDI RDF graph
statement +x+y should really look like this:
This reinforces the realization I had
Tuesday night that was at the heart of “sovling the Rubik’s cube”
of the metagraph model. When I first started to produce diagrams of all the metagraph
predicates for my conversations with Nick Nicholas in December, I ran headlong
into what seemed like a paradox: if $has corresponded to an assertion that a
node (the subject) had an outgoing arc (the object) then both $has and $has$a _appeared_ to produce the same diagram. For
example, it looked like +x/$has/+y and +x/$has$a/+y would both produce:
But because we were using $a as the
inversion predicate at that time, I got off completely on the wrong track
trying to solve this problem. I got away from the metagraph predicates just
purely describing the plain graph and started into trying to give them semantics
outside of pure graph description.
The light bulb I had Tuesday night (and
the reason I keep calling it “solving the Rubik’s cube” –
a game my youngest son is currently infatuated with) is that, by switching to $is,
the self-describing arc, as the inversion predicate (which now makes so much
more sense to me), then the difference between $has and $has$a also started to
line up (just like a Rubik’s cube).
The big “AHA” was the
realization that $has and $has$a DO both describe that a node (the subject) had
an outgoing arc (the object). The difference is _what they are describing about that arc_. $has, as I explain
above, is describing that the outgoing arc form a unique path to another node in
the graph. In RDF that corresponds directly to the concept of a blank node as
an object. The difference is that the statement +x/$has/+y is saying that “+x
has a pointer to this node called +y”, and therefore the metagraph statement
+x/$has/+y defines a path, +x+y, that can now be used to address this otherwise
blank node.
You can think of $has as the “registration”
verb that registers the identifier (arc) +y with +x in order to produce the XRI
path +x+y.
So that’s what $has is describing in
the plain graph – simply the address of a unique target node which
corresponds to a singleton blank node in a standard RDF graph.
By contrast, $has$a – which literally
itself represents the metagraph statement $has/$has/$a – describes the set
of nodes (I’m tempted to say “the class of nodes” but that
starts to read semantics into it) that are the object of the $has$a statement. In
other words, +x/$has$a/+y is purely a description of the plain graph saying the
node +x has the arc +y, and thus it corresponds to the plain graph statement
+x/+y, which is the plain graph diagram for 5A and 5B in the PDF:
This also answers Markus’ question
last week about “what does an XDI address of just a subject and predicate
address?” My answer is that it addresses the set of all XDI RDF graph
nodes that are the object of +x/+y. The metagraph statement +x/$has$a/+y
describes/defines this set.
Hope this helps – this email is just
a transcription of what I was hoping we would be able to go over on the call in…3
minutes!
=Drummond
From: Barnhill,
William [USA] [mailto:barnhill_william@bah.com]
Sent: Thursday, January 15, 2009
10:43 AM
To: Drummond Reed; 'OASIS - XDI
TC'
Subject: RE: [xdi] Agenda: XDI TC
Telecon Thursday 1-2PM PT 2009-01-15
Hi Drummond,
I'm unclear on the relationship between metagraph and graph. I had
thought the relationship was comparable to the relationship between the
T-Box and the A-Box in RDFS, OWL, etc. but your diagrams seem to be
saying otherwise. For an example the metagraph diagram for 2A (+x+y) leads to a
graph statement of +x/+y/+x+y, which I am having trouble relating to RDF.
In my mind the XDI metagraph statement +x+y is comparable to the metagraph
statements stated in the following RDF/XML notation:
<owl:Class rdf:about="http://plus.xri.net/x">
<rdfs:subClassOf
rdf:resource="&owl;Thing" />
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=http://plus.xri.net/y
/>
<owl:minCardinality
rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction
</rdfs:subClassOf>
</owl:Class>
Which then might lead an XDI reasoner to entail the implicit graph
statements expressed in
<rdf:Description
rdf:about="http://equals.xri.net/Bill.Barnhill" >
<rdf:type
rdf:resource="http://plus.xri.net/x" />
</rdfDescription>
from the explicit graph statements expressed in:
<rdf:Description
rdf:about="http://equals.xri.net/Bill.Barnhill" >
<rdf:type rdf:resource="&owl;Thing"
/>
<plus:y>!1234!234</plus:y>
</rdfDescription>
In XRI terms the following implicit XRI in the XDI graph
would be determined by an XDI reasoner:
=Bill.Barnhill/$a/+x
from the following explicit XRIs in the graph (playing fast and loose
with name spaces here):
=Bill.Barnhill/$a/+Thing
=Bill.Barnhill/+y/!1234!234
and a query on the graph of $$X/$a/+x will answer [{"$$X",
"=Bill.Barnhill"}]
Could you explain how the above would be done with the metagraph
predicate framework described by your diagram and recent wiki update?
Regards,
=Bill.Barnhill
From: Drummond
Reed
Sent: Thu 1/15/2009 4:48 AM
To: 'OASIS - XDI TC'
Subject: [xdi] Agenda: XDI TC
Telecon Thursday 1-2PM PT 2009-01-15
Following is the agenda for the unofficial telecon of the XDI TC at: Date: Thursday, 15 January 2009 USATime: 1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC) TO ACCESS THE AUDIO CONFERENCE: Dial In Number: 571-434-5750 Conference ID: 5474 AGENDA 1) XDI ADDRESSER We will start with a tour from Markus of his latest XDI RDF utility: http://graceland.parityinc.net/xdi-addresser/XDIAddresser 2) SOLVING THE RUBIK'S CUBE OF THE XDI 1.0 RDF METAGRAPH MODEL Based on insights from Monday's aborted XRI/XDI editor's telecon (whichturned into a long informal XDI telecon) and Tuesday's special XRI Syntax3.0 telecon (which also ended out as a long XDI discussion), Drummond had akey revelation about the metagraph model. He has uploaded a PDF with a new set of diagrams illustrating the metagraphmodel and how it describes the graph model. http://www.oasis-open.org/committees/download.php/30700/xdi-rdf-graph-model-diagrams-v1.pdf He also updated the XDI RDF Graph Model wiki page with new text descriptionsof each metagraph predicate and references to the diagrams. http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel The main topic of the call will be to review this and discuss how it returnsthe metagraph back to a pure description of the graph with no othersemantics and thus enables the metagraph predicates to be used with anydescription logic: http://en.wikipedia.org/wiki/Description_logic 3) MULTI-PART SPEC DESIGN AND NEXT STEPS WITH THE FIRST WORKING DRAFT Drummond had his questions answered by Mary McRae about how a multi-partspecification should work. See the DITA example: http://docs.oasis-open.org/dita/v1.1/OS/overview/overview.html Given this model, Drummond has updated the specification names on: http://wiki.oasis-open.org/xdi/XdiOneSpecs If there is consensus on this, our next step is to choose a template andbegin the first Working Draft. ---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php