I think a simple rule is missing, normal left
to right resolution rules still apply. The meta-data cross reference is a
sub-segment under the authority to the left. So if presented with this
XRI =sakimura*($v*2.3)*(+email) a
resolver will look for a ($v*2.3) iname under =sakimura. It will then
look for a (+email) iname under
=sakimura*($v*2.3). To me this means that we are looking for version 2.3
under the sakimura authority not look for 2.3 of +email … it is all left
to right.
Note: We have not done any service
end point matching here. (+email) is not a legal service type in the
latest resolution draft. In this example it is just an iname.
- Les
I-Name: =les.chasen
From: Drummond
Reed [mailto:]
Sent: Monday, January 16, 2006
1:54 PM
To: 'Schleiff, Marty'; 'Sakimura,
Nat'; 'Wachob, Gabe';
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
First, this is a great
thread – I encourage all XRI TC members to read it as it gets to the
heart of the revisions being made to XRI Metadata 2.0 Working Draft 08.
Nat: Marty already
answered the first point I was going to make that under the proposed new ABNF
for XRI metadata, language tags are now completely unambiguous because the
identifier being described is *inside*
the cross-reference. So as Marty illustrates, instead of…
=sakimura*chinese_string*($l*za)*japanese_string*($l*ja)*some_string
…you would
have…
=sakimura*($l*za*chinese_string)*($l*ja*japanese_string)*some_string
The same is true for
identifier types. Whereas under XRI Metadata 2.0 Committee Draft 01, if we'd
had $t, we would have had…
@Boeing*($t*oid)*8.4.13.6.72*($t*ces)*some_string
…and it might have
been ambiguous which string was an OID and which was a Case Exact String, under
Working Draft 08 you would have…
@Boeing*($t*oid*8.4.13.6.72)*($t*ces*some_string)
…and it will not be
ambiguous at all.
I was very happy about
that realization, and it produces wonderfully clean ABNF. However it's true
that with $d datetime identifiers and $v version identifiers, the XRI metadata
is only telling you that the cross-reference is a datetime or a version number.
How the datetime or version number cross-reference applies to the XRI as a
whole is up to the identifier authority.
As Marty points out, XRI
authorities do have a clean way to specify in an XRI that a datetime or version
applies to a specific portion of the XRI, and that again would be to use
cross-reference syntax to explicitly group the related identifiers as he
illustrates…
(=sakimura*($d*2002-10-10T11:00:00Z))*(+email)
While this is certainly
valid, I don't think it will prove as useful as simply using datetime and
version cross-references to create namespaces. For example, with…
=sakimura*($d*2002-10-10T11:00:00Z)*(+email)
…it doesn't really
matter whether "($d*2002-10-10T11:00:00Z)"
is interpreted as "describing" "=sakimura" or "(+email)" because the net effect will be exactly the same: you have an
XRI that includes exactly one datetime space that can be compared with any
other XRI with the same datetime space to determine an ordered relationship.
For example, in the following two XRIs, you will know that the first one comes
before the second one in time:
=sakimura*($d*2002-10-10T11:00:00Z)*(+email)
=sakimura*($d*2002-10-10T11:00:01Z)*(+email)
The same is true of
versions – you know unambiguously that the second XRI below is a later
version than the first:
=sakimura*($v*2.3)*(+email)
=sakimura*($v*3.1)*(+email)
I believe that with
datetimes and versions this is all that is necessary, but of course I'm too
close to the subject at this point to see it objectively, so please do point
out other use cases that this approach may not meet.
Best,
=Drummond
From: Schleiff,
Marty [mailto:]
Sent: Monday, January 16, 2006
9:22 AM
To: Sakimura, Nat; Drummond Reed;
Wachob, Gabe;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Hi All,
Here's how I look at it:
Metadata is data that describes data, not objects.
So, "$d" (the
metadata) describes "2002-10-10T11:00:00Z" (the date/time value). And in "($v*2.3)", the
"$v" metadata describes describes "2.3" to let us know it's
a version number.
Here's a thought that I
think should be an XRI foundational principle: An XRI is an identifier/name for
some object. The purpose of XRI is to NAME objects, not DESCRIBE
objects. I admit that many names have descriptive meaning; however, I think
that's just incidental and up to the whims of the naming authority.
Drummond and I figured
out that we often violate this "principle" when we talk about
metadata. For example if we have a document called "pays", we
often say that "($l*fr*pays)" lets us know that pays is a French
document. However, what the metadata REALLY says is that the letters p-a-y-s
constitute a French word, or a word with French pronunciation.
When we include metadata
in an XRI, it doesn't really describe the object. Instead, it just becomes part
of the XRI and becomes part of the object's name.
So, in "=sakimura*(+email)*($d*2002-10-10T11:00:00Z)*(+personal)", there is an object (or namespace) called "=sakimura*(+email)*($d*2002-10-10T11:00:00Z)", and within that namespace there is an object called
"(+personal)".
With language (as with
all metadata) Drummond and I claim the intended "target" of the
metadata is within the same cross reference, which would clarify the
multi-lingual example as: "=sakimura*($l*za*chinese_string)*($l*ja*japanese_string)*some_string".
For the email example
where you would like to interprete it as ("me" at
2002-10-10T11:00:00Z)'s email,we think you would use more cross references to
clarify, resulting in an XRI like: "(=sakimura*($d*2002-10-10T11:00:00Z))*(+email)".
I still feel kinda new to
XRI land, so I hope all my examples actually yield valid XRI syntax.
The point about metadata
that drummond and I still argue about is what to do when some portion of an XRI
is the target for multiple sets of metadata. I don't think we have to worry
about this for $v and $t; it's more of a problem for $l and $t. For
example, if the target of the metadata is both case-exact-string (a type) and
French (a language). Drummond says this is a case for nesting cross references,
as in "($l*fr*($t*ces*pays))". I don't like that because I can't tell
if the "$t" and the "ces" should have French pronunciation,
or just the "pays". Also, I'm struggling to figure out if
"($l*fr*($t*ces*pays))" is equivalent to
"($t*ces*($l*fr*pays))". Instead, I favor adding yetta 'nuther
metadata tag, "$m" for "multi", which would somehow
indicate that multiple metadata clauses describe the same target; however, I
can't yet figure out the ABNF for how to do it. Because I'm losing the
arguement with Drummond, I'd like to hear other's comments (if I were winning
that arguement, I might not risk inviting your possibly contentious
views;-).
;
CISSP
Associate
Technical Fellow - Cyber Identity Specialist
Computing
Security Infrastructure
(425)
957-5667
From: Sakimura,
Nat [mailto:]
Sent: Monday, January 16, 2006
6:37 AM
To: Drummond Reed; Schleiff,
Marty; Wachob, Gabe;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
I sort of
understand the situation. However, IMHO, having unambiguous rule about what
that version or date metadata points has its merit in a way that by just
looking at it, you will be able to tell what that cross reference is pointing
to. i.e., you do not have to worry about whether the date is describing
(+email) or (+personal) in the following example.
=sakimura*(+email)*($d*2002-10-10T11:00:00Z)*(+personal)
Always needing
to ask the authority about which interpretation is right is an overhead for
implementations. Besides, an authority may start mixing up the uses and may
well screw up.
This pain
point become even more accute when we are talking about multilingual XRI.
Think of this:
=sakimura*chinese_string*($l*za)*japanese_string*($l*ja)*some_string
If I had to
ask the authority (in this case =sakimura?) whether the child or parent that
the language metadata describes, then I will not be able even to show the XRI
correctly on screen when I am offline. If I know 'a priori' that the
metadata describes the immediately preceding, then I will be able to show it
without making a query to the authority. Moreover, on the way of resolving the
next authorities from left to right, if I got stuck with the permission
problems, I will be out of luck - I will never know how to represent the above
string on screen.
Besides, is
there a syntax to know which way the metadata is describing?
The reason I
think that the metadata should describe something on the left is because it
will be restricting what precedes. This follows the pattern of restriction from
left to right. e.g.,
=sakimura*(+email)
actually will
be the vector of email addresses that I had during my life.
*($d*2002-10-10T11:00:00Z) constrains it to this particular date. You could
argue that it could have been
=sakimura*($d*2002-10-10T11:00:00Z)*(+email)
and the date
is describing the email. However, I would like to interprete it as
("me" at 2002-10-10T11:00:00Z)'s email. Let me do one more: If the
metadata were to describe something on its right, then to describe
"me" on a particular date, I would have to do:
=*($d*2002-10-10T11:00:00Z)*sakimura
I think this
is not quite right.
Nat
From: Drummond
Reed [mailto:]
Sent: Monday, January 16, 2006
5:26 PM
To: Sakimura, Nat; 'Schleiff,
Marty'; 'Wachob, Gabe';
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Nat, there is no inherent
"problem" with this approach if that is what the XRI authority
intended. What Marty and Dave and I found, however, was that for every use of a
date cross-reference describing its parent node, another example can be created
in which it described its child node.
So we concluded that the
only thing that can be stated unambiguously is that:
1) A $d cross-reference
describes an identifier representing a date (which is contained in the
cross-reference)
2) The XRI authority that
assigns the $d cross-reference is responsible for interpretation of what it
"describes" outside of the cross-reference.
In other words, we don't
need to define in the Metadata spec that a metadata cross-reference describes
the node before it or the node after it, only that it defines a date (or
version, or language, or type) and can be compared with other XRIs that are otherwise
identical except for the same cross-reference.
So let me turn the
question around: do you see anything wrong with this approach?
=Drummond
From: Sakimura,
Nat [mailto:]
Sent: Sunday, January 15, 2006
6:37 PM
To: Drummond Reed; Schleiff,
Marty; Wachob, Gabe;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Sorry, I still do not quite follow, I guess, but my
feeling is that it is very useful if one can determine what the metadata really
describes. For example, for version, it is nice to be able to determine that in
=GabeW*resume*($d*2002-10-10T17:00:00Z)*job
*($d*2002-10-10T17:00:00Z) is
describing =GabeW*resume and not job.
The version metadata in
this case actually describes the immediately preceding segment
"resume". Although it just explains "resume", this in turn
means that it is describing "=GabeW*resume".
What is the problem of
this approach?
Nat
From: Drummond
Reed [mailto:]
Sent: Thursday, January 12, 2006
12:30 PM
To: 'Schleiff, Marty'; 'Wachob,
Gabe';
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Do not listen to that man
behind the giant aluminum curtain at Boeing. Those questions he keeps asking
just happen to have about 30 years of thought and experience behind them and he
has completely resculpted the contour of XRI metadata because he has asked the
hard questions long enough and insisted on clear, clean, even answers with little
(preferably no) ambiguity.
Gabe, here's an answer
your question about the application of the RDF S-P-O pattern (that's
subject-predicate-object for anyone who's not an RDF disciple). As Marty
explained, the solution we realized for making XRI metadata both simple and
unambiguous was by including the subject (the identifier being described) as
part of the cross-reference.
For example, if we wanted
to express that the identifier "pays" was the French word and not the
English word, the S-P-O triple would be:
Subject =
"pays"
Predicate =
"$l"
Object = "fr"
…with the resulting
XRI being…
$l*fr*pays
…which when used as
a cross-reference in the context of another resource might be something
like…
xri://xri.example.com/dictionary/($l*fr*pays)/defintion.html
What threw off our
analysis of the underlying pattern being the S-P-O pattern was the fact that
the very simple XRI metadata cross-references we have been using for quite a
while actually fit this pattern even though they were only two
"levels" deep. Example:
$v*2.0
…which when used in
context (to choose a particular very real example from the XRI Resolution 2.0
spec) would be…
xri://$res*local*($v*2.0)
In this use of XRI
metadata, the identifier "$v" directly describes the identifier
"2.0". In RDF terms, what we realized was that this was just like the
metadata in the following XML snippet:
<strong>car</strong>
If you analyze this tag
from an RDF perspective, what you get is:
Subject = "car"
Predicate = fontstyle
(implicit)
Object =
"strong"
In other words, it's
implicit in the semantics of the tag <strong> that it's a font style. You
could make this much more explicit as follows:
<font style="strong">car</font>
Marty and I realized that
$v and $d both followed this implicit predicate pattern. So "$v*2.0"
from an S-P-O perspective is:
Subject = "2.0"
Predicate = $v
Object = version number
(implicit)
And
"$d*2002-10-10T17:00:00Z" from an S-P-O perspective would be:
Subject =
"2002-10-10T17:00:00Z "
Predicate = $d
Object = XML datetime
(implicit)
Marty then suggested that
$v and $d, besides their "implicit" numeric version and XML datetime
formats, respectively, could also have other formats defined explicitly without
conflicting with the implicit default. Examples:
$v*alpha*b.e.c
Subject =
"b.e.c"
Predicate = $v
Object =
"alpha" (explicit)
$d*year*2005
Subject =
"2005"
Predicate = $d
Object = "year"
(explicit)
So (I realize this is a
very long answer to your question), the S-P-O pattern applies strictly to the
identifier that is the subject of the cross-reference, i.e., the final
subsegment of the cross-reference (ALWAYS).
What it ducks is the
question of what the entire XRI metadata cross-reference describes – if
it does describe anything explicitly. In other words, under the above use of
the S-P-O pattern, the S-P-O only operates within the XRI metadata
cross-reference. The mere inclusion of an XRI metadata cross-reference in an XRI
does not explicitly tell you what it describes.
Marty and I did discuss a
way to make that ambiguous, which again would be by using cross-references. For
example, in your question about whether the date cross-reference in…
=GabeW*resume*($d*2002-10-10T17:00:00Z)*job
...describes your resume
or your job, one easy way to make this unambigous is…
=GabeW*(resume*($d*2002-10-10T17:00:00Z))*job
=GabeW*resume*(($d*2002-10-10T17:00:00Z)*job)
It sure is unambiguous to
me what describes what in these identifiers.
However, other than
suggesting/specifying the use of cross-references when you really want to make
it unambiguous what a XRI metadata cross-reference refers to, I'm in favor of
just tightly defining the XRI metadata cross-reference syntax and letting identifier
authorities use these within other XRIs as needed.
Whatchathink?
=Drummond
From: Schleiff,
Marty [mailto:]
Sent: Wednesday, January 11, 2006
4:57 PM
To: Wachob, Gabe; Drummond Reed;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Hi Gabe (& All),
Now you're asking me
really hard questions. I think you need to understand that when Drummond and I
work together, it's mostly him doing the work. I have three unofficial roles in
the collaboration: 1) repeatedly ask stupid questions about a particular
concept until Drummond gets enough practice answering in various
ways, and can figure out the best way to describe it in a spec; 2) think up
bizarre use cases to test out our ideas; and 3) continually pester him and try
to convince him that there are some places where an xref doesn't make sense.
For good answers, I think we'll have to wait for Drummond to chime in.
I'm apparently guilty of
trying to constrain the specs too much. I don't like the concept of it being up
to the issuer to decide how to interpret the target of the metadata. In and XRI
containing ".../pays/pays/(l*fr)/pays/pays/...", to which part(s)
should the metadata apply? I.e., which part(s) should have French
pronunciation? The ambiguity drove us to putting it into the xref, e.g.,
".../pays/pays/($l*fr*pays)/pays..."
Your "left" /
"right" idea is an interesting approach we hadn't thought of (at
least I hadn't thought of it - maybe Drummond had).
;
CISSP
Associate
Technical Fellow - Cyber Identity Specialist
Computing
Security Infrastructure
(425)
957-5667
From: Wachob,
Gabe [mailto:]
Sent: Wednesday, January 11, 2006
4:29 PM
To: Schleiff, Marty; Drummond
Reed;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Marty-
Are you saying that metadata XREFs should have a way of saying
"the thing identified to the left of me" vs. "the thing
identified to the right of me" ? So, in the pattern of:
xri-metadata = "$"
predicate [ “*” object ] “*” subject
you might have:
=GabeW*resume*($v*left*1.2)
-- indicating version 1.2 of my resume
vs.
=GabeW*resume*($v*right*2002-10-10T17:00:00Z)*job -- indicating my job as of
10/10/02?
I guess I'm confused about the concept of having a *choice* about what the metadata
applies to.. I don't quite understand how/why these metadata xrefs "apply"
to parts of the XRI. In that sense, I guess I'm saying that I don't understand
how the subject is *part* of an XRI. It would seem to me that the subject has
to be explicit if you are to have the Subject-Predicate-Object model.
Can we state succinctly
what it means when such a S-P-O triple appears in an XRI? What inference do we
draw by its mere presence? Isn't it just a convenient way to qualify everything
to the right of the metadata XREF, and nothing more?
-Gabe
From: Schleiff,
Marty [mailto:]
Sent: Wednesday, January 11, 2006
4:19 PM
To: Wachob, Gabe; Drummond Reed;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Hi Gabe (& All),
Drummond and I have
discussed/debated at length how to express the portion of an XRI to which
metadata applies. We determined that the only way to clearly associate metadata
with the intended subject of the metadata is to include the subject and
metadata within the same xref. How metadata associates with portions of
the XRI outside the metadata xref is up to the XRI issuer. This is one of
several concepts for which we're interested in reactions from the rest of the
TC. There are other issues, but rather than point them out, I'll be interested
to see if you recognize them on your own.
; CISSP
Associate
Technical Fellow - Cyber Identity Specialist
Computing
Security Infrastructure
(425)
957-5667
From: Wachob,
Gabe [mailto:]
Sent: Wednesday, January 11, 2006
12:54 PM
To: Drummond Reed;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
I guess I'm partial to
the RDF-mindset, but I'm thinking that it is an odd fit to make that tight a
connection to the S-P-O model since its not clear what the actual *subject* is
in all cases - to wit, isn't the subject the thing outside the metadata
cross-reference? Doesn't the Metadata XREF explicitly describe/refer to something
*outside* the metata XREF?
If we *could* mesh this
with RDF concepts, that'd would be interesting.
Otherwise, I don't have a
strong preference between the other four items. They all seem pretty isomorphic
to me, without having thought about this very deeply.
-Gabe
From: Drummond
Reed [mailto:]
Sent: Wednesday, January 11, 2006
11:45 AM
To:
Subject: [xri] Feedback requested
on terms used in Metadata spec
I'm happy to report that Marty and I, after a series
of in-depth work sessions (abetted by Dave McAlpin when he's been in town),
believe we have wrestled the metadata dragon most of the way to the ground.
The "dragon" is a tighter, more consistent
ABNF for all forms of XRI metadata as well as a much cleaner set of rules about
what it describes.
Without going into all the gory detail, what XRI
Metadata 2.0 Working Draft 08 will recommend is a very simple ABNF for
"tagging" an identifier with XRI metadata, which can then be used as
a cross-reference inside another XRI. The important clarification we will be
making is that this metadata only describes the "subject" identifier
(the identifier being described, to borrow term from RDF). For example, in the
XRI…
xri://xri.example.com/some/filename*($v*2.3)
…the metadata "$v" only describes the
identifier "2.3". It tells you it’s a version number. That's
it. From the identifier above, it would be a pretty obvious conclusion that the
identifier authority intended the cross-reference "($v*2.3)" to
identify a version namespace for the resource identifier by
"filename". However in the following XRI…
xri://xri.example.com/some/filename*($v*2.3)*anotherfile
…it may not be quite as clear – does the
identifier "($v*2.3)" create a version namespace for
"filename" or for "anotherfile"?
The answer is: that's up to the identifier authority
and out of scope for the XRI Metadata spec. The scope of the Metadata spec is
limited to defining well-known semantics and syntax for a limited set of
broadly useful identifier metadata (versions, dates, languages, types, and
annotations).
With that explained, here's what we'd like feedback
on: the semantics of the actual production names used in the ABNF – which
(per our experience with XRI syntax) we'd like to match up with the terms used
in the text of the Metadata spec itself.
Following are four "versions" of the ABNF
that are all identical structurally but different in the production names for
the first two of the three productions in the proposed syntax. (Marty and I
both like the term "subject" for the third component -- the
identifier being described -- since this is consistent with RDF and SAML and
other similar uses.)
We'd just like to know which of these (if any) are
preferred by other members of the TC, since semantics is not something that can
be determined by fiat. Please send a reply email to the list with a comment
about your preference if you have one (or a different suggestion if you feel
something else altogether would work better).
Thanks,
=Drummond and Marty
Example 1 ("tag" wording)
xri-metadata
= "$" metadata-tag [ “*” metadata-tag-value ]
“*” subject
metadata-tag
= ( alpha / xref )
metadata-tag-value
= ( xri-subseg / xref )
subject
= ( xri-subseg / xref )
Example 2 ("attribute" wording)
xri-metadata = "$" attribute [
“*” attribute-value ] “*” subject
attribute = ( alpha /
xref )
attribute-value = ( xri-subseg / xref )
subject = (
xri-subseg / xref )
Example 3 ("property" wording)
xri-metadata = "$" property [
“*” property-value ] “*” subject
property = ( alpha
/ xref )
property-value = ( xri-subseg / xref )
subject = (
xri-subseg / xref )
Example 4 ("RDF" wording)
xri-metadata = "$" predicate [
“*” object ] “*” subject
predicate = ( alpha /
xref )
object
= ( xri-subseg / xref )
subject = (
xri-subseg / xref )
Examples of the five types of XRI metadata:
($l*fr*pays)
($t*ces* john%20henry%20doe)
($v*2.3)
($d*2002-10-10T17:00:00Z)
($-*some.comment.here)
How these examples parse to the ABNF above:
First
production
Second
production
Subject
$l
*fr
*pays
$t
*ces
*john%20henry%20doe
$v
*number (default
– can be omitted)
*2.3
$d
*XMLdatetime (default
– can be omitted)
*2002-10-10T17:00:00Z
$-
*string (default
– can be omitted)
*some.comment.here
