|Subject:||Re: [xri] Language expression|
|From:||Drummond Reed (drum...@xdi.org)|
|Date:||Jan 19, 2010 6:36:12 pm|
Such is the challenge of “structured attributes” (or “structured claims” in the Information Card world). Ironically my answer to you here, on the XRI TC list, is going to be couched in my experience in two other forums: at the Information Card Foundation (my day job), and at the XDI TC (my other night job ;-)
First, let me address Scott Cantor’s feedback (from his separate reply to your post):
***** SCOTT’S REPLY *****
My only opinion is that adding information to URLs (especially when you
don't own them in the first place) is a very bad idea.
The reason I agree with Scott is not because I don’t believe in structured identifiers – as you know I very much do. However I believe Scott’s point is that with URLs (technically, http: URIs), the entire identifier space under the authority belongs to that authority.
Now, since the URLs you are talking about in your message are the OpenID AX attribute identifier URLs, I believe what you are suggesting is that the OpenID AX Working Group should adopt an identifier templating specification that can be used to create structured attribute identifiers. I personally believe that solution can work – it’s a half-step to exactly what XRI and XDI are all about. However, two caveats:
1) Based on what I’ve learned about URL templating, no solid standard has been established yet (Eran is the one to ask about this).
2) Based on my experience with XDI (which is essentially an entire data interchange language built from structured identifiers), it can be harder than meets the eye.
Now, I wouldn’t be doing my job as co-chair of this TC if I didn’t point out, with XRI 3.0 Syntax now content-complete ( http://www.oasis-open.org/committees/download.php/35972/xri-syntax-3.0-wd03.pdf), that the OpenID AX group could adopt XRI 3.0 syntax to express its structured identifiers in the “body” of OpenID AX attribute URLs. This is perfectly consistent with XRI 3.0 architecture because it binds XRIs to URLs (or any other supported base URI) to make them absolute URIs. So the OpenID AX WG could both have its cake (URLs) and eat it too (XRIs with standard structure and semantics).
But I’m not going to push that. Overall my advice with regard to this subject is:
1) If you’re going to adopt structured identifiers, make sure you’re adopting it at least using a template language specified by the authority for the namespace in which they will be issued.
2) Keep the template patterns as simple as possible and the structuring semantics as clear as possible
3) Reinvent as few wheels as possible, i.e., reuse existing specs like RFC 4646 for language tags.
2010/1/19 Nat Sakimura <n-sa...@nri.co.jp>
I am discussing the attribute schema URL with Japanese telcos. It is supposed to be usable by not only OpenID but at other places as well.
(We know that there are efforts like PoCo and looking at them.)
One of the issue that we have is how to express the language preference for each item.
For example, "fullname" is expressed as http://axschema.org/namePerson in axschema, but it has no notion of the language nor the character type. So, we do not know if the user would supply Kanji name or Katakana name or Hiragana name or Alphabet name in Japanese. We need a way to express them.
A very simplistic approach is to do something like:
Then, we know that there is a language issue. Unless we know the language, we do not know how to display them. So, more plausible way of expressing them might be:
These are very ad-hoc way of doing it.
I thought XRI TC may have some opinion on them since you have been dealing with $ qualifiers in the past.
Your input is greatly appreciated.
Nat Sakimura (=nat)
-- Nat Sakimura (n-sa...@nri.co.jp) Nomura Research Institute, Ltd. Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php