Re: [Crm-sig] Using multiple instantiation

[Martin Doerr]

I think Robert's text needs a bit more background. Would someone try?

Multiple instantiation is fundamental to the CRM and semantic models. 
Not just a technique.


We also observe that programmers writing code for selecting applicable 
properties as data entry into RDF/OWL based systems or mapping systems 
use to forget multiple instantiation, and to alert users that a suitable 
subclass may have the property needed.

It's not only a problem with other kinds of data models.

Best,

Martin

On 12/11/2018 1:42 PM, Christian-Emil Smith Ore wrote:

I like Robert's text. I can see some problems with the use of "merged classes" since 
there is a large number of possible classes. A "merged" class is simply a way to 
reformulate same as at the class level.

In a relational datebase one would need a common series of identifier for  the 
primary key in all involved tables which is uncommon but ok since one in 
principle need only one sequence giving unque identifers for an entire database 
(or all databases in the world)
Best
Christian-Emil


From: Crm-sig  on behalf of Detlev 
Balzer
Sent: 11 December 2018 12:16
To:crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Using multiple instantiation

I'm also wondering if we actually need such explanation. If the concern is that


many implementations at their core are not natively RDF or even graph-based and 
would run into difficulties trying to create relationship representations or 
classes in an object oriented programming language that instantiated multiple 
ontological classes.

then this is certainly true for "classical" relational databases without any 
level of object-relational mapping. However, anyone embarking on a certain degree of 
object-oriented design will be (or soon become) aware of these limitations, and of the 
various solutions discussed at length in the developer community.

Detlev


Am 11.12.2018 um 11:23 schrieb Richard Light:

Hi,

Unless I have misunderstood, both versions came from Robert. I still think that 
we need to consider what actually needs to be in the RDF document. In my view 
it should be the absolute minimum to 'do the job': the only question is what 
'the job' should be.:-)

Richard



--

 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: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl

Re: [Crm-sig] Using multiple instantiation

[Christian-Emil Smith Ore]

I like Robert's text. I can see some problems with the use of "merged classes" 
since there is a large number of possible classes. A "merged" class is simply a 
way to reformulate same as at the class level.

In a relational datebase one would need a common series of identifier for  the 
primary key in all involved tables which is uncommon but ok since one in 
principle need only one sequence giving unque identifers for an entire database 
(or all databases in the world)
Best
Christian-Emil


From: Crm-sig  on behalf of Detlev Balzer 

Sent: 11 December 2018 12:16
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Using multiple instantiation

I'm also wondering if we actually need such explanation. If the concern is that

> many implementations at their core are not natively RDF or even graph-based 
> and would run into difficulties trying to create relationship representations 
> or classes in an object oriented programming language that instantiated 
> multiple ontological classes.

then this is certainly true for "classical" relational databases without any 
level of object-relational mapping. However, anyone embarking on a certain 
degree of object-oriented design will be (or soon become) aware of these 
limitations, and of the various solutions discussed at length in the developer 
community.

Detlev


