The Web Ontology Language (OWL)の翻訳(暫定版)              
	RDF compatible
		Peter F. Patel-Schneider
		Bell Labs Research
		(4 January 2002)

出展： http://lists.w3.org/Archives/Public/www-webont-wg/2002Jan/att-0061/01-swol.text

1. はじめに

 本資料は、DAML+OILの改訂版、一時的にthe Web Ontology Language (OWL)と呼ぶ、の簡潔な定義である。
  
 OWLのDAML+OILからの基本的な変更点は、以下の３つである。
 
(1)　OWLの意味は、model theory for RDFとコンシステントである。
(2)　OWLの構文は、the XQuery 1.0 and XPath 2.0　Data Model (データモデルも含む)を用いる。
(3)　データ型の問い扱いを単純にする。

 意味の変更の背景にある基本的なアイデアは、サブクラスのような意味論の観点から扱うべきコンスト
ラクトを構文としてもつRDFアプローチを採用するだけでなく、解釈(interpretations)における関係
(relationships)を明確にすることにある。しかしながら、意味的な矛盾を引き起すような言語全体の
拡張は避けなければならない。そこで、私は、意味的な矛盾が存在しないことを確信できるようにする
という観点から、解釈における関係を明確にできるコンストラクトの数を制限した。

　構文の変更の背景にある基本的なアイデアは、XQuery　processingを利用することである。

2. データ型

　データ型付スキーマ(datatyping scheme)は、データ型DTの集まり(collection)である。

　DTの各々のデータ型dに対して、４つのコンポーネントがある。
	U(d), データ型に対する(for)URI
	L(d), データ型に対する字句空間(lexical space)
	V(d), データ型に対する値空間(value　space)
	LV(d) : L(d) -> V(d), データ型に対する字句から値への写像

　データ型付スキーマが与えられると、
　　　let L = union over d in DT of L(d), 字句値(lexical value)
			       V = union over d in DT of V(d), データ値(data values)
			       LV = union over d in DT of LV(d)

  このデータ型付けの方法は、整数のようなプリミテイィブなデータ型の集まりがあり、
そして、これらのデータ型の各々の値空間への,LVの値域の制限が関数的(functional)であ
るときにうまくいく。

　この条件を満たさないデータ型が存在する場合でも、例えば、XML Schema union データ型
がそうであるが 、OWLの型理論が、字句から値への写像の結果を制限するだけで、実際の写像を
制限するわけではないことを理解している限りは、大きな(severe)問題にはならない。

　上記は、プロパティの値域は、整数のユニオンの文字列であって、10進数文字の並び(sequences)
を整数にするわけでないことをいっている。しかしながら、いかなる構文タグも持たないような8進
整数のように、プリミテイィブなデータ型に対して字句から値への異なった写像をもつようなデータ
型が存在する場合には、大きな問題になる。

 　構文はXQuery Data Modelsなので、XQueryの標準的な実装を用いることにより、
XML　Schemaのデータ型のほとんどすべてを提供できるようになる。より単純なデータ付けスキーマ
が望まれる場合には、XMLSchemaのビルトインのデータ型が、容易に実装可能な候補といえる。
また、上記の定義を満たす他のデータ型付けスキーマを用いることももちろん可能である。
　
　実際のデータ付スキーマを変更する場合は別にして、すべてのテキストノーﾄﾞをタイプ付けする
ことを要求することもまた可能である。これは、構文と意味を明らかなほどに単純にしているわけ
ではないが、実装を単純にしているかもしれない。また、タイプ付けされないテキストのノード
の扱いを修正することも可能にしている。すわわち、タイプ付けされないテキストのノードの外延
(denotation)が、全ての他のデータ型と異なっておりかつ共通部分を持たない(Disjoint)ような特
別のテキストデータ型の値空間とすることを可能にしている。

3. 構文

　ここで入力として用いられるデータモデルノードを生成するプロセスは、この資料で
扱う内容の範囲外である。しかしながら、一つないし複数のXML文書と共に始まり、
XMLパーシングやXML　Schemaの妥当性検証を経た後、一つないし複数のデータモデル文書
を生成するような通常の生成方法が期待される。

　これらの文書が解析されることで(analyzed)、どのような他のXML文書が必要であるかや、一つな
いし複数の別のパージング、妥当性検証、そして解析が潜在的に要求されているかが決定される。
結局、文書ノードのようなすべての無関係な情報は、取り除かれる。前処理の最後の結果は、OWL知
識ベース(KB)であり、そのKBは、各々がそのルートとして要素ノードをもつようなデータモデル断片
の順序付けられていない集まりである。

