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
