Re: [Crm-sig] A hoard as crm:E78_Collection ?
On 1/12/2014 9:47 μμ, Simon Spero wrote: I'm not entirely sure that this is the right reading of Wickett et. al.; the issue seems that in the CRM, roles are conflated, or at least fused. That is the intention. The CRM should cover things by reasonable generalizations. It is not directly an ontology for the archival world. Specializations should be possible, that should not require to invalidate "fused" roles that provide better recall. Would that make sense? Best, Martin -- -- Dr. Martin Doerr | Vox:+30(2810)391625| Research Director | Fax:+30(2810)391638| | Email: mar...@ics.forth.gr | | 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 | | Web-site: http://www.ics.forth.gr/isl | --
Re: [Crm-sig] A hoard as crm:E78_Collection ?
Dear Dan, On 1/12/2014 7:26 ??, Dan Matei wrote: My main criterion (not always explicit !) to use one property or other is not the query (dis)ambiguity, but the facility of the semantic reasoning, i.e. inference. Am I wrong ? I'd regard this as secondary application. Many reasoning applications need to narrow the world down, which often comes in direct conflict conflict with the recall of a global query. If that happens, search has preference over expressive power. Of course, reasoning can also increase recall. Then it is preferable. In other words, imagine a global network of knowledge. The idea is, if I cannot get all facts possibly relevant to my research question, I need to worry about drawing deep conclusions from the rest. Once we have solved that, then we can go into the next round of reasoning services. That may be a CRM extension, but I'd argue not the CRM itself. So, my feeling (not more than that) is that the reasoner is helped if crm:Py_is_component_of suggests that the subject of the assertion is a thing "functional" in itself, vs. crm:P46i_forms_part_of that suggests otherwise. If that would be the case, we would need an example in which the same thing can be integrated in one thing as functional component, and in another as non-functional, and the distinction is so frequent, that we would be confused by too many answers otherwise. But, feeling is not enough for the CRM ;-) . We always require enough real data to demonstrate the need. Of course, we are all free to make extensions for particular applications. So, what is reasonable for an application, may not be relevant enough to increase an ISO standard :-) . Anyway always good to think things through... All the best, Martin -- -- Dr. Martin Doerr | Vox:+30(2810)391625| Research Director | Fax:+30(2810)391638| | Email: mar...@ics.forth.gr | | 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 | | Web-site: http://www.ics.forth.gr/isl | --
Re: [Crm-sig] A hoard as crm:E78_Collection ?
I'm not entirely sure that this is the right reading of Wickett et. al.; the issue seems that in the CRM, roles are conflated, or at least fused. It is a plausible reading that donating a private collection to an archive must cause the identity of the collection to change (with the archival collection being a derivative, (possibly improper) sub-collection of the donated collection. This could be the case if the intensional definition of the collection as received by the archive necessarily includes the identity of the donor (though presumably the indexing, once resolved, would not require the identity of the collection to change if transferred to another institution). It could also be the case if the collection policy /plan is an identity criterion, and necessarily changes when the curator changes. However this reading would seem to require any change in policy or plan to form a new intensional collection, even if the change in policy is one that a priori cannot change the contents or description of the former collection (e.g an institution wide policy requiring that "all unicorns will be stored in vibranium edged boxes"). Since I am rarely on the "same" page as Karen wrt identity I'm checking with the editor :-) Simon On Nov 30, 2014 11:19 AM, "martin" wrote: > Dear Simon, > > This is an interesting discussion. Preserving things others have collected > has been described as > "SECONDARY COLLECTOR CONTEXT" and is well distinguished in archival > practice to my knowledge. > See also: > https://www.ideals.illinois.edu/bitstream/handle/2142/45860/EDM-DCC_Whitepaper_Final20131009.pdf?sequence=3 > The case had been discussed when we defined E78. The "collection in the > collection" can either be > seen as one object in a collection, or, if incompletely acquired , the > secondary collection plan can be to acquire the missing parts to the > original collection, or, to continue the primary collector's plan. In any > case, the original collector was a curator to the collection. > > All the best, > > Martin > > On 29/11/2014 11:57 μμ, Simon Spero wrote: > > The definition of Collection possibly overly restrictive, even from an > archival point of view. > > An collection of records will probably have been assembled by a different > agent to the curator; materials may be discarded as "not archival", but if > the fonds gets respect, the curator is not free to do much assembling. > > It is possible to finesse this by a sufficiently broad reading of "plan", > but it seems as if the roles of assembling curating/preserving are > intrinsically linked in the CRM (I ought to take a look at the old EAD > mapping) . > > Simon > On Nov 29, 2014 3:32 PM, "Stephen Stead" wrote: > >> Martin >> >> The problem probably lies in the word “Collection”! Everyone reads that >> and thinks that the defining characteristic is the act of collecting rather >> than the true differentiator which is the curation. >> >> Perhaps changing the name to “E78 Curated Set” would solve the problem. >> Nobody would know what it meant and so would read the scope note >> >> TTFN >> >> SdS >> >> >> >> Stephen Stead >> >> Tel +44 20 8668 3075 <%2B44%2020%208668%203075> >> >> Mob +44 7802 755 013 <%2B44%207802%20755%20013> >> >> E-mail ste...@paveprime.com >> >> LinkedIn Profile http://uk.linkedin.com/in/steads >> >> >> >> *From:* Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] *On Behalf Of * >> martin >> *Sent:* 29 November 2014 19:07 >> *To:* crm-sig@ics.forth.gr >> *Subject:* Re: [Crm-sig] A hoard as crm:E78_Collection ? >> >> >> >> Continuing: >> >> I don't know, why E78 Collection attracts so much attention. The scope >> note of >> E19 Physical Object says: >> >> "The class also includes all aggregates of objects made for functional >> purposes of whatever kind, independent of physical coherence, such as a set >> of chessmen. Typically, instances of E19 Physical Object can be moved (if >> not too heavy)." >> >> >> The CRM is not a terminological system to classify things. It is made to >> provide relevant properties. We should only use a more specific class, if >> we expect the respective additional properties to be relevant for >> querying. To say that an E19 "has type: Hoard" should be enough. Only if >> we want to specify a curator and an E87 Curation Activity with a curation >> plan, using E78 Collection would be adequate. The less classes we use, the >> more effective the queries. >> >> Best, >> >> Martin >> >> On 29/11/2014 2:45 μμ, Christian-Emil Smith Ore wrote: >> >> In the case a curator in a museum buries his collection, a hoard may be >> considered as as a collection. The collection class is intended for museum >> collections, see the examples in the scope note. >> >> >> >> C-E >> >> >> >> -Original Message- >> >> From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr >> ] On Behalf Of Dan Matei >> >> Sent: Saturday, November 29, 2014 1:30 PM >> >> To: crm-sig@ics.forth.gr >> >> Subject: [Crm-sig] A hoard as
Re: [Crm-sig] A hoard as crm:E78_Collection ?
Dear Martin On 1 December 2014 at 17:26, martin wrote: > > This is a deep methodological question: > "True that crm:E19_Physical_Object "includes all aggregates of objects", > but I feel the need of something like crm:Fx_Assemblage between > crm:E19_Physical_Object > and E78_Collection, because I would like to make a clear (conceptual) > distinction between: > > or < > crm:Py_is_component_of > > > and >" > > This is not what we have made the CRM for. You SHOULD not make such a > distinction, > if there is no use case that would create query ambiguity. CRM is not a > language to describe the nuances of cultural heritage objects. Since a > hoard cannot have parts like a car, and a car not parts like a hoard, the > distinction does not help in any query. > > My main criterion (not always explicit !) to use one property or other is not the query (dis)ambiguity, but the facility of the semantic reasoning, i.e. inference. Am I wrong ? So, my feeling (not more than that) is that the reasoner is helped if crm:Py_is_component_of suggests that the subject of the assertion is a thing "functional" in itself, vs. crm:P46i_forms_part_of that suggests otherwise. We have built the CRM because we had such principles. It is overdue to write them down. Good idea ! Best, Dan > >
Re: [Crm-sig] A hoard as crm:E78_Collection ?
Dear Dan, This is a deep methodological question: "True that crm:E19_Physical_Object "includes all aggregates of objects", but I feel the need of something like crm:Fx_Assemblage between crm:E19_Physical_Object and E78_Collection, because I would like to make a clear (conceptual) distinction between: or < crm:Py_is_component_of > and " This is not what we have made the CRM for. You SHOULD not make such a distinction, if there is no use case that would create query ambiguity. CRM is not a language to describe the nuances of cultural heritage objects. Since a hoard cannot have parts like a car, and a car not parts like a hoard, the distinction does not help in any query. We all must be clear that the CRM is made ONLY for searching possibly related things across disciplines in a global network of knowledge. People don't use the CRM because it has already 150 properties. It is absolutely counterproductive to introduce more. Already, it is impossible to write queries using all 150 properties without long preparation. My position is, in order to capture the nuances of cultural heritage, we should write good scholarly texts, and not admire the brave new world of formal ontologies as the future scholarly language. We must be absolutely clear that the wish of each scholar to make a clear (conceptual) distinction is not an argument for the CRM. If it would be, we would now, after 18 years, struggle with millions of distinctions, and no chance people to understand the whole. Only clear functional requirements that a search statement would become ambiguous or return too much noise is an argument. Opinions? Secondly, the reasons why we have decided not to introduce a "crm:Fx_Assemblage" is because for many things it is undecidable, if something is an assemblage or not. If you propose, you should provide evidence of the decidability. Further, no distinct property necessary for querying could be identified. To make clear: I do not want to dominate the discussion. We have built the CRM because we had such principles. It is overdue to write them down. If E78 is problematic, if other senses of part_of are needed, if "crm:Fx_Assemblage" is adequate, must be a COMMON agreement that we apply the same principles. If you agree that these my arguments above are a correct application of these principle, and if you then disagree with the principles, we have to discuss the principles and not the E78. If you find that I wrongly apply the principles, we all should be happy to receive new issues to the CRM. Opinions? Cheers, Martin On 1/12/2014 3:17 ??, Dan Matei wrote: Hi, dear Vladimir Here is what I replyed to Martin (or you see the list ?): - Well, crm:E78_Collection attracts so much attention either because it is important or it has problems, or both :-) (Second thought: we can say that the guy burying a hoard had a "collection development plan": he planed to "develop", the hoard, retrieving it after some time and spending the coins :-) True that crm:E19_Physical_Object "includes all aggregates of objects", but I feel the need of something like crm:Fx_Assemblage between crm:E19_Physical_Object and E78_Collection, because I would like to make a clear (conceptual) distinction between: or < crm:Py_is_component_of > and So, I would like a crm:Fx_Assemblage exactly for the reason you invoke: "We should only use a more specific class, if we expect the respective additional properties to be relevant for querying.". - I'm still in doubt... Best, Dan ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- -- Dr. Martin Doerr | Vox:+30(2810)391625| Research Director | Fax:+30(2810)391638| | Email: mar...@ics.forth.gr | | 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 | | Web-site: http://www.ics.forth.gr/isl | --
Re: [Crm-sig] A hoard as crm:E78_Collection ?
Hi, dear Vladimir Here is what I replyed to Martin (or you see the list ?): - Well, crm:E78_Collection attracts so much attention either because it is important or it has problems, or both :-) (Second thought: we can say that the guy burying a hoard had a "collection development plan": he planed to "develop", the hoard, retrieving it after some time and spending the coins :-) True that crm:E19_Physical_Object "includes all aggregates of objects", but I feel the need of something like crm:Fx_Assemblage between crm:E19_Physical_Object and E78_Collection, because I would like to make a clear (conceptual) distinction between: or < crm:Py_is_component_of > and So, I would like a crm:Fx_Assemblage exactly for the reason you invoke: „We should only use a more specific class, if we expect the respective additional properties to be relevant for querying.". - I'm still in doubt... Best, Dan
Re: [Crm-sig] A hoard as crm:E78_Collection ?
Hi Well, crm:E78_Collection attracts so much attention either because it is important or it has problems, or both :-) (Second thought: we can say that the guy burying a hoard had a "collection development plan": he planed to "develop", the hoard, retrieving it after some time and spending the coins :-) True that crm:E19_Physical_Object "includes all aggregates of objects", but I feel the need of something like crm:Fx_Assemblage between crm:E19_Physical_Object and E78_Collection, because I would like to make a clear (conceptual) distinction between: or < crm:Py_is_component_of > and So, I would like a crm:Fx_Assemblage exactly for the reason you invoke: „We should only use a more specific class, if we expect the respective additional properties to be relevant for querying.". Cheers, Dan On 29 November 2014 at 21:07, martin wrote: > Continuing: > > I don't know, why E78 Collection attracts so much attention. The scope > note of > E19 Physical Object says: > > "The class also includes all aggregates of objects made for functional > purposes of whatever kind, independent of physical coherence, such as a set > of chessmen. Typically, instances of E19 Physical Object can be moved (if > not too heavy)." > > The CRM is not a terminological system to classify things. It is made to > provide relevant properties. We should only use a more specific class, if > we expect the respective additional properties to be relevant for > querying. To say that an E19 "has type: Hoard" should be enough. Only if > we want to specify a curator and an E87 Curation Activity with a curation > plan, using E78 Collection would be adequate. The less classes we use, the > more effective the queries. > > Best, > > Martin > > > On 29/11/2014 2:45 μμ, Christian-Emil Smith Ore wrote: > > In the case a curator in a museum buries his collection, a hoard may be > considered as as a collection. The collection class is intended for museum > collections, see the examples in the scope note. > > C-E > > > -Original Message- > From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr > ] On Behalf Of Dan Matei > Sent: Saturday, November 29, 2014 1:30 PM > To: crm-sig@ics.forth.gr > Subject: [Crm-sig] A hoard as crm:E78_Collection ? > > Friends > > I have to say that a particular coin is a member of a particular hoard. I > googled > to see how others are dealing with that, but... > > I'm tempted to: > > > > > > abusing a bit the E78 scope note: > > "This class comprises aggregations of instances of E18 Physical Thing that are > assembled and maintained (“curated” and “preserved,” in museological > terminology) by one or more instances of E39 Actor over time for a specific > purpose and audience, and according to a particular collection development > plan." > > > The "... according to a particular collection development plan." troubles me. > Can we say that the guy burying a hoard had a "collection development plan" ? > > There is a better practice for modelling that ? > > Dan > > PS. Not to mention that I would like to associate the discovery event with the > hoard, not with the coin. > > ___ > Crm-sig mailing > listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > > -- > Dr. Martin Doerr | Vox:+30(2810)391625| > Research Director | Fax:+30(2810)391638| >| Email: mar...@ics.forth.gr | > | >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 | > | > 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 > > -- --- Dan Matei Institutul Național al Patrimoniului (National Heritage Institute) - București Fundația Gellu Naum TermRom - Asociația Română de Terminologie