　OWL KB中のノードの集合をKとする。

注意： この資料を通じて、データモデルノードは、位置をもった引数付のコンクリートなデータ型と
して扱う。これは、実際にどのように定義されるかという問題を扱うことなく、構文を簡単に説明す
るためである。

　OWLの構文は、これらのノードの上で定義される。唯一の興味ありかつ関係のあるノードは、
ELEMENTノード、ATTRIBUTEノード、そしてTEXTノードである。ELEMENTノードは、名前、属性、子供、
そしてオプショナルな単純型とタイプ付けられた値をもつ。ATTRIBUTEノードは、名前、テキスト値、
そして、オプショナルな単純型とタイプ付けられた値をもつ。TEXTノードは、テキスト値をもつ。
各々の非ルートノードは、 |parent|と示される暗黙の親をもつ。ノード自身は、|self|と示される。
各々のノードは、また、資格付名称Q(qualified names)に対する展開写像(expansion mapping)を
もち、rdf:IDのような展開されていない資格付名称を、{http://www.w3.org/1999/02/22-rdf-syntax-ns,ID}の
ような展開された資格付名称に変換する(turn)ことができる。展開された資格付名称は、Nとする。

注意： 値の並び(sequences of values)の扱いに関しては、確信をもった考えがないので、
  　　現状では、それらを許さないものとする。この点は、今後の検討課題である。

 　不幸なことに、XMLには必要な構文のコンストラクトが欠けており、かつ、非RDF部分の構文は、
予約された単語とは区別されなければならない。これらの予約された単語を使うような構文のコン
ストラクトは、しばしばRDFのコンストラクトのように見えるので、文法を曖昧にしてしまう。形式的
に定められるわけではないが、記述(description)を含むプロダクションは、記述を含まないプロダ
クションよりも優先することとする。また、RDFの構文的な属性(rdf:ID, rdf:about, and rdf:resource)は、
その他すべてのプロダクションよりも優先することとする。

　OWLにおける実際の構文の構成は、充足の章における意味的な条件と共に定義される。

4. 解釈

  OWLのデータ型付スキーマDT上の解釈I(interpretaion I over a datatyping scheme DT)は、単純な
RDFSの解釈を一般化したものであり、以下のものから構成されている。 
　　R, nonempty 		the domain of resources, disjoint from V
　　P <= R, nonempty		properties
　　C <= R, nonempty		classes	      
　　EXT : P -> 2^(Rx(RuV))	property extensions
　　CEXT : C -> 2^(RuV)	　　　　class extensions
　　S : N -> R		　　　　mapping from names to denotation

　以下の条件が、解釈によって満たされなければならない。

4.1 RDFからの条件

 これらの条件は、RDF model theoryからほとんど直接に定まる。

R1  CEXT(S(rdf:Property))  =   P
R2  S(rdf:type)            in  P
R3  for x in R  x in CEXT(y)  iff   in EXT(S(rdf:type))


　rdf:typeは、データ値ではなく、リソース上のCEXTのみと一緒に並ぶ(lines up)ので、データ値は、
rdf:typeの領域(domain)の中にあることはできないことに注意せよ。
　
4.2 RDFSからの条件 

 これらの条件は、RDF model theoryからほとんど直接に定まる。

S1  CEXT(S(rdfs:Resource))  =  R
S2  CEXT(S(rdfs:Class))	    =  C
S3  CEXT(S(rdfs:Literal))   =  V

S4  C\DT contains S(rdfs:Resource), S(rdf:Property), 
		  S(rdfs:Class), S(rdfs:Literal)
S5  P contains S(rdfs:subClassOf), S(rdfs:subPropertyOf)
	       S(rdfs:domain), S(rdfs:range)
S6  EXT(S(rdfs:subClassOf)) contains < S(rdfs:Class), S(rdfs:Resource) >,
				     < S(rdfs:Property), S(rdfs:Resource) >
S7  EXT(S(rdfs:domain)) contains  < S(rdf:type), S(rdfs:Resource) >
				  < S(rdfs:subClassOf), S(rdfs:Class) >
				  < S(rdfs:subPropertyOf), S(rdfs:Property) >
				  < S(rdfs:domain), S(rdfs:Property) >
				  < S(rdfs:range), S(rdfs:Property) >
S8  EXT(S(rdfs:range))  contains  < S(rdf:type), S(rdfs:Class) >
				  < S(rdfs:subClassOf), S(rdfs:Class) >
				  < S(rdfs:subPropertyOf), S(rdfs:Property) >
				  < S(rdfs:domain), S(rdfs:Class) >
				  < S(rdfs:range), S(rdfs:Class) >

S9   in EXT(S(rdfs:subClassOf))       implies   CEXT(x) <= CEXT(y)
S10  in EXT(IS(rdfs:subPropertyOf))   implies   EXT(r)  <= EXT(s)

S11 if  in EXT(p) and  in EXT(S(rdfs:domain)) then x in CEXT(c)
S12 if  in EXT(p) and  in EXT(S(rdfs:range))  then y in CEXT(c)

4.3 データ型からの条件

D1  DT <= C
D2  S(Ud) = d   for d in DT
D3  S(swol:Datatype)    in   C\DT
D4  CEXT(S(swol:Datatype)) = DT
D5  for d in DT    CEXT(d) = Vd

4.4 OWLからの条件

W1  C\DT contains S(swol:Class)
		  S(swol:ObjectProperty), S(swol:DatatypeProperty),
		  S(swol:UniqueProperty), S(swol:UnambiguousProperty)
		  S(swol:TransitiveProperty)
W2  P contains S(swol:sameClassAs), S(swol:disjointWith),
	       S(swol:samePropertyAs),
	       S(swol:sameIndividualAs), S(swol:differentIndividualFrom)
W3  EXT(S(rdfs:subClassOf) contains 
		
		
		
		
		
		
W4  EXT(S(rdfs:subPropertyOf) contains
		
		
W5  EXT(S(rdfs:domain)) contains  
		,
		
		
		
		
W6  EXT(S(rdfs:range))  contains  
		,
		
		
		
		

W7  x in CEXT(S(swol:Class)) 		    =>  x in C and CEXT(x) <= R 
W8  x in CEXT(S(swol:ObjectProperty))	    =>  x in P and EXT(x) <= R x R
W9  x in CEXT(S(swol:DatatypeProperty))     =>  x in P and EXT(x) <= R x V
W10 x in CEXT(S(swol:UniqueProperty))	    =>  x in P and EXT(x) is functional
W11 x in CEXT(S(swol:UnambiguousProperty))  =>  x in CEXT(S(swol:ObjectProperty))
					        and converse EXT(x) is functional
W12 x in CEXT(S(swol:TransitiveProperty))   =>  x in CEXT(S(swol:ObjectProperty))
					        and EXT(x) o EXT(x) <= EXT(x)

W13  in EXT(S(rdfs:subClassOf))     iff x,y in C\DT and CEXT(x) <= CEXT(y)
W14  in EXT(S(swol:sameClassAs))    iff x,y in C\DT and CEXT(x) = CEXT(y)
W15  in EXT(S(swol:disjointWith))   iff x,y in C\DT and CEXT(x)^CEXT(y) = {}
W16  in EXT(S(rdfs:subPropertyOf))  => x,y in P and EXT(x) <= EXT(y)
W17  in EXT(S(swol:samePropertyAs)) => x,y in P and EXT(x) = EXT(y)
W18  in EXT(S(swol:sameIndividualAs))         iff  x,y in R and x=y
W19  in EXT(S(swol:differentIndividualFrom))  iff  x,y in R and x/=y

W20 CEXT(S(swol:Thing)) = R
W21 CEXT(S(swol:Nothing)) = {}

　rdf:subClassOfは、non-datatypes上のCEXTのみとと一緒に並ぶ(lines up)ことに
注意せよ。

4.5 議論

　ここでの解釈の定義は、多くの論理のフォーマリズムの解釈よりも複雑である。理由は以下の
２つである。
(1)　RDFとRDFSの場合と同様に、理論中にメタ理論が存在する。
(2)　RDFSとOWLに、大きなビルトインのボキャブラリがある。

　解釈が複雑になればなるほど、意味がill-fomredになる可能性が劇的に大きくなる。この可能性を
小さくするために、以下を選択すべきでである。
(1)　description logicsのdescription-forming constructsは、解釈中では明確にしない。
(show up in interpretations.)
(2)　DAML+OILのいくつかのdescription-relating constructsは、期待されるよりもより弱い
　　意味が与えられる。特に、プロパティの様々なカテゴリと同様に、rdfs:subPropertyOfと
swol:samePropertyAsは、一方向の定義のみを与えらえる(are only given one-way defintions).

5. 充足性(Satisfaction)

　OWL KBの拡張された解釈 I'が与えられたとして、 
　KBに対して、OWLの解釈Iが、次の特別なコンポーネントAをもつとき、
	A : K -> R u V		mapping from nodes to denotation
　     但し、Aは、ノンテキストノードはRへと写像され、かつテキストノードはVへの写像されるという
　　　条件を満たすものとする。
　I'は、解釈Iの拡張であると呼ぶ。

　以下に示すように、拡張された解釈は、KBをOWL充足する。

注意：構成rdf:name は、ローカルパートネーム(local part name)と
　　URI http://www.w3.org/1999/02/22-rdf-syntax-ns付のQNameを参照する(refers to the QName with)。 

　　　構成rdfs:name は、ローカルパートネーム(local part name)と
　　URI http://www.w3.org/rdfs URI]付のQNameを参照する。 

　　　構成swol:nameは、ローカルパートネーム(local part name)と
　　URI http://www.w3.org/[swol URI]付のQNameを参照する。

5.1 non-descriptionsに対しての充足(Satisfaction　for non-descriptions)

Syntax		Semantic Conditions

kb ::= resourceElement*

resourceElement ::= 
     ELEMENT(name,{propertyAttribute*},{propertyElement*})
		A(|self|) in CEXT(S(name))

propertyAttribute ::=
     ATTRIBUTE(rdf:ID,id)
		A(|parent|) = S(Q(id))
   | ATTRIBUTE(rdf:about,id)
		A(|parent|) = S(Q(id))
   | ATTRIBUTE(name,text,type,value)
		< A(|parent|) , A(|self|) > in EXT(S(name))
		A(|self|) = value
   | ATTRIBUTE(name,text)
		< A(|parent|) , A(|self|) > in EXT(S(name))
		A(|self|) in LV(text)

propertyElement ::=
     ELEMENT(rdf:type,{},{desc})
		A(|parent|) in ID(desc)
   | ELEMENT(rdfs:subClassOf,{},{desc})
		ID(|parent|) <= ID(desc)
   | ELEMENT(swol:sameClassAs,{},{desc})
		ID(|parent|) = ID(desc)
   | ELEMENT(swol:disjointFrom,{},{desc})
		ID(|parent|) ^ ID(desc) = {}
   | ELEMENT(rdfs:domain,{},{desc})
		IR(|parent|)  <= ID(desc) x (RuV)
   | ELEMENT(rdfs:range,{},{desc})
		IR(|parent|)  <= R x IC(desc)
   | ELEMENT(name,{rdf:resource,id},{})
		< A(|parent|),S(Q(id)) > in IR(name)
   | ELEMENT(name,{},{resourceElement})
		< A(|parent|),S(resourceElement) > in IR(name)
   | ELEMENT(name,{},{valueNode=TEXT(text)},type,value)
		< A(|parent|),A(valueNode) > in IR(name)
		A(valueNode) = value
   | ELEMENT(name,{},{valueNode=TEXT(text)})
		< A(|parent|),A(valueNode) > in IR(name)
		A(valueNode) in LV(text)

prop ::= resourceElement

5.2 descriptionsに対しての拡張(Extensions for descriptions)

Description	Extension(ID)

desc
 ::= ELEMENT(swol:Class,{ATTRIBUTE(rdf:about,id)})
		CEXT(S(Q(id))) ^ R	provided that S(Q(id)) not in DT
   | ELEMENT(swol:unionOf,{desc+})
		ID(desc1) v ... v ID(descn)
   | ELEMENT(swol:intersectionOf,{desc+})
		ID(desc1) ^ ... ^ ID(descn)
   | ELEMENT(swol:complementOf,{desc})
		R \ ID(desc)
   | ELEMENT(swol:oneOf,{resourceElement*})
		{ A(resourceElement1), ..., A(resourceElementn) }
   | ela(swol:toClass,swol:property=prop,swol:class=class})
		{ x :  in EXT(prop) implies y in IC(class) }
   | ela(swol:hasValue,swol:property=prop,swol:value=obj})
		{ x :  in EXT(prop) }
   | ela(swol:hasClass,swol:property=prop,swol:class=class})
		{ x : exists y  in EXT(prop) and y in IC(class) }
   | ela(swol:minCardinality,swol:property=prop,swol:count=int})
		{ x : >=int y   in EXT(prop) }
   | ela(swol:maxCardinality,swol:property=prop,swol:count=int})
		{ x : <=int y   in EXT(prop) }
   | ela(swol:cardinality,swol:property=prop,swol:count=int})
		{ x : =int y   in EXT(prop) }
   | ela(swol:minCardinality,swol:property=prop,swol:count=int,swol:class=class})
		{ x : >=int y   in EXT(prop) and y in IC(class) }
   | ela(swol:maxCardinality,swol:property=prop,swol:count=int,swol:class=class})
		{ x : <=int y   in EXT(prop) and y in IC(class) }
   | ela(swol:cardinality,swol:property=prop,swol:count=int,swol:class=class})
		{ x : =int y   in EXT(prop) and y in IC(class) }


