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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics


Yes, I agree, Markus, "narrowing the selection" should work with both.

=Drummond

On Tue, Apr 20, 2010 at 12:30 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I guess "narrowing the selection" would work both with $has (eg $has+) and with $has$a (eg $has$a+).

Markus


On Tue, Apr 20, 2010 at 5:23 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Markus,

Your message was right  on target about the one downside to the proposal - that it doesn't provide one predicate for parent-subject/child-subject relationships. The greater granularity of individual subsegment predicates is nice when you want that granularity, but it would be really nice if there was a single predicate you could use to query for all child subjects (just like you can use $has to query for all predicates).

So I thought about this overnight and this morning another light bulb hit. I almost laughed out loud at the irony. Let me explain. If you follow the "golden triangle" of XDI metagraph relationships illustrated below, and if $has is dedicated to expressing a subject/predicate relationship, then it becomes clear that to express the subset of those cases where the predicate is also the object, then that subset of $has predicates would be expressed as $has$a. (More below the image.)


Slide1.png


The irony in this is that it is the exact opposite of where we were a year ago, when $has was defined to express subject-parent/subject-child relationships, and $has$a was defined to express subject/predicate relationships.

But it makes so much more sense. $has defines all predicates on a subject. $has$a is the subset of those cases in which the predicate is the object. And what's really nice is that you can repeat the pattern to further narrow the selection too. In other words, if you want all the child + subjects, the predicate would be $has$a+. If you wanted all the $ subjects, it would be $has$a$.

I took my example PDX XDI document and rewrote it using $has and $has$a relationships and it works even better than the delimiter-as-predicate proposal - there are fewer verbs, and it reads very cleanly. I should be ready to post it by tomorrow.

So I modify my earlier proposal to solve the separation of subject/predicate and subject-parent/subject-child relationships by using $has for the former and $has$a for the latter.

=Drummond

On Sun, Apr 18, 2010 at 12:55 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I agree that +a+b and +a/+b don't identify the same graph.

I like the proposed new use of $has and of the +/$/=/@/*/! predicates. This should be simple enough to be understandable even for people new to XDI, which I don't think we can say about some of the previous proposals :)

The term "child" subject is a bit confusing to me, maybe "concatenated subject" or "composite subject" would be better..? Not sure.

The one concern I have is that to efficiently support the +/$/=/@/*/! predicates, the underlying XDI stores would have to become a bit smarter, because the granularity of XDI operations now reaches into XRI subsegment level, whereas before XDI stores only needed to deal on a subject/predicate/object level. So I think an XDI store would have the following options to support e.g. a $get on +a/+ :
- Enumerate all subjects and return the ones that start with +a+ (inefficient if there are lots of subjects)
- Maintain 6 separate indices for every subsegment, so that the subjects starting with +a+ can be efficiently retrieved (indices have to be created whenever a subject is added)
- Maybe choose to not support this all if efficiency is a top priority

Markus

On Sat, Apr 17, 2010 at 4:58 PM, Drummond Reed <drummond.reed@xdi.org> wrote:
Per my action item from Thursday's telecon, following is more about my
analysis and proposal for solving the "$has semantics problem" once
and for all.

*** ANALYSIS ***
My first conclusion, on which I think we all agree, is that while +a+b
might imply +a/+b and vice versa, that does not mean that: a) they
have the same semantics, or b) that they identify the same XDI graph.
Indeed, since one is an XDI subject and the other adds an XDI
predicate, by definition they cannot identify the same XDI graph.

To illustrate in English, most English verbs can be made into nouns by
putting them in their infinitive form (“to be”, “to run”, “to shout”).
But “run” and “to run”, while clearly linked semantically, do not have
the same meaning. They cannot be interchanged with each other.

Thus my second conclusion is that none of the three XDI graph examples
we were discussing on our telecon two weeks ago were in fact
equivalent. They were each different XDI graphs that had similar but
not identical semantics.

My third conclusion is that this means that we do in fact need clearly
distinguished ways of semantically and syntactically of expressing
that an XDI subject (e.g., +a) : 1) has a child subject (e.g., +a+b),
and 2) has a predicate (e.g., +a/+b).

My fourth conclusion was that this is the problem we have been
struggling with for the last year: by using $has (with or without
variants like $has$a) to express both parent subject/child subject
relationships (+a+b) and subject/predicate relationships (+a/+b), we
have wrapped ourself in a classic Gordian knot.

*** PROPOSAL ***

Once the problem was framed this way, it became much easier (for me
anyway) to see that a clean solution would be to dedicate the $has
predicate to only one semantic – either the parent subject/child
subject relationship or the subject/predicate relationship. Of those
two options, I strongly prefer dedicating the $has verb to expressing
the subject/predicate relationship (+a/+b), since this is the simpler
and more intuitive to understand, and mirrors the semantics of the $a
predicate, which expresses predicate/object relationships.

If $has is dedicated to that expression, then we simply need a
different predicate (or set of predicates) to express parent
subject/child subject relationships.

For that, an obvious answer is to use XRI delimiters as predicates.
This is intuitive since it is syntactically required to have a
delimiter between XRI subsegments, and each of the six XRI delimiters
(not counting parentheses for cross-references) has its own
XRI-defined "semantics", e.g., * means reassignable identifier, !
means persistent identifiers, etc.

So to summarize using +a and +b notation:

+a/$has/+b      <==>    +a/+b
+a/+/+b <==>    +a+b
+a/$/$b <==>    +a$b
+a/=/=b <==>    +a=b
+a/@/@b <==>    +a@b
+a/*/*b <==>    +a*b
+a/!/!b <==>    +a!b
+a/()/(b)       <==>    +a(b)

Semantically, it would still be true that +a+b/$is$a/+b (and the
inverse that +b/$a/+a+b). And while +a+b would imply that +a/+b is
valid, and vice versa, the existence of one in an XDI graph would not
imply the existence of the other.

So, if =example wanted to do a query to determine if +a+b and +a/+b
both existed in an XDI graph, it would be:
=example
       $get
               /
                       +a
                               $has
                                       +b
                               +
                                       +b

I have been trying out this proposal in sample XDI documents for the
past week and it seems to work very well. Please consider and
experiment with it and post your thoughts. We'll put it on the agenda
for next week's telecon.

=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







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