NTTドコモ、OSにGoogleの「Android」を採用へ

ここのGIGAZINEの記事
NTTドコモが携帯電話の基本設計を抜本的に変更、OSにGoogleの「Android」を採用へ
http://gigazine.net/index.php?/news/comments/20080324_docomo_android/
によると(以下斜体は上記サイトより引用）


NTTドコモが携帯電話端末の基本設計を抜本的に変更し、基本ソフトとしてGoogleが開発したLinuxベースの携帯電話向けOS「Andoroid」を採用するそうです。


そーいえば、「Android」のシリーズ、途中でしたね。
今度再開しますね・・・

オブジェクト指向と、RDBとセマンティックWebの関係をまとめてみる

　前に、JavaのクラスとOWLについて書いたので、ここで、

　・オブジェクト指向における、クラスとオブジェクトと、
　・RDBにおけるテーブルとレコード、ER図におけるエンティティと
　・セマンティックWebにおけるRDFとOWL

の関係について、まとめてみたいと思います。

---

■クラス－テーブル－エンティティ－OWL

　オブジェクト指向で定義するクラスと、
　ER図のエンティティが対応し、
　これと、セマンティックWebのOWLのクラスが
　だいたい対応する。
　RDFスキーマのクラスも、そうともいえる。

　そして、ER図のエンティティと、RDBのテーブルが、
　だいたい対応する。

　ただし、クラスの場合、メソッドがあるけど、ER図などにはないとか、

　ER図のエンティティにおいては、というかRDBではサブクラスという
　概念はなく、そのかわり、（consist ofと同じように）
　外部キー（参照キー）との関係で示し、
　１対多のとき、１のほうが親になるとか、

　RDBのテーブルには、エンティティ以外に、関係だけを表した、
　連結テーブルというのがあるとか

いった、違いはある。だから、「だいたい」

---

■そうだとすると、

　そうだとすると、それぞれを具現化した、

オブジェクト指向のオブジェクトは、
RDBのレコードに相当する。

このレコードを、RDFの主語としたとき、

オブジェクト指向の属性は、
RDBの項目（フィールド名）に相当し、
RDFの述語に相当する。

そして

オブジェクト指向の属性値は、
RDBの項目の値に相当し、
RDFの目的語に相当する。

っていったら、厳密に考えている人には怒られそうだけど、
だいたい、そんなかんじ。。

JavaとJavaScriptとOWLにおける、「型のかわりのクラス」によるチェックの話

　昨日、、「型のかわりのクラス」を使って、値のチェックの自動化とか、階層化の話を、Javaをベースにして書きました。結局まとめると、

・型をクラスで表現する。継承を利用して、階層化することもある

・値のチェックのメソッドをどのクラスでもint validate(String val)とし、
　階層化されている場合、super.validation(val);を呼び出し、親でのチェックもする

・範囲など、チェックに必要なものは、「型のかわりのクラス」の属性として
　定義し、チェック前までに設定する。設定値がなけれ（デフォルトなら）チェックしない。

こうすると、チェックが自動化、階層化できるため、追加チェックの手間が省けたり、テスト漏れが防止できそうという話を書いた。

---

　でも、サーバーならそれでいいが、クライアントの場合は？
　JavaScriptだと、クラスの概念がない。

　しょうがないので、

・クラス名_validation(val)を関数名とし、そこでチェックし、
・クラス名_属性名で、範囲など、チェックに必要な項目とし、
・継承する場合、クラス名_validation関数の中で、親のクラス名_validation関数
　を呼び出す

という形になるのかしら・・・

---

　で、ここで、ついでに言うと、OWLの場合、はなしはかんたんなんだよね。

　OWLのクラスがこの「型のかわりのクラス」に相当し、
　親は subClassOfで設定すればいい。
　範囲などは、プロパティ制約で記述することになる。

　ってことで、Javaの「型のかわりのクラス」は、OWLの定義そのものと言える。
　ってことは、業務用語をセマンティク的に（OWLで）定義すると、そこからJavaの「型のかわりのクラス」を定義でき、自動的にチェックモジュールを生成できる可能性がある。ってことだね。