Re: [DG-Concordia] No discussion topics - no call
For the attribute exchange interoperability, the attribute URL discussion is very important. Also, how to indicate the desired language and script is important. At Id-plat.org, we have done some discussion around those. Namely, * Use fragment to express the language-Script-COUNTRY in ISO format. For example, http://axschema.org/namePerson#ja-Hani-JP means "namePerson (fullname)" in japanese-Kanji-of_Japan. Also, we have compiled some of the highly demanded attributes. I am attaching them in MS Word format. Regards, Nat (2010/06/29 7:28), Paul Madsen wrote:
I encourage people to bring forward new discussion topics.
Until such time, there is little value in having a call
Paul _______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
-- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute, Ltd. Tel:+81-3-6274-1412 Fax:+81-3-6274-1547 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 信されたメールを削除していただきますようお願い致します。 PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
Thank you Nat-san, can you give some background on Id-plat.org? What can Concordia provide beyond that activity as a forum for discussion? Paul On 7/5/2010 7:40 AM, Nat Sakimura wrote:
For the attribute exchange interoperability, the attribute URL discussion is very important. Also, how to indicate the desired language and script is important. At Id-plat.org, we have done some discussion around those.
Namely,
* Use fragment to express the language-Script-COUNTRY in ISO format. For example,
http://axschema.org/namePerson#ja-Hani-JP
means "namePerson (fullname)" in japanese-Kanji-of_Japan.
Also, we have compiled some of the highly demanded attributes.
I am attaching them in MS Word format.
Regards,
Nat
(2010/06/29 7:28), Paul Madsen wrote:
I encourage people to bring forward new discussion topics.
Until such time, there is little value in having a call
Paul _______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
id-plat.org, "Identity Platform Federation Forum" is an industry forum for telcos and ICT companies in Japan. All of NTT docomo, NTT Communications, KDDI and Softbank are member of the forum. NRI is doing the secretariat of it. Last year, subsidized by the ministry of internal affairs and communication, id-plat has done a prototyping study. Figuring out the interoperable attribute schema among them was one of the topic of the study. =nat (2010/07/05 21:35), Paul Madsen wrote:
Thank you Nat-san, can you give some background on Id-plat.org?
What can Concordia provide beyond that activity as a forum for discussion?
Paul
On 7/5/2010 7:40 AM, Nat Sakimura wrote:
For the attribute exchange interoperability, the attribute URL discussion is very important. Also, how to indicate the desired language and script is important. At Id-plat.org, we have done some discussion around those.
Namely,
* Use fragment to express the language-Script-COUNTRY in ISO format. For example,
http://axschema.org/namePerson#ja-Hani-JP
means "namePerson (fullname)" in japanese-Kanji-of_Japan.
Also, we have compiled some of the highly demanded attributes.
I am attaching them in MS Word format.
Regards,
Nat
(2010/06/29 7:28), Paul Madsen wrote:
I encourage people to bring forward new discussion topics.
Until such time, there is little value in having a call
Paul _______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
-- Nat Sakimura このメールには、本来の宛先の方のみに限定された機密情報が含まれている場 合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメー ルを削除してくださいますようお願い申し上げます。 PLEASE READ：This e-mail is confidential and intended for the named re cipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.
For the attribute exchange interoperability, the attribute URL discussion is very important. Also, how to indicate the desired language and script is important. At Id-plat.org, we have done some discussion around those.
Namely,
* Use fragment to express the language-Script-COUNTRY in ISO format. For example,
Overloading identifiers like that is a disaster waiting to happen, IMHO. -- Scott
Why would it be a disaster? Could you elaborate more? =nat (2010/07/06 4:22), Scott Cantor wrote:
For the attribute exchange interoperability, the attribute URL discussion is very important. Also, how to indicate the desired language and script is important. At Id-plat.org, we have done some discussion around those.
Namely,
* Use fragment to express the language-Script-COUNTRY in ISO format. For example,
Overloading identifiers like that is a disaster waiting to happen, IMHO.
-- Scott
-- Nat Sakimura このメールには、本来の宛先の方のみに限定された機密情報が含まれている場 合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメー ルを削除してくださいますようお願い申し上げます。 PLEASE READ：This e-mail is confidential and intended for the named re cipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.
Why would it be a disaster? Could you elaborate more?
You're turning an opaque identifier into a semantic key that eventually will get overloaded to handle whatever kinds of variability people come up with. This happens in databases all the time, and it leads to maintenance problems. Your solution also doesn't work with existing standards for the representation of attributes, which include the use of opaque URNs to identify attributes that have unambigious names. The problem here is the protocol, so that's where the solution needs to be. Your protocol needs to be fixed to handle the extensibility you need in negotiating information release. -- Scott
So, the point seems to be whether the attribute identifiers should be opaque or not. I am not so sure where the example like OpenSocial or OpenGraph or Poco are using opaque identifier. In my example, an OpenSocial API Call like: GET /rest/people/34KJDCSKJN2HHF0DW20394/@self?fields=name,gender&format=xml HTTP/1.1 HOST api.example.org Authorization: hh5s93j4hdidpola can be trivially converted to GET /rest/people/34KJDCSKJN2HHF0DW20394/@self?fields=name%23ja_Hani_JP,gender&format=xml HTTP/1.1 HOST api.example.org Authorization: hh5s93j4hdidpola for Japanese Kanji name instead of (probably) English name. Same kind of procedures can be applied to OpenGraph, OpenID AX, etc. Are you suggesting that we need to fix those protocols instead? Well, true. It may be a quick hack, but it seems to be somewhat more realistic than fixing all those protocols. (2010/07/06 22:08), Scott Cantor wrote:
Why would it be a disaster? Could you elaborate more?
You're turning an opaque identifier into a semantic key that eventually will get overloaded to handle whatever kinds of variability people come up with. This happens in databases all the time, and it leads to maintenance problems.
Your solution also doesn't work with existing standards for the representation of attributes, which include the use of opaque URNs to identify attributes that have unambigious names.
The problem here is the protocol, so that's where the solution needs to be. Your protocol needs to be fixed to handle the extensibility you need in negotiating information release.
-- Scott
-- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute, Ltd. Tel:+81-3-6274-1412 Fax:+81-3-6274-1547 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。 PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
So, the point seems to be whether the attribute identifiers should be opaque or not.
I'm arguing that it's pretty basic data modeling that all identifiers should be treated as opaque rather than as semantic keys.
I am not so sure where the example like OpenSocial or OpenGraph or Poco are using opaque identifier.
Web 2.0 and Computer Science 101 don't seem to be very closely associated, I've noticed, but your example seems to show parameters influencing the request, not overloaded identifiers (though the identifiers I see there don't seem to be suitable to a distributed environment).
can be trivially converted to
GET /rest/people/34KJDCSKJN2HHF0DW20394/@self?fields=name%23ja_Hani_JP,gender&fo rmat=xml HTTP/1.1 HOST api.example.org Authorization: hh5s93j4hdidpola for Japanese Kanji name instead of (probably) English name.
One problem seems to be with using a flat string or name/value set to make structured data requests. If all you have is a string, then everything has to get stuffed inside the string.
Same kind of procedures can be applied to OpenGraph, OpenID AX, etc.
Are you suggesting that we need to fix those protocols instead?
I'm simply pointing out that it's a bad approach and that it will bite people eventually.
Well, true. It may be a quick hack, but it seems to be somewhat more realistic than fixing all those protocols.
Hack away. -- Scott
Nat-san, thank you for the background on Id-plat.org. While the topic would seem to warrant discussion on a call tomorrow, the regular time (1.30 pm EST) wont work for Nat-san (unless he happens to be travelling?) Do others have views (and would wish to present them on a call)? Paul On 06/07/2010 10:24 PM, Scott Cantor wrote:
So, the point seems to be whether the attribute identifiers should be opaque or not. I'm arguing that it's pretty basic data modeling that all identifiers should be treated as opaque rather than as semantic keys.
I am not so sure where the example like OpenSocial or OpenGraph or Poco are using opaque identifier. Web 2.0 and Computer Science 101 don't seem to be very closely associated, I've noticed, but your example seems to show parameters influencing the request, not overloaded identifiers (though the identifiers I see there don't seem to be suitable to a distributed environment).
can be trivially converted to
GET /rest/people/34KJDCSKJN2HHF0DW20394/@self?fields=name%23ja_Hani_JP,gender&fo rmat=xml HTTP/1.1 HOST api.example.org Authorization: hh5s93j4hdidpola for Japanese Kanji name instead of (probably) English name. One problem seems to be with using a flat string or name/value set to make structured data requests. If all you have is a string, then everything has to get stuffed inside the string.
Same kind of procedures can be applied to OpenGraph, OpenID AX, etc.
Are you suggesting that we need to fix those protocols instead? I'm simply pointing out that it's a bad approach and that it will bite people eventually.
Well, true. It may be a quick hack, but it seems to be somewhat more realistic than fixing all those protocols. Hack away.
-- Scott
_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2986 - Release Date: 07/06/10 14:36:00
While the topic would seem to warrant discussion on a call tomorrow, the regular time (1.30 pm EST) wont work for Nat-san (unless he happens to be travelling?)
Do others have views (and would wish to present them on a call)?
I think I've said my peace, but I probably won't be available in any case. -- Scott
lets keep any discussion on list for now then On 12/07/2010 4:09 PM, Scott Cantor wrote:
While the topic would seem to warrant discussion on a call tomorrow, the regular time (1.30 pm EST) wont work for Nat-san (unless he happens to be travelling?)
Do others have views (and would wish to present them on a call)? I think I've said my peace, but I probably won't be available in any case.
-- Scott
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2998 - Release Date: 07/12/10 02:36:00
participants (3)
-
Nat Sakimura -
Paul Madsen -
Scott Cantor