Issue 435: Scope Note of E60 needs revision

ID: 
435
Starting Date: 
2019-10-08
Status: 
Done
Closing Date: 
2019-10-25
Background: 

Posted by martin on 8/10/2019

Dear All, we need to provide other definitions of identifiers in continua.
E60 Number

Subclass of:         E59 Primitive Value

 

Scope Note:        This class comprises any encoding of computable (algebraic) values such as integers, real numbers, complex numbers, vectors, tensors etc., including intervals of these values to express limited precision.

 

Numbers are fundamentally distinct from identifiers in continua, such as instances of E50 Date and E47 Spatial Coordinate, even though their encoding may be similar. Instances of E60 Number can be combined with each other in algebraic operations to yield other instances of E60 Number, e.g., 1+1=2. Identifiers in continua may be combined with numbers expressing distances to yield new identifiers, e.g., 1924-01-31 + 2 days = 1924-02-02. Cf. E54 Dimension

Examples:          

§  5

§  3+2i

§  1.5e-04

§  (0.5, - 0.7,88)

 

In First Order Logic:

                           E60(x) ⊃ E59(x)

Posted by Richard Light on 9/10/2019

Martin,

I'm not sure I particularly like the phrase 'identifiers in continua' - but maybe I just don't understand its intended meaning.  To me, a date is just a data value, expressed to a certain degree of precision. An 'identifier' suggests something which is deliberately assigned as a property of an entity, in order to ... identify it.

In any case, if we are defining and giving examples of these identifiers, shouldn't we be doing so within the class descriptions where this concept applies, not in one where we specifically say that it doesn't apply?

Whatever these identifiers are, they won't be E50 or E47, both of which are flagged as deprecated (and now to be treated as E41 Appellation).

Richard

Posted by martin on 9/10/2019

Richard,

On 10/9/2019 6:34 PM, Richard Light wrote:
>
> Martin,
>
> I'm not sure I particularly like the phrase 'identifiers in continua' - but maybe I just don't understand its intended meaning.  To me, a date is just a data value, expressed to a certain degree of precision. An 'identifier' suggests something which is deliberately assigned as a property of an entity, in order to ... identify it.

A date is a numerical distance from a starting point, e.g. a zero redefined every time the precision increases. A geocoordinate refers to Greenwich, etc. Therefore they are NOT values, but absolute points in space time. Not quantities.
>
> In any case, if we are defining and giving examples of these identifiers, shouldn't we be

Yes E41 need rewriting. I work on it. All examples from deprecated classes need to be transferred.

Posted by Richard Light on 10/10/2019
Martin,
Is this an official CRM Issue? I don't see an issue number, and a search of the issues page for 'E60' yields only Issue 197, which was resolved two years ago. Nor can I find any mention of this issue in the recently-published minutes from the last SIG meeting.

I ask because I'm struggling to understand the context in which the question has been raised, and your most recent answer.

Hi Richard,

Sorry, should have been "NEW ISSUE".

Posted by Richard Light on 14/10/2019

Martin,

Returning to your original point, I think the first paragraph of the scope note for E60 is sufficient.  I don't think that the second paragraph adds explanatory value, and I suggest that it is removed.  This text is not concerned with implementation details, so we don't need to discuss encoding of numbers here.

Posted by Martin on 14/10/2019

Hi Richard,

I have just tried to write the scope note without the deprecated classes. I do not think the second paragraph pertains to implementation, but clarifies what is not a number ontologically. It makes a statement that some implementation may make a different impression about the ontological nature. It is good practice to refer in a scope note to things that are not meant by the class. Your comment about dates being values just confirms me that this is an important clarification.

Even though it appears to some to be more elegant to have minimal scope notes, many users do not appreciate that.

So, I suggest it stays...

 

Outcome: 

In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meetingthe sig reviewed MD’s rework of the scope note for E60 Number, which aimed at redefining the class without recourse to deprecated classes of the CRM (E50, E47). The new scope note was accepted.  

The issue closed

Heraklion, October 2019