Am 11.12.2018 um 11:23 schrieb Richard Light:
> Hi,
>
> Unless I have misunderstood, both versions came from Robert. I still think 
> that we need to consider what actually needs to be in the RDF document. In my 
> view it should be the absolute minimum to 'do the job': the only question is 
> what 'the job' should be. :-)
>
> Richard
>
> On 11/12/2018 09:51, Stephen Stead wrote:
>>
>> I like Robert’s text as it gives enough info to point people in the right 
>> direction. However, it is brief. On the other hand Martin’s text is longer 
>> and needs some editorial input to make it read less “Martinish”. I would be 
>> happy to do that over Xmas but, if  Robert’s text is sufficient then I will 
>> not expend the time.
>>
>> Rgds
>>
>> SdS
>>
>>
>>
>> Stephen Stead
>>
>> Tel +44 20 8668 3075
>>
>> Mob +44 7802 755 013
>>
>> E-mail ste...@paveprime.com <mailto:ste...@paveprime.com>
>>
>> LinkedIn Profile https://www.linkedin.com/in/steads/
>>
>>
>>
>> *From:*Crm-sig  *On Behalf Of *Robert Sanderson
>> *Sent:* 10 December 2018 17:52
>> *To:* Florian Kräutli ; martin 
>> 
>> *Cc:* crm-sig 
>> *Subject:* Re: [Crm-sig] Using multiple instantiation
>>
>>
>>
>>
>>
>> I agree that it’s very dense, but also very informative!
>>
>>
>>
>> A shorter version might check both boxes – informative to folks that are 
>> more used to programming or traditional data management platforms, and 
>> instructive on how to work around their limitations?
>>
>>
>>
>> For example, something as short as the following might be sufficient:
>>
>>
>>
>> The CRM can be implemented in RDF using a technique called “multiple 
>> instantiation”.  This means that instances would participate in the IsA 
>> relationship (rdf:type) multiple times, thereby instantiating multiple 
>> classes at the same time. In the abstract model this is very appropriate, as 
>> an instance can very legitimately be thought of as an Appellation and a 
>> Linguistic Object at the same time in the case of a name that is in a human 
>> language. However, many implementations at their core are not natively RDF 
>> or even graph-based and would run into difficulties trying to create 
>> relationship representations or classes in an object oriented programming 
>> language that instantiated multiple ontological classes.  Instead, the 
>> projection from the abstract CRM into RDF includes artificial “merge” 
>> classes such as E41_E33_Linguistic_Appellation when use cases are sufficient 
>> to demonstrate the value of these constructions.  Use of these artificial 
>> classes is intended for situations where
>> the implementation is a challenge, rather than being an ontologically 
>> rigorous pattern.
>>
>>
>>
>>
>>
>> Rob
>>
>>
>>
>> *From: *Crm-sig > <mailto:crm-sig-boun...@ics.forth.gr>> on behalf of Florian Kräutli 
>> mailto:fkraeu...@mpiwg-berlin.mpg.de>>
>> *Date: *Friday, December 7, 2018 at 1:04 AM
>> *To: *martin mailto:mar...@ics.forth.gr>>
>> *Cc: *crm-sig mailto:crm-sig@ics.forth.gr>>
>> *Subject: *Re: [Crm-sig] Using multiple instantiat

Re: [Crm-sig] Using multiple instantiation

[Detlev Balzer]

I'm also wondering if we actually need such explanation. If the concern is that

> many implementations at their core are not natively RDF or even graph-based 
> and would run into difficulties trying to create relationship representations 
> or classes in an object oriented programming language that instantiated 
> multiple ontological classes. 

then this is certainly true for "classical" relational databases without any 
level of object-relational mapping. However, anyone embarking on a certain 
degree of object-oriented design will be (or soon become) aware of these 
limitations, and of the various solutions discussed at length in the developer 
community.

Detlev


Am 11.12.2018 um 11:23 schrieb Richard Light:
> Hi,
> 
> Unless I have misunderstood, both versions came from Robert. I still think 
> that we need to consider what actually needs to be in the RDF document. In my 
> view it should be the absolute minimum to 'do the job': the only question is 
> what 'the job' should be. :-)
> 
> Richard
> 
> On 11/12/2018 09:51, Stephen Stead wrote:
>>
>> I like Robert’s text as it gives enough info to point people in the right 
>> direction. However, it is brief. On the other hand Martin’s text is longer 
>> and needs some editorial input to make it read less “Martinish”. I would be 
>> happy to do that over Xmas but, if  Robert’s text is sufficient then I will 
>> not expend the time.
>>
>> Rgds
>>
>> SdS
>>
>>  
>>
>> Stephen Stead
>>
>> Tel +44 20 8668 3075
>>
>> Mob +44 7802 755 013
>>
>> E-mail ste...@paveprime.com <mailto:ste...@paveprime.com>
>>
>> LinkedIn Profile https://www.linkedin.com/in/steads/
>>
>>  
>>
>> *From:*Crm-sig  *On Behalf Of *Robert Sanderson
>> *Sent:* 10 December 2018 17:52
>> *To:* Florian Kräutli ; martin 
>> 
>> *Cc:* crm-sig 
>> *Subject:* Re: [Crm-sig] Using multiple instantiation
>>
>>  
>>
>>  
>>
>> I agree that it’s very dense, but also very informative!
>>
>>  
>>
>> A shorter version might check both boxes – informative to folks that are 
>> more used to programming or traditional data management platforms, and 
>> instructive on how to work around their limitations?
>>
>>  
>>
>> For example, something as short as the following might be sufficient:
>>
>>  
>>
>> The CRM can be implemented in RDF using a technique called “multiple 
>> instantiation”.  This means that instances would participate in the IsA 
>> relationship (rdf:type) multiple times, thereby instantiating multiple 
>> classes at the same time. In the abstract model this is very appropriate, as 
>> an instance can very legitimately be thought of as an Appellation and a 
>> Linguistic Object at the same time in the case of a name that is in a human 
>> language. However, many implementations at their core are not natively RDF 
>> or even graph-based and would run into difficulties trying to create 
>> relationship representations or classes in an object oriented programming 
>> language that instantiated multiple ontological classes.  Instead, the 
>> projection from the abstract CRM into RDF includes artificial “merge” 
>> classes such as E41_E33_Linguistic_Appellation when use cases are sufficient 
>> to demonstrate the value of these constructions.  Use of these artificial 
>> classes is intended for situations where
>> the implementation is a challenge, rather than being an ontologically 
>> rigorous pattern.
>>
>>  
>>
>>  
>>
>> Rob
>>
>>  
>>
>> *From: *Crm-sig > <mailto:crm-sig-boun...@ics.forth.gr>> on behalf of Florian Kräutli 
>> mailto:fkraeu...@mpiwg-berlin.mpg.de>>
>> *Date: *Friday, December 7, 2018 at 1:04 AM
>> *To: *martin mailto:mar...@ics.forth.gr>>
>> *Cc: *crm-sig mailto:crm-sig@ics.forth.gr>>
>> *Subject: *Re: [Crm-sig] Using multiple instantiation
>>
>>  
>>
>> Hi Martin,
>>
>>  
>>
>> I agree with the previous comments that the text is a bit dense and assumes 
>> a quite specific prior knowledge, i.e. it might be confusing to include it 
>> as a general guideline.
>>
>>  
>>
>> When I started with the CRM however, I somehow refrained from doing multiple 
>> instantiation. I don't think it is actively discouraged anywhere, but I was 
>> under the impression that I should rather find a more fitting entity than 
>> 'overloading' one with several classes. So an indication that multiple 
>> instantiation can b

Re: [Crm-sig] Using multiple instantiation

[Stephen Stead]

I like Robert’s text as it gives enough info to point people in the right 
direction. However, it is brief. On the other hand Martin’s text is longer and 
needs some editorial input to make it read less “Martinish”. I would be happy 
to do that over Xmas but, if  Robert’s text is sufficient then I will not 
expend the time.

Rgds

SdS

 

Stephen Stead

Tel +44 20 8668 3075 

Mob +44 7802 755 013

E-mail  <mailto:ste...@paveprime.com> ste...@paveprime.com

LinkedIn Profile https://www.linkedin.com/in/steads/

 

From: Crm-sig  On Behalf Of Robert Sanderson
Sent: 10 December 2018 17:52
To: Florian Kräutli ; martin 

Cc: crm-sig 
Subject: Re: [Crm-sig] Using multiple instantiation

 

 

I agree that it’s very dense, but also very informative! 

 

A shorter version might check both boxes – informative to folks that are more 
used to programming or traditional data management platforms, and instructive 
on how to work around their limitations?

 

For example, something as short as the following might be sufficient:

 

The CRM can be implemented in RDF using a technique called “multiple 
instantiation”.  This means that instances would participate in the IsA 
relationship (rdf:type) multiple times, thereby instantiating multiple classes 
at the same time. In the abstract model this is very appropriate, as an 
instance can very legitimately be thought of as an Appellation and a Linguistic 
Object at the same time in the case of a name that is in a human language. 
However, many implementations at their core are not natively RDF or even 
graph-based and would run into difficulties trying to create relationship 
representations or classes in an object oriented programming language that 
instantiated multiple ontological classes.  Instead, the projection from the 
abstract CRM into RDF includes artificial “merge” classes such as 
E41_E33_Linguistic_Appellation when use cases are sufficient to demonstrate the 
value of these constructions.  Use of these artificial classes is intended for 
situations where the implementation is a challenge, rather than being an 
ontologically rigorous pattern.

 

 

Rob

 

From: Crm-sig mailto:crm-sig-boun...@ics.forth.gr> > on behalf of Florian Kräutli 
mailto:fkraeu...@mpiwg-berlin.mpg.de> >
List-Post: crm-sig@ics.forth.gr
Date: Friday, December 7, 2018 at 1:04 AM
To: martin mailto:mar...@ics.forth.gr> >
Cc: crm-sig mailto:crm-sig@ics.forth.gr> >
Subject: Re: [Crm-sig] Using multiple instantiation

 

Hi Martin, 

 

I agree with the previous comments that the text is a bit dense and assumes a 
quite specific prior knowledge, i.e. it might be confusing to include it as a 
general guideline.

 

When I started with the CRM however, I somehow refrained from doing multiple 
instantiation. I don't think it is actively discouraged anywhere, but I was 
under the impression that I should rather find a more fitting entity than 
'overloading' one with several classes. So an indication that multiple 
instantiation can be ok, and a set of examples of where it makes sense might be 
useful to include somewhere. 

 

The example of using E33 to reach P72 is a good one I think. I also use it 
together with F22.

 

Best,

 

Florian

 

On 6. Dec 2018, at 18:37, Martin Doerr mailto:mar...@ics.forth.gr> > wrote:

 

Right. It is very dense. I tried to justify multiple instantiation in the same 
text and give practical advice. I am not sure who finds it an issue. In the 
principles of the CRM we describe it again, but may be here it would be useful 
just to make people aware of it, and make an example in the Annex. Or omit 
allover. 

 

Opinions?

 

Martin

 

On 12/6/2018 12:55 AM, van Leusen, P.M. wrote:

Hi Martin, 

Not sure if you would regard me as a typical reader, but I find this text very 
hard to read and understand without having at least one good worked example to 
guide me through it. It presupposes so much specialised knowledge about the 
various types of data management and knowledge organisation systems that, in 
its current state, only a small group of specialists might find it useful...

Martijn

 

On Wed, Dec 5, 2018 at 11:13 PM Martin Doerr mailto:mar...@ics.forth.gr> > wrote:

This was a proposal by Robert :-). It may be useful for implementers not used 
to semantic technologies.

 

What do other people think?

 

On 12/5/2018 6:54 PM, Richard Light wrote:

Martin,

Please explain why you think that this text is needed in the RDF implementation 
guidelines. To me, it seems quite generic, and doesn't offer specific guidance 
as to what implementors should do about the issue that their existing systems 
may be incapable of expressing certain RDF features. I think it would actually 
detract from the usefulness of the document, because it would confuse and 
puzzle the typical reader.  [Maybe we need to stop and think about who the 
'typical reader' would be, and what they would want from this document.]

Richard

On 05/12/201

Re: [Crm-sig] Using multiple instantiation

[Robert Sanderson]

I agree that it’s very dense, but also very informative!

A shorter version might check both boxes – informative to folks that are more 
used to programming or traditional data management platforms, and instructive 
on how to work around their limitations?

For example, something as short as the following might be sufficient:

The CRM can be implemented in RDF using a technique called “multiple 
instantiation”.  This means that instances would participate in the IsA 
relationship (rdf:type) multiple times, thereby instantiating multiple classes 
at the same time. In the abstract model this is very appropriate, as an 
instance can very legitimately be thought of as an Appellation and a Linguistic 
Object at the same time in the case of a name that is in a human language. 
However, many implementations at their core are not natively RDF or even 
graph-based and would run into difficulties trying to create relationship 
representations or classes in an object oriented programming language that 
instantiated multiple ontological classes.  Instead, the projection from the 
abstract CRM into RDF includes artificial “merge” classes such as 
E41_E33_Linguistic_Appellation when use cases are sufficient to demonstrate the 
value of these constructions.  Use of these artificial classes is intended for 
situations where the implementation is a challenge, rather than being an 
ontologically rigorous pattern.


Rob

From: Crm-sig  on behalf of Florian Kräutli 

Date: Friday, December 7, 2018 at 1:04 AM
To: martin 
Cc: crm-sig 
Subject: Re: [Crm-sig] Using multiple instantiation

Hi Martin,

I agree with the previous comments that the text is a bit dense and assumes a 
quite specific prior knowledge, i.e. it might be confusing to include it as a 
general guideline.

When I started with the CRM however, I somehow refrained from doing multiple 
instantiation. I don't think it is actively discouraged anywhere, but I was 
under the impression that I should rather find a more fitting entity than 
'overloading' one with several classes. So an indication that multiple 
instantiation can be ok, and a set of examples of where it makes sense might be 
useful to include somewhere.

The example of using E33 to reach P72 is a good one I think. I also use it 
together with F22.

Best,

Florian

On 6. Dec 2018, at 18:37, Martin Doerr 
mailto:mar...@ics.forth.gr>> wrote:

Right. It is very dense. I tried to justify multiple instantiation in the same 
text and give practical advice. I am not sure who finds it an issue. In the 
principles of the CRM we describe it again, but may be here it would be useful 
just to make people aware of it, and make an example in the Annex. Or omit 
allover.

Opinions?

Martin

On 12/6/2018 12:55 AM, van Leusen, P.M. wrote:
Hi Martin,
Not sure if you would regard me as a typical reader, but I find this text very 
hard to read and understand without having at least one good worked example to 
guide me through it. It presupposes so much specialised knowledge about the 
various types of data management and knowledge organisation systems that, in 
its current state, only a small group of specialists might find it useful...
Martijn

On Wed, Dec 5, 2018 at 11:13 PM Martin Doerr 
mailto:mar...@ics.forth.gr>> wrote:
This was a proposal by Robert :-). It may be useful for implementers not used 
to semantic technologies.

What do other people think?

On 12/5/2018 6:54 PM, Richard Light wrote:
Martin,
Please explain why you think that this text is needed in the RDF implementation 
guidelines. To me, it seems quite generic, and doesn't offer specific guidance 
as to what implementors should do about the issue that their existing systems 
may be incapable of expressing certain RDF features. I think it would actually 
detract from the usefulness of the document, because it would confuse and 
puzzle the typical reader.  [Maybe we need to stop and think about who the 
'typical reader' would be, and what they would want from this document.]
Richard
On 05/12/2018 16:05, Martin Doerr wrote:
Dear All,
I propose this paragraph to be added to the implementation guidelines for RDFS:
"About implementing multiple Instantiation
Knowledge representation models and more generally semantic networks differ 
fundamentally in one aspect from data structures, such as XML, Relational 
database schemata and data structures in all programming languages, including 
the object-oriented one:

•   Knowledge representation starts with an item in the real world 
regardless its nature, assigns an identifier to it in order to be able to make 
assertions about it, and then accumulates statements (assertions, propositions) 
about it.

•   Data structures start with a set of templates, a set of foreseen kinds 
of statements dedicated to a particular category each (class, entity), to be 
filled in by a user.


Consequently, knowledge representation may assign multiple classes to a given 
identifier without any problem. The asso

Re: [Crm-sig] Using multiple instantiation

[Florian Kräutli]

Hi Martin,

I agree with the previous comments that the text is a bit dense and assumes a 
quite specific prior knowledge, i.e. it might be confusing to include it as a 
general guideline.

When I started with the CRM however, I somehow refrained from doing multiple 
instantiation. I don't think it is actively discouraged anywhere, but I was 
under the impression that I should rather find a more fitting entity than 
'overloading' one with several classes. So an indication that multiple 
instantiation can be ok, and a set of examples of where it makes sense might be 
useful to include somewhere. 

The example of using E33 to reach P72 is a good one I think. I also use it 
together with F22.

Best,

Florian

> On 6. Dec 2018, at 18:37, Martin Doerr  wrote:
> 
> Right. It is very dense. I tried to justify multiple instantiation in the 
> same text and give practical advice. I am not sure who finds it an issue. In 
> the principles of the CRM we describe it again, but may be here it would be 
> useful just to make people aware of it, and make an example in the Annex. Or 
> omit allover. 
> 
> Opinions?
> 
> Martin
> 
> On 12/6/2018 12:55 AM, van Leusen, P.M. wrote:
>> Hi Martin,
>> Not sure if you would regard me as a typical reader, but I find this text 
>> very hard to read and understand without having at least one good worked 
>> example to guide me through it. It presupposes so much specialised knowledge 
>> about the various types of data management and knowledge organisation 
>> systems that, in its current state, only a small group of specialists might 
>> find it useful...
>> Martijn
>> 
>> On Wed, Dec 5, 2018 at 11:13 PM Martin Doerr > > wrote:
>> This was a proposal by Robert :-). It may be useful for implementers not 
>> used to semantic technologies.
>> 
>> What do other people think?
>> 
>> On 12/5/2018 6:54 PM, Richard Light wrote:
>>> Martin,
>>> 
>>> Please explain why you think that this text is needed in the RDF 
>>> implementation guidelines. To me, it seems quite generic, and doesn't offer 
>>> specific guidance as to what implementors should do about the issue that 
>>> their existing systems may be incapable of expressing certain RDF features. 
>>> I think it would actually detract from the usefulness of the document, 
>>> because it would confuse and puzzle the typical reader.  [Maybe we need to 
>>> stop and think about who the 'typical reader' would be, and what they would 
>>> want from this document.]
>>> Richard
>>> On 05/12/2018 16:05, Martin Doerr wrote:
 Dear All,
 
 I propose this paragraph to be added to the implementation guidelines for 
 RDFS:
 
 "About implementing multiple Instantiation
 
 Knowledge representation models and more generally semantic networks 
 differ fundamentally in one aspect from data structures, such as XML, 
 Relational database schemata and data structures in all programming 
 languages, including the object-oriented one:
 
 ·   Knowledge representation starts with an item in the real world 
 regardless its nature, assigns an identifier to it in order to be able to 
 make assertions about it, and then accumulates statements (assertions, 
 propositions) about it.
 
 ·   Data structures start with a set of templates, a set of foreseen 
 kinds of statements dedicated to a particular category each (class, 
 entity), to be filled in by a user.
 
  
 Consequently, knowledge representation may assign multiple classes to a 
 given identifier without any problem. The associated processing software 
 will then allow for asserting for this identifier all properties 
 applicable to each assigned class. This process is called “multiple 
 instantiation. For instance, the “weapon” with all its characteristics may 
 also be a “ceremonial object”.
 
  
 A system based on data structures must create a different instance of the 
 respective templates for each class an item belongs to. It may later the 
 link the different instances describing aspects of the same thing, in 
 order to simulate the mechanism. In particular the very successful 
 “encapsulation principle” of object-oriented programming languages 
 requires dedicated data structures and constitutes a fundamental mismatch 
 with the Open-World modeling of semantic relationships (see, for instance 
 Schnase 1993). Fundamental to semantic data integration are also 
 superproperties, which are not provided by data structures either.
 
  
 The CRM as ontology relies heavily on multiple instantiation: Classes that 
 use to co-occur on things simultaneously “incidentally”, without being 
 associated with properties only applicable to the combination of such 
 classes, are not modelled individually as subclasses of multiple parent 
 classes. The latter would be called “multiple IsA”. To avoid 

Re: [Crm-sig] Using multiple instantiation

[van Leusen, P.M.]

Hi Martin,
Not sure if you would regard me as a typical reader, but I find this text
very hard to read and understand without having at least one good worked
example to guide me through it. It presupposes so much specialised
knowledge about the various types of data management and knowledge
organisation systems that, in its current state, only a small group of
specialists might find it useful...
Martijn

On Wed, Dec 5, 2018 at 11:13 PM Martin Doerr  wrote:

> This was a proposal by Robert :-). It may be useful for implementers not
> used to semantic technologies.
>
> What do other people think?
>
> On 12/5/2018 6:54 PM, Richard Light wrote:
>
> Martin,
>
> Please explain why you think that this text is needed in the RDF
> implementation guidelines. To me, it seems quite generic, and doesn't offer
> specific guidance as to what implementors should do about the issue that
> their existing systems may be incapable of expressing certain RDF features.
> I think it would actually detract from the usefulness of the document,
> because it would confuse and puzzle the typical reader.  [Maybe we need to
> stop and think about who the 'typical reader' would be, and what they would
> want from this document.]
>
> Richard
> On 05/12/2018 16:05, Martin Doerr wrote:
>
> Dear All,
>
> I propose this paragraph to be added to the implementation guidelines for
> RDFS:
>
> "*About implementing multiple Instantiation*
>
> Knowledge representation models and more generally semantic networks
> differ fundamentally in one aspect from data structures, such as XML,
> Relational database schemata and data structures in all programming
> languages, including the object-oriented one:
>
> ·   Knowledge representation starts with an item in the real world
> regardless its nature, assigns an identifier to it in order to be able to
> make assertions about it, and then accumulates statements (assertions,
> propositions) about it.
>
> ·   Data structures start with a set of templates, a set of foreseen
> kinds of statements dedicated to a particular category each (class,
> entity), to be filled in by a user.
>
>
>
> Consequently, knowledge representation may assign multiple classes to a
> given identifier without any problem. The associated processing software
> will then allow for asserting for this identifier all properties applicable
> to each assigned class. This process is called “multiple instantiation. For
> instance, the “weapon” with all its characteristics may also be a
> “ceremonial object”.
>
>
>
> A system based on data structures must create a different instance of the
> respective templates for each class an item belongs to. It may later the
> link the different instances describing aspects of the same thing, in order
> to simulate the mechanism. In particular the very successful “encapsulation
> principle” of object-oriented programming languages requires dedicated data
> structures and constitutes a fundamental mismatch with the Open-World
> modeling of semantic relationships (see, for instance Schnase 1993).
> Fundamental to semantic data integration are also superproperties, which
> are not provided by data structures either.
>
>
>
> The CRM as ontology relies heavily on multiple instantiation: Classes that
> use to co-occur on things simultaneously “incidentally”, without being
> associated with properties only applicable to the combination of such
> classes, are not modelled 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.
>
>
>
> Most implementations on top of RDF still use RDF as if it were a fixed
> schema and repeat in the UI code all the schema. Therefore, the promise of
> RDF and other semantic models to be able to accommodate dynamically new
> properties often does not work. It is still as if they were using
> Relational systems. Generic XML editors do adapt already to the schema, but
> usually the rendering paradigms they employ, without additional parameters,
> are too poor for good UI code. One can however write code that reads the
> RDF schema used at run-time and that extends data entry and display by the
> actual properties found. This functionality is foreseen by SPARQL, but most
> programmers still do not appreciate the utility of querying the schema.
> Even if fixed templates are used, the data entry system should foresee the
> same thing to be described by multiple templates, relatively freely
> selectable by the user.
>
>
>
> 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. It may be useful to develop
> tools for specific guidance that show users how a valid path from a given
> domain class to a certain range class can be created by using multiple
> instantiation (and, by 

Re: [Crm-sig] Using multiple instantiation

[Martin Doerr]

This was a proposal by Robert :-). It may be useful for implementers not 
used to semantic technologies.


What do other people think?

On 12/5/2018 6:54 PM, Richard Light wrote:


Martin,

Please explain why you think that this text is needed in the RDF 
implementation guidelines. To me, it seems quite generic, and doesn't 
offer specific guidance as to what implementors should do about the 
issue that their existing systems may be incapable of expressing 
certain RDF features. I think it would actually detract from the 
usefulness of the document, because it would confuse and puzzle the 
typical reader.  [Maybe we need to stop and think about who the 
'typical reader' would be, and what they would want from this document.]


Richard

On 05/12/2018 16:05, Martin Doerr wrote:


Dear All,

I propose this paragraph to be added to the implementation guidelines 
for RDFS:


"*About implementing multiple Instantiation*

Knowledge representation models and more generally semantic networks 
differ fundamentally in one aspect from data structures, such as XML, 
Relational database schemata and data structures in all programming 
languages, including the object-oriented one:


·Knowledge representation starts with an item in the real world 
regardless its nature, assigns an identifier to it in order to be 
able to make assertions about it, and then accumulates statements 
(assertions, propositions) about it.


·Data structures start with a set of templates, a set of foreseen 
kinds of statements dedicated to a particular category each (class, 
entity), to be filled in by a user.


Consequently, knowledge representation may assign multiple classes to 
a given identifier without any problem. The associated processing 
software will then allow for asserting for this identifier all 
properties applicable to each assigned class. This process is called 
“multiple instantiation. For instance, the “weapon” with all its 
characteristics may also be a “ceremonial object”.


A system based on data structures must create a different instance of 
the respective templates for each class an item belongs to. It may 
later the link the different instances describing aspects of the same 
thing, in order to simulate the mechanism. In particular the very 
successful “encapsulation principle” of object-oriented programming 
languages requires dedicated data structures and constitutes a 
fundamental mismatch with the Open-World modeling of semantic 
relationships (see, for instance Schnase 1993). Fundamental to 
semantic data integration are also superproperties, which are not 
provided by data structures either.


The CRM as ontology relies heavily on multiple instantiation: Classes 
that use to co-occur on things simultaneously “incidentally”, without 
being associated with properties only applicable to the combination 
of such classes, are not modelled 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.


Most implementations on top of RDF still use RDF as if it were a 
fixed schema and repeat in the UI code all the schema. Therefore, the 
promise of RDF and other semantic models to be able to accommodate 
dynamically new properties often does not work. It is still as if 
they were using Relational systems. Generic XML editors do adapt 
already to the schema, but usually the rendering paradigms they 
employ, without additional parameters, are too poor for good UI code. 
One can however write code that reads the RDF schema used at run-time 
and that extends data entry and display by the actual properties 
found. This functionality is foreseen by SPARQL, but most programmers 
still do not appreciate the utility of querying the schema. Even if 
fixed templates are used, the data entry system should foresee the 
same thing to be described by multiple templates, relatively freely 
selectable by the user.


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. It may be 
useful to develop tools for specific guidance that show users how a 
valid path from a given domain class to a certain range class can be 
created by using multiple instantiation (and, by the way, also by 
using subclasses of the domain class), such as combining /E41 
Appellation/ with /E33 Linguistic Object/ in order to reach /E56 
Language/ via /P72 has language./


