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
