RE: [xri] Feedback requested on terms used in Metadata spec

From
Sakimura, Nat <>
Date
2006-01-16T02:37:08+00:00
ID
Thread
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