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


Reply via email to