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 <[email protected]> on behalf of Detlev Balzer <[email protected]> Sent: 11 December 2018 12:16 To: [email protected] 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 [email protected] <mailto:[email protected]> >> >> LinkedIn Profile https://www.linkedin.com/in/steads/ >> >> >> >> *From:*Crm-sig <[email protected]> *On Behalf Of *Robert Sanderson >> *Sent:* 10 December 2018 17:52 >> *To:* Florian Kräutli <[email protected]>; martin >> <[email protected]> >> *Cc:* crm-sig <[email protected]> >> *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 <[email protected] >> <mailto:[email protected]>> on behalf of Florian Kräutli >> <[email protected] <mailto:[email protected]>> >> *Date: *Friday, December 7, 2018 at 1:04 AM >> *To: *martin <[email protected] <mailto:[email protected]>> >> *Cc: *crm-sig <[email protected] <mailto:[email protected]>> >> *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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 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 combinations with their multiple IsA >> counterparts and vice-versa. >> >> >> >> So, partially, problems with multiple instantiation are >> a question of programming practice. On the other side, it is also a question >> of user training and extended good practice. 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." >> >> John L. Schnase, (1993). "Semantic Data Modelling of >> Hypermedia Associations", in: ACM Transactions on Information Systems, >> Vol.11,No.1, January 1993, p 45. >> >> Comments welcome! >> >> 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] <mailto:[email protected]> >> >> Web-site: http://www.ics.forth.gr/isl >> >> >> >> _______________________________________________ >> >> Crm-sig mailing list >> >> [email protected] <mailto:[email protected]> >> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> -- >> *Richard Light* >> >> >> >> _______________________________________________ >> >> Crm-sig mailing list >> >> [email protected] <mailto:[email protected]> >> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> -- >> >> ------------------------------------ >> >> 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] <mailto:[email protected]> >> >> Web-site: http://www.ics.forth.gr/isl >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> >> -- >> >> Dr. Martijn van Leusen >> >> Associate professor, Landscape Archaeology, Groningen Institute of >> Archaeology >> >> Poststraat 6, 9712ER Groningen (Netherlands) / phone +31 50 3636717 >> >> Chair, Examination Board for Arts, Culture and Archaeology / Chair, >> Faculty of Arts Advisory Board for Data Management policies >> >> Academia page <https://rug.academia.edu/MartijnvanLeusen> >> >> >> >> -- >> >> ------------------------------------ >> >> 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] <mailto:[email protected]> >> >> Web-site: http://www.ics.forth.gr/isl >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- > *Richard Light* > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233 PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7 _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
