Dear All,
here my heavy reworking and reduction of the debated paragraph about
multiple instantiation. I hope this has settled all concerns, linguistic
improvement not withstanding. Please comment!
-------------------------------------------------------------------------------------------------------------
*About implementing multiple Instantiation*
Knowledge Representation models can assign multiple classes to a given
instance identifier. After that, all properties of each assigned class
are applicable for this identifier. This construct is called “multiple
instantiation. For instance, a calligraphy is an “image” and a
“linguistic object”, having a language and a painting style. This is not
possible with Relational data structures, because instance
identification is limited to the entity (class) or with XML-like data
structures, because instance identification is by structural position
(additional identifiers can be used for linking).
Therefore many users are not aware of this feature, and even KR tools do
not systematically guide users to use it: Once an instance is classified
by one class, the tool should not allow for using a property of another
class, but most likely will not advise the user that she could add the
additional class to the instance. Nevertheless, it is a key feature of
KR models that facilitating modularizing ontologies and the often
advertised ability to combine different ontologies.
The CRM as ontology relies heavily on multiple instantiation:
Combination of classes that are applicable to some instances only
incidentally and have no properties specific to this combination are not
modelled in the CRM individually as subclasses of multiple parent
classes. The latter would be called “multiple IsA”. To avoid multiple
IsA in such cases is an important normalization principle to keep the
ontology very compact and unambiguous.
In the specification modules of mapping software used to transform data
into a CRM-compatible form, care must be taken to foresee and allow the
user to combine RDF classes systematically.
Some combinations of classes may more frequently occur, such as
combining /E41 Appellation/ with /E33 Linguistic Object/ in order to
reach /E56 Language/ via /P72 has language. /In a local system that does
not easily support multiple instantiation, the candidate cases for
multiple instantiation may be combined in subclasses using multiple IsA.
For their labels, we recommend to aggregate the class identifier codes
as in: “/E41_E33_Linguistic Appellation”. /Such a replacement is query
compatible with the standard. A respective import/export system simply
needs to make the trivial replacements of the respective class
combinations with their multiple IsA counterparts and vice-versa in
order to achieve import/export compatibility.
Users may provide feedback about frequent cases where multiple
instantiation is used, in order to guide users to these modelling cases.
These could systematically be entered into the CRM RDF implementation,
without requiring the CRM standard itself to repeat them.
----------------------------------------------------------------------------
Best,
Martin
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625
Email: [email protected]
Web-site: http://www.ics.forth.gr/isl
