OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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

Subject: POWDER on track to become proposed recommendation

What are the group's thoughts on relevance of POWDER (http://www.w3.org/2007/powder/) to XRI and XDI work? The POWDER group started as far as I can tell a little over a year ago, but they say they are currently in process of transitioning to a proposed recommendation.  If this becomes a PR it might have an impact on XRI/XDI adoption/voting, which is why I wanted to hear what your thoughts are.
An example of a POWDER document is:
<powder xmlns="http://www.w3.org/2007/05/powder#" 

    <issuedby src="http://authority.example.org/company.rdf#me" />






From: Barnhill, William [USA]
Sent: Fri 1/16/2009 9:52 AM
To: Drummond Reed; 'OASIS - XDI TC'
Cc: 'Nick Nicholas'
Subject: [xdi] RE: More on $has predicate (was RE: [xdi] Agenda: XDI TC Telecon Thursday 1-2PM PT 2009-01-15)

This is just initial thoughts as I'll look at the updated diagrams/pages this weekend.
For XDI graph with no metagraph statements and metagraph, why don't be just paraphrase RDF?
XDI Graph - An XDI graph is the union of a possibly empty A-Graph containing XRIs that make statements about a set of individuals and/or concepts, with  a possibly empty T-Graph containing XRIs that make statements about the statements contained within the A-Graph or statements about the graph.
You said that +x/$has/+y does in fact translate into two base graph statements:  +x/+y/+x+y and    +x+y

But what do you mean by translate? Do you mean (a) that the presence of the first in the graph implies the other two; (b) that the presence of the other two in the graph implies the first, or (c) both?
I agree with (c) for the +x+y part, but am having trouble with the other.
If you say (c) for both then +x/+y/+x+y <=> +x+y. So the subject +ball, predicate +color has the object +ball+color as well as +red? That would mean that a query of +ball/+color would return two answers: +ball+color and +color*red? If +ball+color and +color*red are synonyms then a query can have something similar to a DISTINCT clause that eliminates synonymous XRIs.  By synonyms I mean the symmetric difference of the set of XDI nodes addressed by +x+y and the set of XDI nodes addressed by +color*red.  That would present the following problems I think:
.. There may be other things that are colored red (e.g. +z/+y/+red)
..  If the predicate +y does not have a maxCardinality of 1 then there may be other colors for +x (e.g. +x/+y/+green)
But for the above reasons I'm a lot more comfortable with the RDF/OWL syntax I gave in the previous email as the RDF analog to +x+y, which interprets +x/$has/+y as a property restriction on the class of things +x. If you kind of combined what I'm understanding your approach to be with my take one possibility might be:
+ball+color <=> [+ball/+color/$$A ^ $$A/$a/+ball+color ^ +ball+color/$a/+color]
This incorporates  +x/$has/+y infers the statement +x+y/$is$a/+y  as well as your other statements but separates things from all being about individuals to some of the implied statements being about class membership.
What do you think?
One thing that's missing from the above merged proposal is the $is. I don't have any reason other than that for me it violates the principle of least surprise, but I really do not like $is as the inverse operator, even less so than I liked $a.  To me a different set of metagraph predicates to include in the final set would be:
1) $implies such that $$X/$implies/$$Y is true (ie returns a non-null set of addressed XDI nodes) iff the symmetric difference of the set of nodes addressed by $$X and the set of nodes addressed by $$Y is the empty set.
2) $is such that $$X/$is/$$Y is true iff [$$X/$implies/$$Y ^ $$Y/$implies/$$X]
3) $has .. been over this one, see earlier email with RDF analog. My take is that this (and any predicate) should have a semantic meaning or adopters will assign their own different meanings and things will get screwy fast. My take is also that semantic meaning of $has is a property restriction on the class of things $$X
4) $a  would imply set membership (subClassOf for concept classes as sub and obj, rdf:type for individual as sub and class as obj, and the implication that the class has a single member that is the individual for a class as sub and individual as obj)
5) $inv s.t. the set of nodes addressed by $$X/$inv$$Y/$$Z is equivalent to the set addressed by $$Z/$$Y/$$X.. Whether $inv$$Y or $$Y$inv is TBD AFAIK
6) binary set operators: $and, $nand, $or, $xor, $nor, $nxor, $diff, $symdiff, $union, $intersection
7) $not .. std negation from set membership exclusion pov
While not predicates I'd also suggest the following:
The first two are from First Order Logic. The last allows fuzzy logic treatment of predicates.
The mechanisms for combining the above (e.g. $is$a, $has$a, $is$not, etc) are and what they mean in a way that's expressible in an RDF syntax analog warrant furthe discussion.

From: Drummond Reed
Sent: Fri 1/16/2009 2:05 AM
To: 'Barnhill, William [USA]'; 'OASIS - XDI TC'
Cc: 'Nick Nicholas'
Subject: More on $has predicate (was RE: [xdi] Agenda: XDI TC Telecon Thursday 1-2PM PT 2009-01-15)

