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
