Nat,
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.
-- Scott
******
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.
=Drummond
2010/1/19 Nat Sakimura <>
Hi.
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:
http://axschema.org/namePerson/kanji
http://axschema.org/namePerson/hiragana
http://axschema.org/namePerson/alphabet
etc.
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:
http://axschema.org/namePerson/kanji/ja_JP
etc. (Or http://axschema.org/namePerson/ja_JP/kanji, but since we could
set the default language, it is probably better to be
http://axschema.org/namePerson/kanji/ja_JP).
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.
Best,
Nat Sakimura (=nat)
--
Nat Sakimura ()
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
