Dear Martin, Well I am curious to know if I am the only one who finds this property useful at a high level for describing humans related to CH (presumably an important factor), or if I have truly not understood something. So some comments below.
> The first principle of all is are there relevant queries that need that > property for integrating disparate sources, which indeed provide such data, > and is that research one we like to support with the CRM? > > Second, using p2 on E21 does the job, doesn't it? What is the added value > of "knows language"? > > The has type solution has the following problem. E21 p2 has type E56 Language does not work It does not work because no E21 is a language. But we have already set off as a major category of documentation in the CRM an entire class for languages. It is called E56. So one would expect information around language to aggregate around... language or E56. The solution: E21 p2 has type E55 English Speakers is not satisfactory because you cannot make any connection between the type E55 English Speaker and any instance of language. You would have to model this relation, which would be an indirection, which would make a simple query people generally might want to make in a cultural heritage system difficult to make. E21 knows language E56 http://vocab.getty.edu/page/aat/300388277 would allow the user to connect some instance of E21 to E56 in a semantically clear way and that instance of E56 would be the same one they would use for talking about other objects in the graphs, thus aiding reasoning and helping in connecting things. > > > Next principle, keep the ontology small. Querying 1000 properties is > already more than anybody can keep in mind. Each additional property has an > implementation cost. We need strong arguments for relevance. > > It has been the mos t important success factor of the CRM to keep the > ontology small and still expressive enough. If we loose this discipline, we > will loose the whole project. > > In CRM Sig we decided to create a new extension CRMSoc in order to document social factors. I have proposed to put this new property here (though it is so general a type of information this could be argued). Presently we have as primary properties of actors 'contact point'. How, in a non arbitrary way, is this more or less general than language? It is a typical piece of information that one may know about an individual that can be useful in querying your data. Especially in a time of great interest in identity, knowing the variables that are pertinent to the actors related to CH collections does not seem very esoteric. > > Finally, we are not repeating in the CRM the way typically information > systems document, but always tried to find a more fundamental > representation. With that argument, we could never have introduced events. > They did NOT appear in any of the typical systems at that time. It is a > principle *not *to model all the valuable description elements, which are > relevant to characterize an item, but not creating interesting links across > resources. > > The proposal of 'knows language' is to follow yet another principle, model bottom up. So indeed, I would not rush to add 'has knowledge' because we don't know what that is, but we certainly do have a good enough mesoscopic understanding of what it means for someone to know a language (in the same rough and ready way we speak of somethign consisting of a material). Of course this could be specialized for highly specific anthropological studies, but this does not fall into a use case I am aware of. Almost any good CH database I have modelled that has information about the people related to the collection does document this. I agree we can't add any property for our pleasure, but this is really fundamental documentation, not at all on the sidelines of the information space we are talking about. It is equivalent to saying an object has a material. The people doing CH fall in scope and that they know a language is as fundamental as that. About the structure of building the model, of course we should not have it reflect the systems. The principle I refer to is the principle that we have to model at the level of knowledge that is typically available. That is why CRM has shortcuts and allows multiple levels of description given what is known by the user. So we do not force everything to go through an event when we know that typically such thing will not be known (but may in principle be). So it would be great to imagine also the 'language acquistion' node which is the moment(s?) of acquiring a language which would pertain to a very specific field of study. But for the CH information system, we do know that somebody knew a langauge and it is valuable to the overall study and so, unclear to me why not necessary. Introducing 'knows language' introduces interesting links between resources...see above. > > I did not say that it is a personal opinion that someone speaks a > language. I said, this is observable. I document: Franco has spoken Latin, > repeatedly? But talking about skills, is another level, it introduces a > quality, which is hard to objectify, as Franco has pointed out. Actually, > it is a typical classification problem, with all its boundary case > questions, and the CRM is about relations between particulars. > > So, what is the* added value* against p2, and what are the typical > research data and typical research questions for *integrating* such data, > that cannot be answered with P2? > > It would be difficult for me to generate all the potential research questions that people may want to do based on knowing the languages that people related to cultural heritage objets through events might want to perform. Again, identity studies are very large, today. You may want to know the number of English knowers vs Greek knowers in digs at different periods in the history of archaeological research. You may want to try to see patterns in collections related to speakers of X as opposed to speakers of Y language. You may want to know who at a certain time in your graph may have been able to read a book from that graph. I struggle to see the esoteric ness of the proposal and do see how it fits to the modelling principles we elaborated. Best, George > > Best, > > martin > > > > > On 10/14/2019 4:24 PM, George Bruseker wrote: > > Dear Martin, > > Which is CEO’s proposition that you support? It gets lost in the string. > Do you mean that a) a person speaking a language means being part of a > group, or b) using the p2 on E21 and then make types for ’Speakers of...' > > I am (still and very much ) a supporter of a new property ‘knows > language'. I do not think that the group solution works because of the > identify criteria of groups. I also don’t think the event solution is > necessary (another suggestion that has floated in this conversation). It is > often the case that for person we do not know events of their acquisition > or use of language or a skill but we do have proposition that they had that > language or skill! I also don’ t support the ‘English Speakers’ type > solution since it provides a different URI than the URI for ‘English’ and > forces more, obscure, modelling. > > Another CIDOC CRM principle is model at the level of knowledge that is > typically present in information systems. Again, I think the present case > (people know languages) is identical to the case of > > E22 consists of E57 Material > > This is a typical piece of knowledge held about an object. It would be > obtuse to insist that one should create an event node to indicate the > manner of this material becoming the constituting material of the object > when we don’t know this fact. This is why CRM represents such binary > relations, because they are real, they are a level of knowledge and they > are observable. > > If someone has entered into an information system George: English, Pot > Making, it is unlikely that what they want to reconstruct are instances of > me using English or performing Pot making. Rather they are interested that > there is an individual which has a particular formation which means that he > knows language x, knows skill x. This information is probably used in an > actual integration to connect an instance of E21 via an instance of E57 > Language to for example E33 that use the same E57. > > It would seem we need some sort of hierarchy in the principles which can > also be conflicting. > > > My approach is not documenting skills*.* My approach is documenting > facts, rather than potentials. I take notice and may document that you > spoke Latin, as I have done last time at school. I have a document stating > my grade in Latin at high school. My grade at high school confirms a set > of years of continued successful lessons, not that I could understand much > Latin now;-). > Speaking a language can be documented as an extended (observed) activity, > as in FRBRoo. > > > It may be, but is it typically? I have never seen an information system, > especially in museum context that would. > > For instance, someone writing books in particular language. This falls > under any kind of extended activity not further specified, such as an > artist using a technique for some time, and avoids transforming actual > activities into potentials. > > We can document someone's documented opinion about a potential of a > person, as an information object. > > > That would make this information mostly unusable however. If our goal is > to functionally use the observation person x speaks language y, then it > needs to be semantically represented and not made a string. > > > In the "Principles for Modelling Ontologies" we refer: > "7.2 Avoid concepts depending on a personal/ spectator perspective" > > This could be elaborated more. In the CRM, we do not model concepts > "because people use them", but because they can be used to integrated > information related to them with URIs. Therefore, your arguments and what > I wanted to say is, "skill" is a bad concept for integration. What should > be instantiated are the observable activities, which may or may not > indicate skills. > > > I don’t see that this principle applies. It is not a personal perspective > that someone speaks a language, anymore than it is a personal perspective > that an object is constituted of a material. This fact can be documented > and observed. Someone else can come and do the same. Don’t believe Franco > can speak Latin? Watch him and see if he can. When someone writes in an > information system, they probably typically mean, some evidence leads me to > assert Person y knows language y. They do not mean to say at some point in > the past he learned it, or at some point he performed it. > > In the case of documenting that someone knows a language this can be used > practically to integrate using URIs just in case we use the same URI for > English that we use to describe a document and that we use to describe the > knowledge of the individual > > E21 knows language E57 Language URI:AA > E33 has language E57 Language URI:AA > > answers the query, who in this graph knew the language this document was > written in. > > Functionally, the issue for me is, is there a good reason against adding > a binary property off of person which can indicate their knowledge ability > and connect to a well known URI for a language. > > Best, > > George > > > -- > ------------------------------------ > 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 > > > _______________________________________________ > Crm-sig mailing > listCrm-sig@ics.forth.grhttp://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 > Web-site: http://www.ics.forth.gr/isl > > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig >
