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 <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 <mar...@ics.forth.gr >> <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 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: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> >>>> Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> >>>> >>>> >>>> _______________________________________________ >>>> Crm-sig mailing list >>>> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>> <http://lists.ics.forth.gr/mailman/listinfo/crm-sig> >>> -- >>> Richard Light >>> >>> >>> _______________________________________________ >>> Crm-sig mailing list >>> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>> <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: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> >> Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> <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: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> > Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
