Happy new year! Just preparing to go back to work next week and saw this thread.
>From my quick reading of the emails it is of course possible to place a time span on any event/activity such as a measurement event and connect that to a dimension that has a P2_has_type (height, width, US inch, US inch (pre-1959), Swedish inch, etc and a P90 value and P91 unit. Our own mapping uses P2_has_type to provide the type of dimension of an E54 and then uses a vocabulary (E55) provided by qudt http://www.qudt.org/ (or local vocab for more specialized dimension types not available in qudt). We also use qudt for unit but again you can add your own historic ones - e.g. On a more general data integration point I was interested in Rob's email about the pre-1959 inch and looked it up. I assume that Rob has the data that provides a date of each measurement activity, and that all inch's are US and that those actors who did the original measuring adhered to the different inches at the exact time of change in 1959. I know that in Britain we might have been less than quick at changing to new fancy EU measurements and distributing new rulers! and in any event changing measurements is usually transitional (the Swedish inch was transitioned between 1855 and 1863 - quite an efficient eight years). It seems that more generally in history the inch has been less than a standard. If the purpose is to query or construct triples that provide consistent metric conversions, for example, then the more diverse the integrated data (our primary aim is to integrated diverse data) the more complex it becomes. On wiki media (and wikipedia) they have the following image. https://en.wikipedia.org/wiki/Inch#/media/File:Inch_converter.jpg. I cite http://themetricmaven.com/ from which I have derived the information for this email and which is devoted to US metric system and its history. The site author has also published a book called "The Dimensions of the Cosmos: Tales from 16 Metric Worlds" (by Randy Bancroft) described as follows, "Originally, our world was described using a plethora of provincial ad hoc measurement units only of everyday dimensions. The US inch was initially defined as the length of three barleycorn placed end-to-end, and is the current basis of US shoe sizes. The invention of the microscope and telescope in the 17th century revealed unimagined new macroscopic and microscopic worlds. The Dimensions of the Cosmos takes the reader on a tour of these hidden worlds with the only measurement system designed to intuitively describe them, the modern metric system." >From the wiki media image the metric maven site reproduces the following table. It should also be noted that the Swedish inch also changed in the later part of the 19th century and please note the large variation particularly for the Russian inch. - Hamburgh – Inch divided into 8 parts. 1 inch ≈ 23.2 mm - Austrian – Inch divided into 8 parts. 1 inch ≈ 25.8 mm - Itallian – Inch divided into 8 parts. 1 inch ≈ 28.3 mm - Bremen – Inch divided into 10 parts. 1 inch ≈ 23.7 mm - Swedish – Inch divided into 12 parts. 1 inch ≈ 24.3 mm - Turkish – Inch divided into 12 parts. 1 inch ≈ 31.3 mm - Bavarian – Inch divided into 12 parts. 1 inch ≈ 24.0 mm - Spanish – Inch divided into 12 parts. 1 inch ≈ 23.0 mm - Portuguese – Inch divided into 12 parts. 1 inch ≈ 27.0 mm - Moscow – Inch divided into 12 parts. 1 inch ≈ 27.7 mm - Russian – Inch divided into 8 parts. 1 inch ≈ 44.1 mm - Amsterdam – Inch divided into 12 parts. 1 inch ≈ 23.5 mm - Rhynland – Inch divided into 12 parts. 1 inch ≈ 26.1 mm - French – Inch divided into 12 parts. 1 inch ≈ 27.0 mm - Fr. Metre – Centimetres divided into millimetres - English – Inch divided into 32 parts. 1 inch ≈ 25.3 mm I will pass this on to our own documentation section for their comment. Although obviously important from an institutional documentation point of view, I agree with Martin in that when you are exploring integrated datasets you probably don't want to rely on dimension values as the main exploration mode and we are instead looking at how best to display dimensions as facets once the result set is reduced to a more useful graph using more global categories. The interfaces that FORTH and BM are currently working on do precisely this and we are both at a stage trying to understand what relationships work best at the more macro level and what information is better left at a facet or micro (record) level. For my own part this data is often (whatever the dataset) affected by varying standards and inconsistent validation over time, and so attempting to provide faceted dimension ranges (which might be useful to users at another level of exploration) becomes difficult, but at the moment, given current feedback probably makes this marginal work at the moment. However, I do hope to be able to provide CRM-SIG with some practice information at some point. On this point we have made our beta exploration system public to get some feedback when we visit colleagues at www.researchspace.org/home/public (or a link to it is here) and we will be working with FORTH to understand the optimal set of fundamental categories and relationships for different purposes and situations to further refine the beta before formal release. This type of system is very different from keyword searching because instead of masking data issues by simple indexing keywords and prioritizing recall, it actually and deliberately exposes data issues writ large. This is necessary if we are to collaborate on identifying and enriching key data. In many cases, what I see as really important categories of information and context for wider audiences (including researchers) are missing from traditional catalog data using standards not designed for open world engagement and research. I'm not saying that there isn't a research or engagement question, (particularly given Randy's book), for which the minutiae of measurement related to cultural heritage collections wouldn't be valid or interesting (and I don't know the level of precision needed for provenance assessments which is something more internal), but I suspect from the emails that we currently have some good coverage in CIDOC CRM linked to its open world purpose, particularly now with CRMSci - and as Martin says, we can easily specialize locally if we want to reflect local documentation issues. These discussions are good for provoking practical use cases for future CRM -SIG meetings and modeling issues - and on that note once I have a copy of Randy's book, I may have much much more to say..... ;-) Cheers and best for the new year, Dominic orcid.org/0000-0002-5539-3126 On Sat, Jan 7, 2017 at 5:02 PM, martin <[email protected]> wrote: > Dear Richard, > > On 6/1/2017 7:57 μμ, Richard Light wrote: > > > On 2017-01-06 2:06 PM, martin wrote: > > Dear Robert, > > Thank you very much for your message! Let me first comment your initial > mail. > > Martin, > > This reply of yours has only just popped into my in-box, so my previous > reply was written before I had read it. > > As a general remark to all other valuable contributions to this issue > however: We should not loose focus: the CRM intends only to describe > important facts for cultural-historical and scientific inquiries across > integrated knowledge networks. If we want to describe any detail, we are > free to put it in P2 notes or to make our own extensions. For instance, I'd > argue that details of dimensions of museum objects are irrelevant to global > queries. Would anybody research for all objects that could be 3.25 mm long, > without any prior, substantial reduction of the search space? Without a > strict scope limitation, we will end up modelling all sciences and > businesses of the world. > > I don't see how this argument applies to measurement of museum objects, > given what is already in the CRM. We have *E16 Measurement*, which is an > attribute assignment activity, with properties *P39 measured *specifying > the thing measured, and *P40 observed dimension *giving the result of the > measurement activity. This is an *E54 Dimension*: the very thing we are > discussing. The examples in the scope notes include the length of museum > objects. If measuring museum objects is 'out of scope', what are these > classes and properties doing in the CRM? > > I never said that measuring is out of scope. I said that reasoning about > precise dimension values is out of scope. Applications that do have the > problem would first filter out certain contextual parameters, then verify > the quality of the available data, and then feed the numerical data into a > specialized system doing further processing. > > > Also, while I agree that it is unlikely that anyone would search for all > objects that are exactly a certain length, they might very well be > interested in objects that have dimensions which are less than or greater > than a certain value. > > That might be the case. If it is, your proposal to split a length value > into feet and inches is exactly the opposite to do. Then, we normalize to a > common standard, i.e., e metric interval. The applications I know of is > packaging for exhibitions etc. This is a local problem in the museum. > Packaging dimensions require a specific method, e.g., using a box with > adjustable walls. > > But, asking the audience: *Who has a real use case for this scenario? *This > is not to question your argument, it is a serious question. > > > > CRM compatibility does not prohibit any local extension of topics outside > its scope. Since CRM SIG acts as standardization body, it cannot be > proactive to needs. It can only react after some established practices need > harmonization. > > Measuring objects is a core part of museum documentation. There is a > wealth of existing 'established practice' to support this. > > Of course. Not only measuring lentghs, but a large variety of analytical > methods. This is a domain of CRMSci. > For instance, spectral analysis of colorants. But you would query for > "egyptian blue", and then question the measurement data. You would not > query for spectral values. Therefore, spectral values need not be > accessible to SPRQL queries, only obviously connected to the object and the > analysis events. Please conservators to correct me! > > Best, > > Martin > > Of course. > > Richard > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: [email protected] | > | > 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 > [email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > -- > *Richard Light* > > > _______________________________________________ > Crm-sig mailing > [email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: [email protected] | > | > 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 > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > >
