Dear all, As a follow-up to this issue, I wanted to point towards issue 240 from the CRM queue. It’s a pending issue but is perhaps apropos. If the question is where to stick actual data values of texts if you don’t have a URI to point to then perhaps adopting the solution suggested there provide a good answer?
http://www.cidoc-crm.org/Issue/ID-240-new-encoding-property-for-e90-symbolic-object <http://www.cidoc-crm.org/Issue/ID-240-new-encoding-property-for-e90-symbolic-object> Best, George > On Feb 22, 2018, at 11:46 AM, George Bruseker <bruse...@ics.forth.gr> wrote: > > Dear Phil et al., > > I think this is a case of interpreting the label of the property rather than > its intention. CRM ‘has value’ isn’t supposed to cover all possible meanings > of the natural language interpretation of has value. Rather it has a very > restricted use. It is meant to give the quantitive number value associated to > a dimension. Dimension is a class that should be used to store information > that results from a measurement activity. The measurement activity is > specified as some procedural event that has the intentional objective of > producing quantitative data. It is an activity of interacting with the world > with the intention of producing a quantitive result. > > So it would be a nonsensical, to say 'this paragraph (E73) has dimension (E54 > defined as a quantitive result from a measuring procedure) has value “the > characters in this paragraph” (E59 primitive value). The definition of E54 > forbids it because a string is not a quantity (though of course it may have a > quantity… that would have to be measure). > > That of course sounds irritating. It would be nice to have a property that > could store all values. But then of course that property would mean > everything and nothing and the ontology wouldn’t work for getting specific > information, like the quantitative results of measurement activities separate > from any other value ‘good’ ‘bad’ ‘ugly’ ‘monogamy’ ‘world peace’ ‘all the > characters in this present string’. > > That’s the ontological argument. The practical question is why you are > looking to expand the scope. I’m guessing that the reason is because you want > a unique place to store a data value (this is a guess, so please do correct > my presumption if I’m wrong). > > This seems to me to get back to the encoding issue and having a standard > strategy. I think that a usual suggestion could be to throw it into string > via P3 via note. Another suggestion would be to put it in label and, as I > recall, there is rdf has value which could hold the actual data points. You > will note, in retort, that p3 handles different kinds of information so is > not a good solution. Point taken. > > In any case, I would argue that increasing the range of the existing property > to E1 E59 clearly cannot work because that would be a completely different > meaning of the property and it would cause all sorts of backwards > incompatibilities and data problems. It would really be an undoing of good > information structure. That being said, some sort of solution either in the > ontology or as an encoding formalization of where to stick the actual > ‘values’ of an entity ought to be found. > > I think the right direction might already have been found with CRMsci which > generalizes the notion of measurement to observation. Observation is a class > that documents events of systematic observing (without that this be > measuring, a clearly distinct and different real life human activity with > different parameters of interest) and allows the tracing of observing a value > (here the range is even more radical, set at E1) and setting the property > type. (see the definitions > http://www.cidoc-crm.org/crmsci/sites/default/files/2017-03-22%23CRMsci1.2.3_esIP.pdf) > This has a great deal of flexibility since we need to know not just the > value of any random thing that someone has assigned to some object, but at > the very least, of what type it is. > > Consider one of Rob’s examples: > > ‘linguistic objects have values’ > > Linguistic Object: here do mean the characters themselves? the propositional > content? the darkness of the font, the font type, the style of encoding. > these are all potential values of the linguistic object. Obviously we don’t > want to let our ontology toss all this in the same bucket, right? I think the > same argument would go for appellation. > > Not to mention, how one could irritatingly misinterpet the sentence > ‘linguistic objects have values’ to imply their adherence to a dogma, a > political party, a certain sense of taste in dress. > > Digital Image, I am not sure we would have a problem with, as it is a > mathematical object and as such I guess its properties are quantitive and > therefore just good old fashioned dimension. > > All this being said, obviously you raise the issue because there are things > that you need to document in the real world and are presently unable to > encode as you would need using CRM. Obviously, something like a property with > the natural language interpretation of ‘has value’ has an intuitive appeal. > Would you give a few examples of the problems areas (I would certainly not > assert that they do not exist), so we can think together of a solution that > is ontologically sound and pragmatically applicable? > > Cheers, > > George > > >> On Feb 21, 2018, at 7:30 PM, Franco Niccolucci <franco.niccolu...@gmail.com> >> wrote: >> >> Hm. >> >> The current way of representing something similar (but different) to what >> you propose is: >> >> E70 Thing -> P43 has dimension -> E54 Dimension -> P90 has value -> E60 >> Number >> >> The path starts from Things (and not CRM Entities) and ends to Numbers (and >> not Primitive Values, i.e. also Strings, Time Primitives and whatever we can >> invent in the future): it gives a numeric value to a thing. >> >> The proposed change would allow giving, through the "new" P90, a generic >> value defined as E59 Primitive Value, i.e anything, also to E2 Temporal >> Entities, E53 Places etc, all subclasses of E1. >> >> What can be an example of the Primitive Value of a Temporal Entity or of a >> Place? >> >> For example “Bronze Age”, an instance of E4 Period, cannot have a primitive >> value whatever; it may have a Time Span and take place somewhere in a Place. >> Time spans may P83/84 have durations, instances of E54. >> >> Dimensions would need to be considered not only as something that can be >> measured with numbers only: for example “poor - fair - good - excellent” >> would be acceptable for the space of Values, same for “strings of UTF8 >> characters”. It is not necessary to specify what the values is, as it by >> definition could be anything >> >> So I would rather suggest to leave the domain of P43 as is, i.e. Things >> only; and the range of P90, as you propose, could become E59, i.e. strings >> or anything else to be created as subclass of E59, without short-cutting the >> above. >> >> This allows specifying what we are talking about the Thing (its length, its >> social value, its ranking on its Facebook page, its translation into >> Estonian), i.e. the dimension; and how we measure it if desired, - E58 >> Measurement Unit. >> >> Best >> >> Franco >> >> PS This discussion reminds me of a commercial advertising a credit card. It >> showed somebody buying a ring for the beloved one, paying the dinner with >> her, buying flowers, and ended saying that one can buy everything with the >> card, but romance has no price. >> >> Prof. Franco Niccolucci >> Director, VAST-LAB >> PIN - U. of Florence >> Scientific Coordinator >> ARIADNE - PARTHENOS >> >> Piazza Ciardi 25 >> 59100 Prato, Italy >> >> >>> Il giorno 21 feb 2018, alle ore 17:13, Robert Sanderson >>> <rsander...@getty.edu> ha scritto: >>> >>> >>> >>> Definitely in favor of this. Linguistic Objects can have values. >>> Appellations have values. Digital Images have values. Etc. >>> >>> >>> >>> Rob >>> >>> >>> >>> >>> >>> From: Crm-sig <crm-sig-boun...@ics.forth.gr> on behalf of "Carlisle, >>> Philip" <philip.carli...@historicengland.org.uk> >>> Date: Wednesday, February 21, 2018 at 4:04 PM >>> To: "crm-sig (Crm-sig@ics.forth.gr)" <Crm-sig@ics.forth.gr> >>> Subject: [Crm-sig] Domain and range of P90 >>> >>> >>> >>> Dear all, >>> Naïve question. >>> >>> >>> >>> Is there any reason why P90 has value could not/should not change its >>> domain and range from: >>> >>> >>> >>> Domain: Range >>> >>> E54 Dimension E60 Number >>> >>> >>> >>> to >>> >>> >>> >>> E1 CRM Entity E59 Primitive Value >>> >>> >>> >>> I look forward to you answers >>> >>> >>> >>> Phil >>> >>> >>> >>> >>> >>> >>> >>> Phil Carlisle >>> >>> Knowledge Organization Specialist >>> >>> Listing Group, Historic England >>> >>> Direct Dial: +44 (0)1793 414824 >>> >>> >>> >>> http://thesaurus.historicengland.org.uk/ >>> >>> http://www.heritagedata.org/blog/ >>> >>> >>> >>> Listing Information Services fosters an environment where colleagues are >>> valued for their skills and knowledge, and where communication, customer >>> focus and working in partnership are at the heart of everything we do. >>> >>> >>> >>> >>> >>> >>> >>> <image001.jpg> >>> >>> We help people understand, enjoy and value the historic environment, and >>> protect it for the future. Historic England is a public body, and we >>> champion everyone’s heritage, across England. >>> Follow us: Facebook | Twitter | Instagram Sign up to our >>> newsletter >>> >>> Help us create a list of the 100 places which tell England's remarkable >>> story and its impact on the world. A History of England in 100 Places >>> sponsored by Ecclesiastical. >>> >>> We have moved! Our new London office is at 4th Floor, Cannon Bridge House, >>> 25 Dowgate Hill, London, EC4R 2YA. >>> >>> >>> This e-mail (and any attachments) is confidential and may contain personal >>> views which are not the views of Historic England unless specifically >>> stated. If you have received it in error, please delete it from your system >>> and notify the sender immediately. Do not use, copy or disclose the >>> information in any way nor act in reliance on it. Any information sent to >>> Historic England may become publicly available. >>> >>> >>> >>> _______________________________________________ >>> Crm-sig mailing list >>> Crm-sig@ics.forth.gr >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
