[Crm-sig] RDF guidelines

Martin Doerr martin at ics.forth.gr
Fri Mar 22 20:33:34 EET 2019

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.




  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
  Email: martin at ics.forth.gr
  Web-site: http://www.ics.forth.gr/isl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20190322/adbe13a1/attachment-0001.html>

More information about the Crm-sig mailing list