The GCS Delimiter proposal (http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter)
goes into great depth about why XDI needs the level of precision provided by both
GCS delimiters and cross-references. Cross-reference syntax (syntactically
encapsulating identifiers by enclosing them in parentheses) is essential for
being able to put any identifier (a URI or an XRI) in another context. For
example, in my last message I showed how it could be used to indicate –
anywhere within an XRI – that a URI represented a resource in either a
personal or an organizational context:
...=(http://example.com/data/uri)...
...@(http://example.com/data/uri)...
This isn’t something we want to give
up.
At the same time, the extreme semantic precision
of XDI RDF (which is really to say the extreme semantic precision of any RDF
vocabulary compared to natural language vocabularies like English) also needs
to be able to express that a resource in one XDI global context can be referred
to directly within another XDI global context. That means the ability to
express any combination of the following XRIs:
=example
@example
+example
$example
E.g.:
@example+example
+example$example
@example+example$example
@example=example
=example@example
In XDI RDF, all of these represent very
precise RDF statements about the relationship between two resources that can be
independently identified in a global context. Adding parens, stars, or bangs
would change those XDI RDF statements as explained at http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter.
In conclusion, Les, I don’t think there
is any satisfactory answer to your question when you are looking at XRI syntax
from a natural language standpoint. To a human being, =
and =drummond*(@microsoft.com) don’t look that different. However to a
machine, they are different identifiers, and when you need the precision of a
semantic language like XDI RDF, this difference becomes critically important.
On that score, for TC members who are not
intimately familiar with RDF, I did a blog post about a new book called Semantic
Web for the Working Ontologist:
http://www.equalsdrummond.name/?p=164
I recommend it very highly because it does
such a good job at explaining to reasonably web-savvy technologists how RDF
really works and what kinds of problems in machine-understandable semantics it can
solve.
=Drummond
From: Chasen, Les
[mailto:]
Sent: Monday, November 24, 2008
11:36 AM
To: ;
Cc: ;
;
Subject: Re: [xri] GCS Characters
I continue to struggle with why we need two ways to put a
global xri in the context of another xri. = and
=drummond*(@microsoft.com) seem to do the same thing. If the later is less than
desirable let's drop ()'s in xri.
Besides that confusion there is the issue steve raises.
--------------------------
http://xri.net/=les.chasen
From: Drummond Reed
To:
'OASIS XRI TC'
Cc:
'John Bradley' ; 'Victor Grey' ;
Chasen, Les; 'David Orchard'
Sent:
Mon Nov 24 14:07:53 2008
Subject: RE: [xri] GCS Characters
First, just to address some clarification
questions in this thread, the proposal under discussion, called GCS Delimiter,
is posted at:
http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter
The accompanying ABNF that implements this
proposal is at:
http://wiki.oasis-open.org/xri/XriThree/SyntaxAbnf
As described there in more detail, the
proposal is that in XRI 3.0, all GCS characters (=, @, +, $) are treated in XRI
syntax as delimiters just like * and ! are in XRI 2.0.
Per the ABNF, both =
and @microsoft.com=drummond would parse into two subsegments. =
would parse into:
1) =drummond
2) @microsoft.com
@microsoft.com=drummond would parse into:
1) @microsoft.com
2) =drummond
=drummond+phone+home would parse into:
1) =drummond
2) +phone
3) +home
In XRI resolution, each of these would produce
its own XRD. I don’t know why John thinks this is strange – an XRD
can describe any resource, and certainly my phone collection is a resource, and
my home phone is a resource.
=Drummond
From: John Bradley
[mailto:]
Sent: Monday, November 24, 2008
10:47 AM
To: Victor Grey
Cc: Chasen, Les; Drummond Reed;
OASIS XRI TC; David Orchard
Subject: Re: [xri] GCS Characters
Well thats a can of worms:)
I think in Drummonds proposal + and $ also get to have XRD.
In the first segment the only place those
symbols formerly known as GCS would have
there conventional meaning is if they are attached to the
first sub segment.
If they are the leading character of any other subsegment they would be
treated as * and the =, +, $ are only inferences to the global
concept.
Remember I am the one opposed to the change unless there is a good
reason. So take any pro things I say with a grain of salt.
The thing is that under that they will be treated as sub segments by
the authority server, so what gets passed?
For =
the first subsegment is =drummond what is the second that get passed to
=drummonds's authority service?
*@microsoft.com
@microsoft.com
*(@microsoft.com)
microsoft.com
So would =drummond*microsoft.com produce the same XRD as =?
Could go ether way depending on how we define resolution.
Yes having =drummond+phone have its own XRD seems sort of funky to me
as well.
John B.
On 24-Nov-08, at 10:23 AM, Victor Grey wrote:
The confusion with email
addresses, social, technical or otherwise, is not the only problematic aspect
of the @ GCS character.
XMPP addresses take the form of username@host/optional/path. The username part
(known as a JID or Jabber Identifier) has only a very few disallowed
characters, including whitespace and control chars and : / " ' and of
course @.
The = and @ GCS characters both denote a reassignable identifier for an entity,
as opposed to + and $ which identify terms.
@ and = also serve as configurable aliases for an XRD discovery function $f(x),
for example $dns(xri.net).
If we didn't have to deal with @, we could define a very simple and expandable
set of transformations for XRD discovery:
Given an abstract ID =drummond with $f(x) configured as $dns(xri.net), here are
some possible discovery transformations:
https
https://xri.net/=drummond
http
http://xri.net/=drummond
xmpp
=
mailto = (I think there is an
attractive case for an XRI aware mailserver that can resolve the XRI and make
service selections based on the XRD and x-headers.)
Other as yet to be invented communication protocols could all be accommodated
with this simple and very abstract spec. We shouldn't let the current
kerfluffle with the W3C derail us into thinking that http is the whole universe
of possibility.
Since @ and = behave exactly the same way, and =ids --can-- be used as
community roots already, I've never really understood any strong necessity for
the overloading of the entity identifier to distinguish individuals from
collections of individuals, and the disregard of the fact that there could be
other kinds of entities besides those two.
So at the risk of making everyone's head explode, I'm proposing that we
deprecate the @ GCS character in XRI 3, and make = the single GCS character
that denotes a reassignable identifier for any kind of entity. An entity would
be defined as anything that can have an XRD.
=vg