Class		Extension(IC)

class
 ::= desc
		ID(desc)
   | ELEMENT(swol:Datatype,{ATTRIBUTE(rdf:about,id)})
		L(S(Q(id))))		provided that S(Q(id)) in DT

The construction ela(name,arg=category,...) is a shorthand for for an
ELEMENT node with name, , and no other attributes or children.
The possible attributes or children and their meanings are:

For prop:

Syntactic Form 			 	   Meaning

ATTRIBUTE(argi,id)			   S(Q(id))
ELEMENT(argi,{ATTRIBUTE(rdf:resource,id)}) S(Q(id))
ELEMENT(argi,{},{resourceElement})	   A(resourceElement)

For class:

Syntactic Form 			 	   Meaning

ATTRIBUTE(argi,id)			   S(Q(id))
ELEMENT(argi,{ATTRIBUTE(rdf:resource,id)}) S(Q(id))
ELEMENT(argi,{},{class})		   class

For obj:

Syntactic Form 			 	  Meaning 	Semantic Conditions

ATTRIBUTE(argi,text,type,value)		  A(|self|)	A(|self|) = value
ATTRIBUTE(argi,text)			  A(|self|)	A(|self|) in LV(text)
ELEMENT(argi,{},{TEXT(text)},type,value)  A(|self|)	A(|self|) = value
ELEMENT(argi,{},{TEXT(text)}) 		  A(|self|)	A(|self|) in LV(text)
ELEMENT(argi,{},{obj=resourceElement})	  A(obj)

