[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Copy of the chat
Drummond Reed (=drummond) added =Bill.Barnhill to this chat
4:10 PM
Drummond Reed (=drummond)
4:11 PM
there, Bill?
=Bill.Barnhill
4:11 PM
Yes, thanks
Drummond Reed (=drummond) set topic to " XDI TC Chat Room "
4:11 PM
Drummond Reed (=drummond)
4:22 PM
So, here's an example: if I have =drummond/+cat, then does that imply =drummond+cat
4:24 PM
=drummond/+cat/=drummond*hobbes, and =drummond/+cat/=drummond*stormy
4:24 PM
=drummond+cat
4:24 PM
=drummond+cat
4:25 PM
=drummond+cat/+color/+brown
Giovanni Bartolomeo
4:26 PM
=drummond+cat identifies the set
4:27 PM
=drummond+cat=drummond*hobbes, this identifies a specific member
Drummond Reed (=drummond)
4:28 PM
=drummond/+cat/*hobbes
4:28 PM
=drummond+cat*hobbes
4:30 PM
=drummond*hobbes
$is
*hobbes
4:30 PM
*hobbes
$is
=drummond*hobbes
4:31 PM
=drummond/+cat/*hobbes infers =drummond+cat*hobbes
Giovanni Bartolomeo
4:31 PM
yes
Drummond Reed (=drummond)
4:32 PM
+x/+y/+z infers that the set exists +x+y+z
Giovanni Bartolomeo
4:32 PM
+x+y+z can be both a set
4:32 PM
but also a member of the set +x+y
=Bill.Barnhill
4:32 PM
And my question is does =Drummond/+cat/*hobbes infer =drummond/+cat/=Drummond*hobbes?
Drummond Reed (=drummond)
4:35 PM
=drummond/+cat/*hobbes MIGHT infer =drummond/+cat/=drummond+cat*hobbes
=Bill.Barnhill
4:35 PM
To put it another way, if *hobbes is relative is the base xri to which it is relative automatically the subject of the statement or the document XRI, or are they the same? Ie is every document the statements describing a single subject, or contexts within that subject?
Drummond Reed (=drummond)
4:35 PM
I need to think bout it more
Giovanni Bartolomeo
4:36 PM
I like much more this form =drummond/+cat/*hobbes, than this one: =drummond/+cat/=drummond+cat*hobbes
Drummond Reed (=drummond)
4:39 PM
Again, just to clarify, are we sayin that the XDI statement +x/+y/+z infers the XDI subject +x+y+z
4:40 PM
+x/+y/+z infers BOTH +x+y and +x+y+z
4:40 PM
Okay, so what is inferred by +x+y+z+k ?
=Bill.Barnhill
4:41 PM
My thought would be its (+x+y+z)+k..agree with starting with slash form though
Drummond Reed (=drummond)
4:42 PM
what seems clean that this infers +x+y/+z/+k AND +x+y+z/+k
4:43 PM
+x+y INFERS that you have +x/+y
Giovanni Bartolomeo
4:43 PM
we should start from +x/+y
=Bill.Barnhill
4:44 PM
So +x+y+z => +x/+y/+z, and+x/+y/+z/+k => infers based on the context rules that +k is a predicate of subject +x/+y/+z, right?
Giovanni Bartolomeo
4:44 PM
+x/+y/+z/+k ???
4:45 PM
shoudn't it be +x/+y//+z/+k
Drummond Reed (=drummond)
4:45 PM
+x/+y//+z/+k
Giovanni Bartolomeo
4:45 PM
=markus/+$get//=drummond/+name
4:46 PM
=markus/$get//=drummond/+name
4:46 PM
(without +)
Drummond Reed (=drummond)
4:47 PM
set/member-identifier/member
4:49 PM
When we say +x/+y , and then we say +x+y, we are saying that +x+y is a identfier of all objects of the XRI RDF statement +x/+y
4:49 PM
so +x+y is an identifier of a set
4:50 PM
is +x by itself also an identifier of a set?
Giovanni Bartolomeo
4:50 PM
in my view each subject can be both
4:50 PM
a set and a member
=Bill.Barnhill
4:51 PM
So our consensus at this point can be described in the following way, so I can make sure my head is straight,: XDI XRI's of the form Subject represent the set of relationships going out from S; the form S+P is the set of relationships of type +P; where relationship is a 2-tuple of (type, object}
Giovanni Bartolomeo
4:55 PM
so if you query for +S+P
4:55 PM
what you should get?
Drummond Reed (=drummond)
4:55 PM
So what Bill is saying is that if you do a query on =drummond, you will get back the graph root on =drummond, but if you did a query on =drummond+email, you would get back a graph rooted on =drummond/+email
=Bill.Barnhill
4:55 PM
I would say the XDI graph rooted in +S that is filtered so that there are no arcs out of +S that are not +P
Drummond Reed (=drummond)
4:56 PM
Okay, let me ask this question -- this is important! - are we saying that =drummond+email identifies the same set as =drummond/+email ???
Giovanni Bartolomeo
4:56 PM
no
Drummond Reed (=drummond)
4:56 PM
okay, what's the precise difference?
Giovanni Bartolomeo
4:56 PM
well I think that
4:57 PM
if you query
4:57 PM
=drummond+email
4:57 PM
you'll get all statements with subject =drummond+email
Drummond Reed (=drummond)
4:57 PM
I agree with that
Giovanni Bartolomeo
4:57 PM
e.g.
4:57 PM
=drummond+email/$is$a/+email
Drummond Reed (=drummond)
4:57 PM
the question I'm asking is what Bill is saying - is that graph defined to be the same as the graph of all objects that satisfy =drummond/+email ?
=Bill.Barnhill
5:00 PM
=drummond+email/$is$a/+email => (=drummond/+email)/$is$a/+email
Giovanni Bartolomeo
5:01 PM
+x+y+z
5:02 PM
(=drummond/+email)/$is$a/+email
5:04 PM
we do not need at all +x+y, x+y+z
Drummond Reed (=drummond)
5:07 PM
+drummond+email+home+preferred ==> (=drummond/+email//+home/+preferred)
=Bill.Barnhill
5:08 PM
What about ((=drummond/+email)/+home)/$is$a/+email ?
Drummond Reed (=drummond)
5:09 PM
so Bill, that would be saying ((=drummond/+email)/home) ==> +drummond+email+home ?
5:09 PM
In that case, +x+y+z does NOT mean +x/+y/+z, but ONLY +x+y/+z
=Bill.Barnhill
5:09 PM
The other option is (=drummond/(+email+home))/$is$a/+email
Drummond Reed (=drummond)
5:11 PM
+x+y+z+k ==> (((+x/+y)/+z)/+k)
5:13 PM
=drummond+home+email
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thu 4/30/2009 3:31 AM
To: 'Giovanni Bartolomeo'; xdi@lists.oasis-open.org
Subject: [xdi] Revisiting $has and $has$a per Giovanni's proposal
[Note: I numbered the sections of this email so that we can discuss them on
the Thursday 2009-04-30 XDI TC telecon.]
Giovanni,
This has been a long thread - one running for several months now - but the
good news is that I think your proposal and this last round of discussion
has finally made me understand the reasons for wanting to avoid the need for
+x/$has/+y to infer that +x/+y/+x+y.
Even better news is that you have convinced me that this is no longer a
problem. In other words, +x/$has/+y only needs to infer the following XDI
RDF statements:
#1: +x/$has/+y INFERS:
+y/$is$has/+x
+x+y/$is$a/+y
+y/$a/+x+y
+x+y
+x/+y
The corollary is also true, i.e.:
#1A: +x+y INFERS
+x/$has/+y
+y/$is$has/+x
+x+y/$is$a/+y
+y/$a/+x+y
+x/+y
The reason I had such a mental block around this, i.e., that +x/$has/+y must
infer +x/+y/+x+y, is that I was intepreting the XDI metagraph model
literally, i.e., that a $has statement must describe a literal arc between
+x and +x+y. But your definition of a $has statement does not require a
literal arc. +x/$has/+y can simply be defined to mean the set of all XDI RDF
nodes that are the object of +x/+y (and thus members of the set +x+y).
With this new definition, we still have all the XDI RDF addressing
properties of $has, without the RDF semantics that you were objecting to -
and which I now agree were overloading $has beyond what it needed.
**************
So now let's turn to $has$a. If $has defines a new SET, $has$a defines only
A MEMBER OF THAT SET. So +x/$has$a/+y asserts that +y is a valid property on
the subject +x. But it does not identify a new set, only that there may be
members of such a set. By contrast, +x/$has/+y identifies the set of all
members of +x/+y, which is why it produces the new XDI RDF address of that
set, +x+y. Thus:
#2: +x/$has$a/+y INFERS:
+x/+y
+y/$is$has$a/+x
#2A: +x/+y INFERS:
+x/$has$a/+y
+y/$is$has$a/+x
**************
Next, I have been fascinated by your suggestion that the XDI RDF node that
is the object of +x/+y/+z can be referred to as +x+y+z. If this is true,
then:
#3: +x+y+z INFERS:
+x/+y/+z
+x+y/$has/+z
+z/$is$has/+x+y
QUESTION Q1: Do you agree?
QUESTION Q2: Does the XDI RDF statement +x/+y/+z infer both +x+y and +x+y+z?
QUESTION Q3: Does the XDI RDF statement +x+y+z+k infer all of the following:
+x+y+z/$has/+k
+x+y+z/+k
+x+y/+z/+k
This should make for an excellent discussion on tomorrow's call.
=Drummond
_____
From: Giovanni Bartolomeo [mailto:giovanni.bartolomeo@uniroma2.it]
Sent: Friday, April 17, 2009 3:42 AM
To: Drummond Reed
Cc: xdi@lists.oasis-open.org
Subject: [xdi] RE: XDI RDF addressing alternatives? (was RE: Minutes: XDI
TCTelecon Thursday 1-2PM PT 2009-04-02)
Hello Drummond,
yes, that's more or less my proposal. Some comments are below, the main
point being that I'm wondering if, using this addressing procedure, maybe we
can avoid the pattern +x/+y/+x+y.
As you know, this pattern sounds a bit strange to me, as it requires changes
in RDF semantics (
http://lists.oasis-open.org/archives/xdi/200904/msg00006.html
<http://lists.oasis-open.org/archives/xdi/200904/msg00006.html> ); maybe I'm
still not able to understand why it is needed: are there reasons (which I'm
still missing) why we need +x+y be pointed by the +y arc outgoing from +x?
Couldn't we simply assume that +x+y exists if +x/+y/... is in the graph?
My other comments and questions below are marked in bold and prefixed by
"G>" for a more convenient reading.
Thank you very much,
Giovanni
At 01.34 12/04/2009, Drummond Reed wrote:
Giovanni,
First, thank you very much for this explanation. I now understand how you
would create a new subject based on an existing subject. In fact, let me
test my understanding by restating all this as an algorithm. What you are
proposing is:
Every XDI RDF statement +x/+y/+z infers two additional XDI subjects:
1) +x+y
2) +x+y+z
The first one, +x+y, is the address of a single node in the XDI RDF graph
that is the target of exactly one outgoing arc +y whose source is the XDI
RDF subject +x. However I believe what you are saying is that this new
subject, _as a node in the graph_, represents the set of all possible
targets of an outgoing arc +x from the source node +x.
Is that right?
G> Well, I'm just assuming that two additional nodes may be defined and are
may be used in the graph as any others, i.e. to create new statements in
which they may appear as subjects. I'm still missing why we really need +x+y
to be pointed by the +y arc outgoing from +x..
The second one, +x+y+z, is also the address of a single node in the XDI RDF
graph. This one is the target of exactly one outgoing arc +z whose source is
the XDI RDF subject +x+y above. However I believe what you are saying is
that this new subject, _as a node in the graph_, represents the member +z of
the set represented by +x+y as defined above.
Is that right?
G> good point! Yes, +x+y+z in a way "is a" +z, but note that it's the
"particular +z" put in the context of +x+y. I've not much worked on this,
however, what I've thought, is that +x+y+z gives you more information than
+z; (do you remember my mail on @golf-club+member=drummond? I know Nick is
not liking this,
http://lists.oasis-open.org/archives/xdi/200903/msg00006.html, but, I've
found it more attractive than qualifying attributes, as it seems to me to
not breaking the narrowing pattern suggested by Bill
@golf-club+member=drummond+id instead of =drummond@golf-club+member+id);
however, I think that we can discuss pros and cons of this approach in a
further thread if needed.
Lastly, what you are saying is that the same way it has always been true in
XDI RDF, this pattern is recursive to any depth. In other words, the
following algorithm would also be true:
Every XDI RDF statement +x+y+z/+d/+e infers two additional XDI
subjects:
1) +x+y+z+d
2) +x+y+z+d+e
Once again, like all XDI RDF subjects, both of these represent a single node
in the XDI RDF graph. However the first one, +x+y+z+d, specifically
represents the set of all possible targets of an outgoing arc +d from the
source node +x+y+z.
And the second one, +x+y+z+d+e, represents the member +e of the set
represented by +x+y+z+d as defined above.
Is that right?
G> yes, apart from the comments I've already expressed in the lines above.
Lastly, although there is a clear set/member recursive pattern here (just
like the subject/predicate//subject/predicate recursive pattern to XDI
addressing as it crosses subcontexts), it actually still works even in at
"odd" intervals. In other words, the following algorithm would also be true:
Every XDI RDF statement +x+y/+z/+d infers two additional XDI
subjects:
1) +x+y+z
2) +x+y+z+d
Once again, like all XDI RDF subjects, both of these represent a single node
in the XDI RDF graph. However the first one, +x+y+z, specifically represents
the member +z of the set represented by +x+y as defined above, while the
second one, +x+y+z+d, specifically represents the set of all possible
targets of an outgoing arc +d from the source node +x+y+z.
Is that right?
G> Well, as +x+y is there, I think that there should be somewhere some
statement +x/+y/+k. Now, +x+y refers to that particular property +y (which
"is a +y"), that is in the context of +x. +x+y/+z/+d is saying something
about *this* property. In terms of sets I simply think that +x+y+z+d is a
member of +x+y+z and +z is a member of +x+y. Note that a member can be
itself a set, similar to Bill's original idea ("any individual is a class as
well").
I want to confirm all this with you because this is a truly fascinating new
way of looking at XDI RDF addressing. Whatsmore, I believe it's completely
consistent with exactly what Bill has been saying about XDI RDF simply being
a way of expressing sets and set membership (which I find very attractive).
Bill, is that right?
=Drummond
At 01.34 12/04/2009, Drummond Reed wrote:
Giovanni,
First, thank you very much for this explanation. I now understand how you
would create a new subject based on an existing subject. In fact, let me
test my understanding by restating all this as an algorithm. What you are
proposing is:
Every XDI RDF statement +x/+y/+z infers two additional XDI subjects:
1) +x+y
2) +x+y+z
The first one, +x+y, is the address of a single node in the XDI RDF graph
that is the target of exactly one outgoing arc +y whose source is the XDI
RDF subject +x. However I believe what you are saying is that this new
subject, _as a node in the graph_, represents the set of all possible
targets of an outgoing arc +x from the source node +x.
Is that right?
The second one, +x+y+z, is also the address of a single node in the XDI RDF
graph. This one is the target of exactly one outgoing arc +z whose source is
the XDI RDF subject +x+y above. However I believe what you are saying is
that this new subject, _as a node in the graph_, represents the member +z of
the set represented by +x+y as defined above.
Is that right?
Lastly, what you are saying is that the same way it has always been true in
XDI RDF, this pattern is recursive to any depth. In other words, the
following algorithm would also be true:
Every XDI RDF statement +x+y+z/+d/+e infers two additional XDI
subjects:
1) +x+y+z+d
2) +x+y+z+d+e
Once again, like all XDI RDF subjects, both of these represent a single node
in the XDI RDF graph. However the first one, +x+y+z+d, specifically
represents the set of all possible targets of an outgoing arc +d from the
source node +x+y+z.
And the second one, +x+y+z+d+e, represents the member +e of the set
represented by +x+y+z+d as defined above.
Is that right?
Lastly, although there is a clear set/member recursive pattern here (just
like the subject/predicate//subject/predicate recursive pattern to XDI
addressing as it crosses subcontexts), it actually still works even in at
"odd" intervals. In other words, the following algorithm would also be true:
Every XDI RDF statement +x+y/+z/+d infers two additional XDI
subjects:
1) +x+y+z
2) +x+y+z+d
Once again, like all XDI RDF subjects, both of these represent a single node
in the XDI RDF graph. However the first one, +x+y+z, specifically represents
the member +z of the set represented by +x+y as defined above, while the
second one, +x+y+z+d, specifically represents the set of all possible
targets of an outgoing arc +d from the source node +x+y+z.
Is that right?
I want to confirm all this with you because this is a truly fascinating new
way of looking at XDI RDF addressing. Whatsmore, I believe it's completely
consistent with exactly what Bill has been saying about XDI RDF simply being
a way of expressing sets and set membership (which I find very attractive).
Bill, is that right?
=Drummond
> -----Original Message-----
> From: Giovanni Bartolomeo [ mailto:giovanni.bartolomeo@uniroma2.it
<mailto:giovanni.bartolomeo@uniroma2.it> ]
> Sent: Thursday, April 09, 2009 2:17 AM
> To: Drummond Reed
> Cc: xdi@lists.oasis-open.org
> Subject: Re: XDI RDF addressing alternatives? (was RE: Minutes: XDI
> TCTelecon Thursday 1-2PM PT 2009-04-02)
>
> Hello Drummond,
>
> Thanks for your mail. A clarification to your first concern: note that
> X3 is only the serialization format it is used to define new subjects,
> and it does not replace the graph. As I wrote:
>
> ...Using these compound identifiers, it is possible to *introduce in
> the XDI/RDF graph* five new nodes: @example.org+employee
> @example.org+ceo @example.org+employee=j.doe
> @example.org+employee=m.smith @example.org+ceo=r.walker which are not
> part of the original graph, but are useful to make entailments on the
> graph itself (metamodel)...
>
> This means that the new nodes *are* actually new subjects in the
> graph, and they can appear as roots in the tree, when you make
> assertions about them. For example, you can have
>
> @example.org+employee=m.smith
> +mail
> ( mailto:m.smith@example.org <mailto:m.smith@example.org>
)
>
> thus you have two new nodes:
>
> @example.org+employee=m.smith+mail
> @example.org+employee=m.smith+mail( mailto:m.smith@example.org
<mailto:m.smith@example.org> )
>
> I've thought a bit about your second concern ("addressing capability
> of the XDI RDF graph is not something that can be expressed in
> conventional RDF"). Well, I'm doing my best to investigate this and to
> try to remain inside RDF as much as possible.
> Of course if we will find that something cannot really be really
> addressed, then it will make sense to shift to another model, but,
> this should be justified and supported by evidences. Otherwise we risk
> to reinvent things that already exist (and work!), and we risk our
> work to be not accepted by the scientific community (my biggest
> concern).
>
> Kind Regards,
> Giovanni
>
> At 08.58 09/04/2009, Drummond Reed wrote:
> Giovanni,
>
> Thanks for making this posting. In reading through "A Different Proposal"
> at
> the end, I am trying but have not yet been able to fully understand the
> proposal. It appears that you are proposing that for the same X3 graph
> rooted on the one XDI RDF subject, you are proposing that +x/+y addresses
> one part of that graph (rooted on the +x subject) and +x+y addresses
> another
> part of the same graph still rooted on the +x subject.
>
> That seems to destroy the extensiblity model of the XDI RDF graph. You
> can't
> actually create a new subject. As I understand the model you have written
> up, you can't go beyond three levels, i.e., you can talk about +x, +x+y,
> and
> +x+y+z. But what do you do about +x+y+z+j+k?
>
> The $has verb in the proposed metagraph model in
> http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel is not limited to 2 or
> 3
> levels deep. You can extend and create new XDI RDF subjects, predicates,
> or
> objects to any depth.
>
> The more I think about this topic, the more I believe that the addressing
> capability of the XDI RDF graph is not something that can be expressed in
> conventional RDF. It simply can't be done. It's like trying to express a
> three-dimensional space in two dimensions. We are adding the dimension of
> addressability to RDF graphs. It results in identifiers being combined
> into
> new identifiers. RDF graphs have no such notion. I can't see any way
> around
> it.
>
> Thoughts? (We'll just have to continue the conversation in email this week
> since I can't attend the XDI TC call tomorrow.)
>
> =Drummond
>
> > -----Original Message-----
> > From: Giovanni Bartolomeo [ <mailto:giovanni.bartolomeo@uniroma2.it>
mailto:giovanni.bartolomeo@uniroma2.it]
> > Sent: Wednesday, April 08, 2009 5:23 AM
> > To: xdi@lists.oasis-open.org
> > Subject: RE: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2009-04-02
> >
> > Hello,
> >
> > After our call of last week, I've updated today the XDIMetamodel page:
> > http://wiki.oasis-open.org/xdi/XdiMetamodel
> >
> > Kind Regards,
> > Giovanni
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]