I had a very productive 1-on-1 call with Nick Nicholas after the XRI TC telecon today, where we went into the metagraph model diagrams even more deeply. Several key conclusions came out of it. Nick is doing his own writeup, which may have even more detail, but in this email I wanted to highlight two key conclusions that directly address the questions Bill raised this morning in his message below. Also, I posted a few minor edits in a V2 of the metagraph/graph diagrams at:




Note: I’m noticing how much we need to refer to the NON-metagraph, but talking about a non-metagraph hurts my head, I propose the term we use to talk about “the XDI RDF graph that does not include any metagraph statements” is “base graph”, simply because something can only be meta if it has a base to work against. Please post if you prefer another term.



The first conclusion is that the V1 diagrams are, in fact, correct. In other words, the metagraph statement +x/$has/+y does in fact translate into two base graph statements:





Both of them are reflected in the diagram:



This is a different conclusion than I gave in my first response to Bill earlier today when I said that +x/$has/+y was a way of asserting that the target of the outgoing arc +y originating from +x was a blank node. Saying the object is in fact +x+y is a better solution for two reasons:


            1) There is no need to invoke the concept of a blank node (and all its baggage).

            2) There is no need to specify that a $has statement means there can be only one arc +y originating from +x.


Instead what +x/$has/+y describes is that:


            There is an exactly one arc +y originating from +x terminating in the object identified as +x+y.


This is consistent with:


            a) RDF, because there is exactly one RDF statement with the same subject, predicate, and object (multiples of that same statement are ignored).

            b) Our use of $has in the metagraph to define XDI addresses in the base graph: $has identifies the singleton arcs in the base graph that serve this addressing role. No more, no less.


Well, actually, a little more. There is one other statement that can be derived from a $has statement – but it really is just a logical conclusion that fundamentally falls out of the logical structure of the metagraph itself. It is the following inference:


            Every metagraph statement +x/$has/+y infers the statement +x+y/$is$a/+y.


Kudos to Nick for recognizing this inference. The funny thing is that it’s plain as the nose on your face if you study the metagraph/base graph diagrams. Diagram from section 4A/4B of the PDF, which is the diagram of the metagraph statements +x/$a/+y and +y/$is$a/+x, shows:



Because both $a and $is$a statements are assertions about an object having an incoming arc, it follows that any metagraph statement that specifies an outgoing arc terminating in an object is also a statement that the object has an incoming arc. Thus all four of the following statements infer the other three:







This jibes with the English semantics if we substitute real words for x and y:







So the English phrase “dog collar” only means that the identified object is-a collar, not that it is-a dog. However it is not just any collar, it is-a collar in the context of being something a dog has.


This finally addresses the question Bill raised in his message below In the RDF he provided, his assumption was that for the metagraph statement +x+y, the RDF statements were:


            1) +x+y is a +x

            2) +x has the property +y.


What Nick and I concluded is that the RDF statements are:


            1) +x+y is a +y

            2) +x has the property +y whose object is +x+y


Bill, we also agreed that since you have more RDF experience than we, it may be easier for you to express the RDF then we can.


Hope this helps.




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" />



            <owl:onProperty rdf:resource=http://plus.xri.net/y />

            <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>



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" />



from the explicit graph statements expressed in:


<rdf:Description rdf:about="http://equals.xri.net/Bill.Barnhill"  >

    <rdf:type rdf:resource="&owl;Thing" />




In XRI terms the following implicit XRI in the XDI graph would be determined by an XDI reasoner:


from the following explicit XRIs in the graph (playing fast and loose with name spaces here):




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?




From: Drummond Reed
Sent: Thu 1/15/2009 4:48 AM
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 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)
    Dial In Number: 571-434-5750
    Conference ID: 5474
We will start with a tour from Markus of his latest XDI RDF utility:
Based on insights from Monday's aborted XRI/XDI editor's telecon (which
turned into a long informal XDI telecon) and Tuesday's special XRI Syntax
3.0 telecon (which also ended out as a long XDI discussion), Drummond had a
key revelation about the metagraph model.
He has uploaded a PDF with a new set of diagrams illustrating the metagraph
model and how it describes the graph model.
He also updated the XDI RDF Graph Model wiki page with new text descriptions
of each metagraph predicate and references to the diagrams.
The main topic of the call will be to review this and discuss how it returns
the metagraph back to a pure description of the graph with no other
semantics and thus enables the metagraph predicates to be used with any
description logic:
Drummond had his questions answered by Mary McRae about how a multi-part
specification should work. See the DITA example:
Given this model, Drummond has updated the specification names on:
If there is consensus on this, our next step is to choose a template and
begin the first Working Draft. 
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:

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