Gabe,
Just to clarify, everything you say in
your message is correct except the last item. While we in Metadata CD 01 we
said that $l tags could be used as a "processing instruction" to
"switch the language of the XRI to another language", that was in
fact what was causing quite a bit of the ambiguity issues that Marty started
bringing up (and which eventually led to him becoming a co-editor of Metadata!)
Under the proposed ABNF for Working Draft 08,
all $ tags only describe what's in the cross-reference that contains them. So
if you want to say that an XRI consisting of multiple subsegments is in a spec
language, you either need to "tag" the whole XRI as a cross-reference,
or tag each of the subsegments with $l tag. The choice would depend on the
context and resolution requirements – obviously the two different
approaches would resolve quite differently.
Example using "xri://@a*b*c/d"
and French:
Tagging the whole XRI:
xri://($l*fr*(@a*b*c/d))
Tagging the individual subsegments:
xri://@*($l*fr*a)*($l*fr*b)*($l*fr*c)/($l*fr*d)
The latter may be more verbose than using
$l as a "switch", but by eliminating all the potential ambiguity
issues, it's much cleaner. I'm happy with the tradeoff (especially considering
that such an XRI is almost certainly going to be produced by a machine based on
a much more intuitive UI).
=Drummond
From: Wachob, Gabe
[mailto:]
Sent: Monday, January 16, 2006
3:11 PM
To: Drummond Reed; Sakimura, Nat;
Schleiff, Marty;
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
I think this makes sense to me and is what
I had understood XREFs to be early on. I had heard you talking at some point
about the metadata describing "the" identifier and I assumed you
meant the entire XRI - it sounds like you've settled on the understanding (that
I originally had) that the XREF doesn't really describe anything outside the
XREF (though, in the case of language, it can be thought of as a
"processing instruction" to switch the language of the XRI to another
language).
-Gabe
From: Drummond
Reed [mailto:]
Sent: Monday, January 16, 2006
12:26 AM
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