For int:

Syntactic Form 			 	  Meaning

ATTRIBUTE(argi,text,type,value)		  value
ATTRIBUTE(argi,text)			  LV(int)(text)
ELEMENT(argi,{},{TEXT(text)},type,value)  value
ELEMENT(argi,{},{TEXT(text)})		  LV(int)(text)


6. モデルとentailment:

　知識べースを充足するある解釈の拡張が存在するならば、その解釈はOWL知識ベースのモデルで
ある。　

　OWL知識ベースKB1のすべてのモデルが、KB2のモデルでもあるならば、KB1はKB2をentailする。

(訳メモ)　entailは、論理的帰結の逆か？

定理(to be proved):
KB1とKB2は、OWL知識ベースとする。また、KB1-とKB2-は、それらの中のRDFの三つ組みとする。
KB1-がKB-をRDFSの意味でentailするならば、KB1はKB2をentailする。


A1. References:

XQuery 1.0 and XPath 2.0 Data Model (W3C Working Draft 7 June 2001)
http://www.w3.org/TR/2001/WD-query-datamodel-2001-6-7/

A2. Status of all RDF, RDFS, and ``old'' DAML-OIL constructs not handled above:

  Surface syntax - does not show up at this level
	xmlns:* rdf:aboutEach rdf:aboutEachPrefix rdf:li rdf:parseType
	rdf:RDF rdf:Description rdf:ID rdf:about rdf:resource
	Ontology versionInfo imports

  Obsolete surface syntax - not needed
	rdf:parseType of daml:collection
	daml:List daml:nil daml:first daml:rest daml:item

  Constructs with no special treatment needed (more or less)
	rdfs:label rdfs:comment rdf:value rdfs:seeAlso rdfs:isDefinedBy

  Unneeded description syntax
	daml:Restriction daml:onProperty daml:hasClassQ

  Not handled (yet)
	daml:disjointUnionOf

  Problematic Constructs
	RDF reification - rdf:subject, rdf:predicate, rdf:object, rdf:Statement
			- rdf:bagID
			- what does it mean?
	RDF containers - rdfs:Container, rdf:Seq, rdf:Bag, rdf:Alt, rdf:_n
		       - what do they mean?
	daml:equivalentTo - what does it mean?