In a local system, another workaround for multiple instantiation can 
be the creation of classes that replace all candidate cases for 
multiple instantiation by subclasses using multiple IsA. For good 
reasons, the compatibility with the CRM is defined at the 
import/export/query level and not at the system internals. Therefore, 
such internal workarounds do not affect the interoperability: Whereas 

Re: [Crm-sig] Using multiple instantiation

[Richard Light]

Martin,

Please explain why you think that this text is needed in the RDF implementation 
guidelines. To me, it seems quite generic, and doesn't offer specific guidance 
as to what implementors should do about the issue that their existing systems 
may be incapable of expressing certain RDF features. I think it would actually 
detract from the usefulness of the document, because it would confuse and 
puzzle the typical reader.  [Maybe we need to stop and think about who the 
'typical reader' would be, and what they would want from this document.]

Richard

On 05/12/2018 16:05, Martin Doerr wrote:

Dear All,

I propose this paragraph to be added to the implementation guidelines for RDFS:

"About implementing multiple Instantiation
Knowledge representation models and more generally semantic networks differ 
fundamentally in one aspect from data structures, such as XML, Relational 
database schemata and data structures in all programming languages, including 
the object-oriented one:

·   Knowledge representation starts with an item in the real world 
regardless its nature, assigns an identifier to it in order to be able to make 
assertions about it, and then accumulates statements (assertions, propositions) 
about it.

·   Data structures start with a set of templates, a set of foreseen kinds 
of statements dedicated to a particular category each (class, entity), to be 
filled in by a user.



Consequently, knowledge representation may assign multiple classes to a given 
identifier without any problem. The associated processing software will then 
allow for asserting for this identifier all properties applicable to each 
assigned class. This process is called “multiple instantiation. For instance, 
the “weapon” with all its characteristics may also be a “ceremonial object”.



A system based on data structures must create a different instance of the 
respective templates for each class an item belongs to. It may later the link 
the different instances describing aspects of the same thing, in order to 
simulate the mechanism. In particular the very successful “encapsulation 
principle” of object-oriented programming languages requires dedicated data 
structures and constitutes a fundamental mismatch with the Open-World modeling 
of semantic relationships (see, for instance Schnase 1993). Fundamental to 
semantic data integration are also superproperties, which are not provided by 
data structures either.



The CRM as ontology relies heavily on multiple instantiation: Classes that use 
to co-occur on things simultaneously “incidentally”, without being associated 
with properties only applicable to the combination of such classes, are not 
modelled 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.



Most implementations on top of RDF still use RDF as if it were a fixed schema 
and repeat in the UI code all the schema. Therefore, the promise of RDF and 
other semantic models to be able to accommodate dynamically new properties 
often does not work. It is still as if they were using Relational systems. 
Generic XML editors do adapt already to the schema, but usually the rendering 
paradigms they employ, without additional parameters, are too poor for good UI 
code. One can however write code that reads the RDF schema used at run-time and 
that extends data entry and display by the actual properties found. This 
functionality is foreseen by SPARQL, but most programmers still do not 
appreciate the utility of querying the schema. Even if fixed templates are 
used, the data entry system should foresee the same thing to be described by 
multiple templates, relatively freely selectable by the user.



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. It may be useful to develop tools for 
specific guidance that show users how a valid path from a given domain class to 
a certain range class can be created by using multiple instantiation (and, by 
the way, also by using subclasses of the domain class), such as combining E41 
Appellation with E33 Linguistic Object in order to reach E56 Language via P72 
has language.



In a local system, another workaround for multiple instantiation can be the 
creation of classes that replace all candidate cases for multiple instantiation 
by subclasses using multiple IsA. For good reasons, the compatibility with the 
CRM is defined at the import/export/query level and not at the system 
internals. Therefore, such internal workarounds do not affect the 
interoperability: Whereas the query compatibility of this solution with the 
standard is immediate, the respective import/export system simply needs to make 
the trivial replacements of the respective class