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: Updated Link Contract Proposal



Updated idea on Link Contracts $if reserved word(s):
   http://openxdi.gluu.info/doku.php?id=linkcontracts

The area where I feel like I'm on shakey ground is on the values of the 
booleans. A new idea is to use the property itself to define its type and 
matching rules. For example:
  "(=!1111+approvedFriendsOfChild/$has/+age!)<(=!1111+approvedFriendsOfChild/+maxAge!)"

thx,

Mike


--------------------------------------------------------------------------------------

Michael Schwartz
Gluu
Founder, CEO
mike@gluu.org
https://www.gluu.org
+1 646-810-8761



On Wed, 6 Jul 2011, Drummond Reed wrote:

> Giovanni, my apologies, the XRI TC spent several years developing canonical
> resolution for XRIs so I am so used to the term that I forgot that not all
> XDI TC members are as familiar with it.
>
> The idea of a canonical identifier is a solution to a common problem: if you
> have a set of 2-or-more XRI synonyms for a resource, how do you know which
> one you can use to identify that resource to another party who may or may
> not have access to the same set of synonyms?
>
> The XRI TC solved this problem by providing semantics in XRDS documents (now
> XRD documents) for specifying which XRI in the set of synonyms was the
> canonical XRI. Then comparisions were always based on the canonical XRI.
>
> This is exactly the architecture proposed in slide #3 of the latest XDI
> Graph Patterns document<http://www.oasis-open.org/committees/download.php/42654/xdi-graph-patterns-2011-06-23.pdf>.
> The $is relational arc is used to express the relationship between any
> non-canonical XRI for an XDI context node and the canonical XRI for the
> context node (the $is arc always points from the non-canonical to the
> canonical XRI).
>
> This is of course different than owl:sameAs semantics, which does not have
> any notion of canonical vs. non-canonical. That's why I'm proposing to use
> $same to express owl:sameAs equivalence relationships in XDI graphs and $is
> to express canonical equivalence relationships in XDI graphs.
>
> We can discuss further on tomorrow's call.
>
> =Drummond
>
> On Wed, Jul 6, 2011 at 1:28 AM, Giovanni Bartolomeo <
> giovanni.bartolomeo@uniroma2.it> wrote:
>
>> Hello Drummond,
>>
>> all your argumentations seem to be based one central notion: "canonical
>> XRI".
>>
>> Could you clarify in more details what a canonical XRI is? (sorry, maybe
>> I'm the only one to require this clarification, however want to be sure that
>> my understanding is correct...)
>>
>> Thanks,
>> Giovanni
>>
>>
>>
>> Def. Quota Drummond Reed <drummond.reed@xdi.org>:
>>
>>  XDI TC Members:
>>>
>>> Having had the long weekend (in the U.S.) to think about it, plus
>>> Giovanni's
>>> email yesterday, I had an insight about defining a predicate for
>>> equivalence/synonymity that has owl:sameAs semantics. This could kill two
>>> current birds with one stone. Here's a summary of my thinking:
>>>
>>> 1) WHY WE SHOULD AVOID MULTIGRAPHS
>>>
>>> First, with regards to the option we discussed last Thursday of the XDI
>>> graph supporting multiple XRI arcs between the same XDI subject and XDI
>>> object -- a directed multigraph <http://en.wikipedia.org/wiki/**
>>> Multigraph <http://en.wikipedia.org/wiki/Multigraph>>.
>>>
>>> As I've pointed out before, this creates problems determining the
>>> canonical
>>> XRI for identifying an XDI context node. But over the weekend I realized
>>> there's a second reason to avoid multigraphs: RDF graphs are not
>>> multigraphs
>>> either. In RDF, you must use an owl:sameAs statement to create an
>>> equivalence statement between two distinct RDF graph nodes. The owl:sameAs
>>> statement is a way to assert that the two nodes represent the same logical
>>> subject, but the two nodes still remain distinct and separate nodes in the
>>> RDF graph. Thus RDF graphs and XDI graphs currently share the same
>>> quality:
>>> every graph node has exactly one arc (one URI) that identifies it.
>>>
>>> With XDI graphs this has the further advantage that *every arc in an XDI
>>> graph corresponds to exactly one XDI statement and vice versa*. This is
>>> not
>>> only conceptually very clean and easy to understand and teach, but it is a
>>> very computation-friendly rule.
>>>
>>> So I would submit that XDI graphs should to follow the same underlying
>>> architecture as RDF graphs, i.e., be simple directed
>>> graphs<http://en.wikipedia.**org/wiki/Graph_%28mathematics%**
>>> 29#Simple_graph<http://en.wikipedia.org/wiki/Graph_%28mathematics%29#Simple_graph>
>>>> and
>>>
>>> not multigraphs.
>>>
>>>
>>> 2) USE $SAME FOR OWL:SAMEAS SEMANTICS
>>>
>>> My second realization was that if we want to be able to express the
>>> owl:sameAs semantics for equivalence, which only expresses general
>>> equivalence and does not include the notion of canonical equivalence, then
>>> we should assign an XRI to have the same semantics as owl:sameAs. To keep
>>> it
>>> simple, I propose that we use $same.
>>>
>>> As a relational arc, a $same assertion of equivalence would NOT be
>>> canonical, i.e., any two XDI subjects could have a $same relational arc
>>> that
>>> asserts that they are equivalent, and this arc could go in either or both
>>> directions between them, i.e., $same would be its own inverse (like $is,
>>> see
>>> below). So we would say:
>>>
>>>  =!1111/$same/=example.name1
>>>  =!1111/$same/=example.name2
>>>  =example.name1/$same/=!1111
>>>  =example.name2/$same/=!1111
>>>
>>>
>>> 3) KEEP $IS FOR BOTH CANONICAL EQUIVALENCE AND ALGORITHMIC INVERSION
>>>
>>> Lastly, because $same solves the RDF-equivalence semantics issue, I
>>> recommend keeping $is for exactly what we are using it for right now,
>>> i.e.:
>>>
>>>   1. By itself, for canonical equivalence (as illustrated in slide #3 of
>>>
>>>   the latest XDI Graph Patterns
>>> PDF<http://www.oasis-open.org/**committees/download.php/42654/**
>>> xdi-graph-patterns-2011-06-23.**pdf<http://www.oasis-open.org/committees/download.php/42654/xdi-graph-patterns-2011-06-23.pdf>
>>>>
>>>   ).
>>>   2. As a prefix, for algorithmic inversion for any other XDI predicate
>>>
>>>   (example: $is$do as shown in slide 9 of the latest XDI Graph
>>> Patterns PDF<http://www.oasis-open.org/**committees/download.php/42654/**
>>> xdi-graph-patterns-2011-06-23.**pdf<http://www.oasis-open.org/committees/download.php/42654/xdi-graph-patterns-2011-06-23.pdf>
>>>>
>>>
>>>   ).
>>>
>>> There are three reasons for this recommendation:
>>>
>>>   1. Since we have a separate $word for owl:sameAs equivalence, $same,
>>>
>>>   there is no longer a conflict with using $is for canonical equivalence
>>> or
>>>   algorithmic inversion or both. The latter are both XDI-only concepts, so
>>> it
>>>   makes sense to use an XDI-defined predicate for them.
>>>   2. The reason for using it for both canonical equivalence and
>>> algorithmic
>>>
>>>   inversion lies in the underlying metagraph model. In short, $is
>>> represents a
>>>   self-referential arc (a loop <http://en.wikipedia.org/wiki/**Graph_loop<http://en.wikipedia.org/wiki/Graph_loop>
>>>> ).
>>>
>>>   Since you can't actually express a loop in a simple directed graph, you
>>> use
>>>   the $is metagraph statement to do it -- that's how we express canonical
>>>   equivalence. When you then put any other XDI graph statement in the
>>> context
>>>   of a parent self-referential arc (loop), you are "turning it back upon
>>>   itself", i.e., expressing the inverse.
>>>   3. $is for inversion reads very well in English. We have seen numerous
>>>
>>>   examples over the past several years. One of the most frequent is using
>>>   $is$a to express supertype, which is the inverse of $a to express
>>> subtype.
>>>   Or in the current link contract proposal, using $is$do to express the
>>>   inverse of $do. But it also works works with virtually any English word.
>>> For
>>>   example, =abraham/+son/=cain has the inverse =cain/$is+son/=abraham.
>>>
>>> =Drummond
>>>
>>>
>>
>>
>> ------------------------------**------------------------------**----
>> Invito da parte dell'Ateneo:
>> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
>> tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
>> codice fiscale: 80213750583 http://5x1000.uniroma2.it
>>
>>
>>
>


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