頻出する type。核となる概念といっても差し支えない。rdf:type とは一緒なのか、どう使うのか。Definition of the CIDOC Conceptual Reference Model から。
About Types
Virtually all structured descriptions of museum objects begin with a unique object identifier and information about the "type" of the object, often in a set of fields with names like "Classification", "Category", "Object Type", "Object Name", etc. All these fields are used for terms that declare that the object belongs to a particular category of items. In the CIDOC CRM the class E55 Type comprises such terms from thesauri and controlled vocabularies used to characterize and classify instances of CIDOC CRM classes. Instances of E55 Type represent concepts (universals) in contrast to instances of E41 Appellation, which are used to name instances of CIDOC CRM classes.
For this purpose the CIDOC CRM provides two basic properties that describe classification with terminology, corresponding to what is the current practice in the majority of information systems. The class E1 CRM Entity is the domain of the property P2 has type (is type of), which has the range E55 Type. Consequently, every class in the CIDOC CRM, with the exception of E59 Primitive Value, inherits the property P2 has type (is type of). This provides a general alternative mechanism to specialize the classification of CIDOC CRM instances to any level of detail, by linking to external vocabulary sources, thesauri, classification schemas or ontologies.
Analogous to the function of the P2 has type (is type of) property, some properties in the CIDOC CRM are associated with an additional property. These are numbered in the CIDOC CRM documentation with a ‘.1’ extension. The range of these properties of properties always falls under E55 Type. The purpose of a property of a property is to provide an alternative mechanism to specialize its domain property through the use of property subtypes declared as instances of E55 Type. They do not appear in the property hierarchy list but are included as part of the property declarations and referred to in the class declarations. For example, P62.1 mode of depiction: E55 Type is associated with E24 Physical Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity. The class E55 Type also serves as the range of properties that relate to categorical knowledge commonly found in cultural documentation. For example, the property P125 used object of type (was type of object used in) enables the CIDOC CRM to express statements such as “this casting was produced using a mould”, meaning that there has been an unknown or unmentioned object, a mould, that was actually used. This enables the specific instance of the casting to be associated with the entire type of manufacturing devices known as moulds. Further, the objects of type “mould” would be related via P2 has type (is type of) to this term. This indirect relationship may actually help in detecting the unknown object in an integrated environment. On the other side, some casting may refer directly to a known mould via P16 used specific object (was used for). So a statistical question to how many objects in a certain collection are made with moulds could be answered correctly (following both paths through P16 used specific object (was used for) - P2 has type (is type of) and P125 used object of type (was type of object used in). This consistent treatment of categorical knowledge enhances the CIDOC CRM’s ability to integrate cultural knowledge.
Types, that is, instances of E55 Type and its subclasses, can be used to characterize the instances of a CIDOC CRM class and hence refine the meaning of the class. A type ‘artist’ can be used to characterize persons through P2 has type (is type of). On the other hand, in an art history application of the CIDOC CRM it can be adequate to extend the CIDOC CRM class E21 Person with a subclass E21.xx Artist. What is the difference of the type ‘artist’ and the class Artist? From an everyday conceptual point of view there is no difference. Both denote the concept ‘artist’ and identify the same set of persons. Thus in this setting a type could be seen as a class and the class of types may be seen as a metaclass. Since current systems do not provide an adequate control of user defined metaclasses, the CIDOC CRM prefers to model instances of E55 Type as if they were particulars, with the relationships described in the previous paragraphs.
Users may decide to implement a concept either as a subclass extending the CIDOC CRM class system or as an instance of E55 Type. A new subclass should only be created in case the concept is sufficiently stable and associated with additional explicitly modelled properties specific to it. Otherwise, an instance of E55 Type provides more flexibility of use. Users that may want to describe a discourse not only using a concept extending the CIDOC CRM but also describing the history of this concept itself, may choose to model the same concept both as subclass and as an instance of E55 Type with the same name. Similarly it should be regarded as good practice to foresee for each term hierarchy refining a CIDOC CRM class a term equivalent of this class as top term. For instance, a term hierarchy for instances of E21 Person may begin with “Person”. One role of E55 Type is to be the CIDOC CRM’s interface to domain specific ontologies and thesauri or less formal terminological systems. Such sets of concepts can be represented in the CIDOC CRM as subclasses of E55 Type, forming hierarchies of terms, i.e. instances of E55 Type linked via P127 has broader term (has narrower term). Such hierarchies may be extended with additional properties. Other standard models, in particular richer ones, used to describe terminological systems can also be interfaced with the CIDOC CRM by declaring their respective concept class as being equivalent to E55 Type, and their respective broader/narrower relation as being identical with P127 has broader term (has narrower term), as long as they are semantically compatible.
In addition to being an interface to external thesauri and classification systems, E55 Type is an ordinary class in the CIDOC CRM and a subclass of E28 Conceptual Object. E55 Type and its subclasses inherit all properties from this superclass. Thus together with the CIDOC CRM class E83 Type Creation the rigorous scholarly or scientific process that ensures a type is exhaustively described and appropriately named can be modelled inside the CIDOC CRM. In some cases, particularly in archaeology and the life sciences, E83 Type Creation requires the identification of an exemplary specimen and the publication of the type definition in an appropriate scholarly forum. This is very central to research in the life sciences, where a type would be referred to as a “taxon,” the type description as a “protologue,” and the exemplary specimens as “original element” or “holotype”. Finally, instances of E55 Type or suitable subclasses can describe universals from type systems not organized in thesauri or ontologies, such as industrial product names and types, defined and published by the producers themselves for each new product or product variant.
タイプについて
事実上、博物館の収蔵品のすべての構造化された記述は、一意の収蔵品識別子と収蔵品の種類（type）に関する情報から始まる。多くの場合、この「種類」に相当する内容は "Classification", "Category", "Object Type", "Object Name" といった項目に記述されている。これらの項目の記述はすべて、収蔵品が特定のカテゴリに属することを宣言するために使用されます。CIDOC CRM では、クラス E55 Type は CIDOC CRM クラスのインスタンスを特徴付け、分類するために使用されるシソーラスや統制語彙からの用語で構成されています。E55 Type のインスタンスは概念（普遍）を表すものであり、CIDOC CRMのクラスのインスタンスの名前に使用されるE41 Appellationのインスタンスとは対照的である。
この目的のために、CIDOC CRMは、情報システムの多くで現在行われていることに対応して、用語で分類を記述する2つの基本的なプロパティを提供しています。クラス E1 CRM Entity は、プロパティ P2 has type (is type of) のドメインであり、範囲は E55 Type です。したがって、CIDOC CRMのすべてのクラスは、E59 Primitive Value を除いて、プロパティ P2 has type (is type of) を継承します。これは、外部の語彙、シソーラス、分類体系、またはオントロジーにリンクすることによって、CIDOC CRMインスタンスの分類を任意のレベルまで詳細化するための一般的な代替メカニズムを提供します。
P2 has type（is type of） プロパティの機能と同様に、CIDOC CRM のいくつかのプロパティは、追加のプロパティに関連付けられています。これらの追加のプロパティは、CIDOC CRMのドキュメントでは ".1" という拡張子を付けて番号が付けられています。これらのプロパティのプロパティの範囲は常に E55 Type に該当します。プロパティのプロパティの目的は、E55 Type のインスタンスとして宣言されたプロパティサブタイプの使用を通じて、そのドメインプロパティを詳細化するための代替メカニズムを提供することです。それらは，プロパティ階層リストには現れないが，プロパティ宣言の一部として含まれ，クラス宣言の中で参照されます。例えばP62.1 mode of depiction : E55 Type は、 E24 Physical Man-made Thing が P62 depicts (is depicted by): E1 CRM Entity していることに紐づけられてます。クラス E55 Type はまた、文化資源のドキュメンテーションにおいて一般的に見られるカテゴリ知識に関連するプロパティのレンジとしても機能します。例えば、プロパティP125 used object of type (was type of object used in) は、CIDOC CRMが「この鋳物は型を使って作られた」というような記述を表現することを可能にし、これは、実際に使用された型である未知のまたは言及されていないオブジェクトが存在したことを意味します。これにより、鋳型として知られている製造装置の種類全体に、鋳型の特定のインスタンスを関連付けることが可能となります。さらに、「鋳型」というタイプのオブジェクトは、P2 has type (is type of) を介して関連づけられるでしょう。このような間接的な関係は、実際には、統合された環境の中で未知の物体を検出するのに役立つかもしれません。一方、いくつかの鋳物は、P16 used specific object (was used for) を介して、既知の鋳型を直接参照している場合があります。したがって、あるコレクションの中でどのくらいの数のオブジェクトが金型で作られているかという統計的な質問は、（P16 used specific object (was used for) - P2 has type (is type of) という経路と P125 used object of type (was type of object used in) と経路の両方をたどって）正しく答えられるかもしれません。このような一貫した分類知識の扱いは、CIDOC CRM の文化知識の統合能力を高めています。
タイプ、すなわち E55 Type とそのサブクラスのインスタンスは、CIDOC CRM クラスのインスタンスを特徴づけるために使用され、その結果、クラスの意味を洗練させることができます。タイプ artist は、P2 has type (is type of)を使って人物を特徴付けることができる。一方、CIDOC CRM の美術史アプリケーションでは、CIDOC CRM クラス E21 Person をサブクラス E21.xx Artist で拡張すれば十分です。タイプ artist とクラス E21.xx Artist の違いは何でしょう？日常的な概念の観点からは違いはありません。どちらも概念 artist を表し、同じ人の集合を識別します。したがって、この設定では、型はクラスとして見られ、型のクラスはメタクラスとして見られるかもしれません。現在のシステムではユーザ定義のメタクラスを十分に制御できないため、CIDOC CRMでは E55 Type のインスタンスを、前の段落で説明した P16やP125の関係を持ち、あたかも個物のものであるかのようにモデル化するべきだと考えています。
ユーザーは、CIDOC CRM クラスシステムを拡張したサブクラスとして、または E55 Type のインスタンスとして概念を実装することができます。新しいサブクラスは、その概念が十分に安定しており、その概念に固有の明示的にモデル化されたプロパティが追加されている場合にのみ作成されるべきです。それ以外の場合は、E55 Type のインスタンスの方がより柔軟に使用できます。CIDOC CRMを拡張した概念だけでなく、その概念自体の歴史も記述したい場合は、同じ概念をサブクラスとして、また同じ名前の E55 Type のインスタンスとして同時にモデル化することを選択することができます。同様に、CIDOC CRMクラスを詳細化した各階層の語について、元のCIDOC CRMクラスに相当する項を最上位項として想定しておくことが望ましいと考えられます。例えば、E21 Person のインスタンスの用語階層は、最上位が Person であると良いということです。E55 Type の役割の一つは、CIDOC CRMのドメイン固有のオントロジーやシソーラス、あるいはあまり正式ではない用語体系へのインタフェイスとなることです。このような概念の集合は、CIDOC CRMにおいて E55 Type のサブクラスとして表現され、用語の階層を形成することができます。つまり、E55 Type のインスタンスは P127 has broader term (has narrower term) で紐づけられるということです。このような階層は、追加のプロパティで拡張することができます。用語体系を記述するために使用される他の標準モデル、特にCIDOC CRMよりも詳細化したモデルも、意味的に互換性がある限り、それぞれの概念クラスを E55 Type と同等であると宣言し、広義・狭義関係を P127 has broader term（has narrower term） と同等であると宣言することで、CIDOC CRMと連携させることができます。
E55 Typeは、外部のシソーラスや分類システムへのインターフェースであることに加えて、CIDOC CRMの通常のクラスであり、
E28 Conceptual Objectのサブクラスでもあります。E55 Typeとそのサブクラスは、このスーパークラスからすべてのプロパティを継承します。このようにして、CIDOC CRM のクラスE83 Type Creationとともに、型が網羅的に記述され、適切な名前が付けられるようにする厳密な学術的・科学的プロセスを CIDOC CRM の内部でモデル化することができます。特に考古学や生命科学の分野では、E83 Type Creationでは模範的な標本を特定し、適切な学術的な場で型の定義を公表する必要がある場合があります。これは生命科学の研究において非常に重要なことであり、型を「分類群（taxon）」と呼び、型の説明を「初発表文（protologue）」と呼び、模範的な標本を「ホロタイプ（holotype）」*1と呼ぶことになります。
最後に、E55 Type のインスタンスまたは適切なサブクラスは、シソーラスやオントロジーで構造化されていない型システムから作られる世界を記述することができる。その型システムとは例えば、工業製品名やその型が、各新製品または製品のバージョンについて生産者自身によって定義され、公開されているようなものである。
P2 has type (is type of) のスコープノート
This property allows sub typing of CIDOC CRM entities - a form of specialisation – through the use of a terminological hierarchy, or thesaurus.
The CIDOC CRM is intended to focus on the high-level entities and relationships needed to describe data structures. Consequently, it does not specialise entities any further than is required for this immediate purpose. However, entities in the isA hierarchy of the CIDOC CRM may by specialised into any number of sub entities, which can be defined in the E55 Type hierarchy. E41 Appellation, for example, may be specialised into “e-mail address”, “telephone number”, “post office box”, “URL” etc. none of which figures explicitly in the CIDOC CRM hierarchy. A comprehensive explanation about refining CIDOC CRM concepts by E55 Type is given in the section “About Types” in the section on “Specific Modelling Constructs” of this document.
このプロパティは、 CIDOC CRM エンティティのサブタイプ化 （詳細化の一形態） を、 用語階層またはシソーラスの使用によって可能にします。
CIDOC CRM は、データ構造を記述するために必要な上層のエンティティと関係に焦点を当てています。その結果、この直接の目的に必要な以上にエンティティを特化することはありません。しかし、CIDOC CRM の isA 階層に相当するエンティティは、E55 Type 階層で定義できる任意の数のサブエンティティに特化することができます。例えば、E41 Appellation は、「メールアドレス」、「電話番号」、「私書箱」、「URL」などに特化することができますが、これらはCIDOC CRMの階層では明示的に定義されていません。E55型によるCIDOC CRMの概念の洗練についての包括的な説明は、本文書の「特定のモデリング構造 (Specific Modelling Constructs)」の「型について(About Types)」の項で説明されています。
サブ疑問：P127 has broader term (has narrower term) と rdfs:subClassOf と skos:broader の関係は？
rdfs:subClassOf と skos 語彙の関係は、skosの方が「緩い」と理解できる。SKOS入門によると、
既存のRDFS/OWLオントロジーをSKOS概念体系に変換する場合を考えてみてください。このような場合には、すべての rdfs:subClassOf ステートメントを skos:broader として解釈し直すことは妥当です。
ので、rdfs:subClassOf で記述できるものは skos:broader で書けるが、
例えば、ex2:vehicles（乗り物）がex2:cars（車）より広義と述べられており、そのex2:cars（車）はex2:wheels（自動車）より広義と言明さているケースを考えてみてください。「wheels」が「vehicles」に関するより狭義の概念であると自動的に推論されれば、問題がありえます。SKOSは、skos:broaderとskos:narrowerが一般的に推移的なプロパティーであると定義しないことによって、このような問題を予測します。「推移的階層」を表現したい場合は、4.5項を読むことをお勧めします。この項で定義しているskos:broaderのセマンティクスとの互換性を担保しつつ、これを行う方法を示しています。
と書かれているように skos:broader は必ずしも rdfs:subClassOf に変換できないので、skos:broader の方が緩いと言えるのだ。
さて、P127 has broader term (has narrower term) と skos:broader については AAT Semantic Representation という文書（w3cのメーリングリストに投稿されたものである。ここは公式ではないがAAT Semantic Representation - W3C Public Mailing List Archivesが見やすい）に以下の文があり、これはTGN（要は地名辞書）を想定しているが、CRMサイドとSKOSサイドで意見が異なる。私はこの解釈自体はSKOS側が正しく、概念（concepts, universals) と個々の地名（places, particulars) の双方に skos:broader は使えると考える。緩いから。一方で、CRMサイドがskosを個物に用いたくないのは分かる。その緩さがセマンティックスが混乱を引き起こすからであり、概念の関係は語彙の名前の対応（ "has broader term" と "broader" ）を見ても分かるように、skos の語彙と意味が対応していて、個物については P89 falls within を別途用意しているからそっちを使ってもらいたいのだ。だから、単に P127 has broader term (has narrower term) と skos:broader の１対１対応を諦めれば良い話である。CRMの関連語彙の union がskos:broader だということにすればよい。つまり、CRMの中で skos:broader は混乱を引き起こすので使わないほうがいいという結論にもなる。
CIDOC CRM uses distinct and unrelated properties for this:
- P2 has type for "place type" and P127 has broader term for "place super-type". P127 is an analog of skos:broader
- P89 falls within for "super-place" (earlier versions also had P88i forms part of)
Some in the CRM community (including Martin Doerr) contend that SKOS should be used only for concepts (universals), and not for named entities such as places (particulars). Some in the SKOS community (including Antoine Isaac) disagree. There are many SKOS thesauri that capture places, e.g. NISV's GTAA (e.g. Amsterdam http://data.beeldengeluid.nl/gtaa/31586). It's clear that TGN will be published as a SKOS thesaurus, with additional place-specific classes and properties. We'll respect a "concept-thing" dichotomy, using foaf:focus to relate the two. E.g.
tgn:7018759-concept a skos:Concept; foaf:focus tgn:7018759-place; skos:prefLabel "Sofiya-Grad"; gvp:broaderPartitive tgn:7006413-concept; # Bulgaria gvp:placeType aat:123456. # region (administrative division) tgn:7018759-place a geo:SpatialThing, crm:E53_Place, <Place classes from other ontologies>; skos:prefLabel "Sofiya-Grad"; crm:P87_is_identified_by [crm:P3_has_note "Sofiya-Grad"]; dc:type aat:123456; crm:P2_has_type aat:123456; # region (administrative division) geo:lat 42.6830; geo:long 23.3160 . tgn:7006413-concept a skos:Concept; foaf:focus tgn:7006413-place; skos:prefLabel "Bulgaria"; gvp:placeType aat:123457. # Nation tgn:7006413-place a geo:SpatialThing, crm:E53_Place, <Place classes from other ontologies>; skos:prefLabel "Bulgaria"; crm:P87_is_identified_by [crm:P3_has_note "Bulgaria"]; dc:type aat:123457; crm:P2_has_type aat:123457; # Nation geo:lat 43.0; geo:long 25.0 .
結局 rdf:type とはどう違うのか
A rdf:type B を CIDOC-CRM では"日"型のドミノ的な方形を利用して上にB下にAを使って表現することが多い。より正確に言えば、AやBのラベルを上下に書き込み、URIで書くという概念は特にない（長らくcrmのURIは定まっていなかったほどだ）。公式文書でも使われている記法で "in boxes showing the class label above the instance label." と書いている。
それと並行して、 このAとBのペアから P2 has type で結ばれる C rdf:type D のドミノは、A と C の rdf:type 関係を表現することが多い。Dが E55 Type であり、メタクラスの役割を果たしている。上の翻訳の鋳型の例で "P16 used specific object (was used for) - P2 has type (is type of) という経路と P125 used object of type (was type of object used in) と経路" が同じペアを結びうることが書かれているが、この時の P2 has type は rdf:type であることが明白である。そして、B と C の間の関係は C rdfs:subClassOf B の関係にあり、それがタイプによる詳細化として機能しているメカニズムである。このように使われるため P2 has type は "C rdfs:subClassOf B を含意した rdf:type"と言い換えても大丈夫だろう。
公式文書より。1つめは、物である（コピー元の）ラオコーン像がヘレニズム風様式であることを示している。この has type は、ヘレニズム風様式の物というサブクラスにラオコーン像を位置づけなおしている。もう一つ、コピー先はコピーだから、コピーというタイプが付されている。これも、rdf:type。
もう一つ公式系のRDF化に関わるスライドより。
まあRDFに関わるものなので少し特殊で、label ではなく、URIが下のボックスに入っている。P2 has Type の意味も rdf:type。
非公式で古いが、CIDOC CRM 入門 にある Type の例の "Dimension Type | length" では Dimension Type が独自か古いかでよくわからないが、n-aryを実現するための長さの無名の抽象表現にlengthクラスが紐づいているので rdf:type と読めるだろう。
ここまで理解してから
現在のシステムではユーザ定義のメタクラスを十分に制御できないため、CIDOC CRMでは E55 Type のインスタンスを、前の段落で説明した P2やP16やP125の関係を持ち、あたかも個物のものであるかのようにモデル化するべきだと考えています。
というフレーズを読み返すと、いくつかのプロパティが意味階層の違うものを結んでいる（ rdf:type を含意する関係）という設計が理解できるだろう。
