Next in thread →
Next in month →
RE: [xri] Feedback requested on terms used in Metadata spec
Hi all,
I am terribly sorry for belated reply.
I still am a bit mixed up, I guess.
Here is my understanding:
(1) $ is a metadata character describing that following
character is
describing the metadata type.
(2) Something like $d is a metadata describing the
string (data) that
follows '*' after it. The
extent that this metadata is effective is
within the cross reference
parens. I.e., ($v*2.3) means that string
'2.3' is actually of
type version.
(3) '($v*2.3)' is significant in resolution and as
treated as opaque string.
If there is nothing that
match the entire identifier, it will be an error.
'($d*2006-01-01T23:45:42Z)'
is significant in resolution and is not
treated as opaque
string, but some computation will be done at the
resolver so that the concrete
identifier for then most current version
of the object is returned.
'($- comment)' is
insignificant in resolution and is ignored.
'($l*fr)' is insignificant in
resolution and is ignored.
Am I right?
Cheers,
Nat
From: Drummond Reed
[mailto:]
Sent: Tuesday, January 17, 2006
5:44 AM
To: 'Chasen, Les'; 'Schleiff, Marty'; Sakimura, Nat;
'Wachob, Gabe';
Subject: RE: [xri] Feedback
requested on terms used in Metadata spec
Les has a good point.
From an XRI resolution standpoint, resolution is always left to right. So I
think it is safe that $d and $v namespaces *always* create a datetime or version
space for the resource identified by the XRI for their immediate
parent.
=Drummond
From: Chasen,
Les [mailto:]
Sent: Monday, January 16, 2006 12:14
PM
To: Drummond Reed;
Schleiff, Marty; Sakimura, Nat; Wachob, Gabe;
Subject: RE: [xri] Feedback requested on
terms used in Metadata spec
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
Next in thread →
Next in month →