Apologies for missing this back in February …

 

Before the deprecation of P83 and P84 in favor of P191, it was possible to say that a TimeSpan had a minimum duration of 2 days and a maximum duration of 4 days by using P83 and P84.

Now there is only a single Dimension related via P191, with the intent that the value can be an interval.

 

Given that in the RDF projection of CRM, the value of a Dimension is a single number (and similarly, the dates are single dates), it is not possible to express the above without some additional constructions in that projection.

 

Thus it seems like we need at least to define P90a_has_minumum_value and P90b_has_maximum_value as properties of Dimension to be able to express the interval value. This would be more consistent, and provide access to the construction for other uses of Dimension, so I’m happy with the deprecation of the last SIG … but we need to follow through with the corresponding RDF definitions.

 

I propose the following properties, which could be defined in the same document as P81a/b and P82a/b:

 

P90a_has_minimum_value

This property allows the lowest possible value of an E54 Dimension to be approximated by an E60 Number primitive.

 

P90b_has_maximum_value

This property allows the greatest possible value of an E54 Dimension to be approximated by an E60 Number primitive.

 

Rob

 

From: Martin Doerr <martin@ics.forth.gr>
Date: Saturday, February 23, 2019 at 4:59 PM
To: Robert Sanderson <RSanderson@getty.edu>, crm-sig <Crm-sig@ics.forth.gr>
Subject: Re: [Crm-sig] Issue 397

 

Dear Robert,

 

On 2/23/2019 1:09 AM, Robert Sanderson wrote:

 

This becomes problematic, unfortunately, in RDF which does not have a way to natively express a Number that is actually an interval.  The resolution would be to do the same as P81a/b … which would have the same effect as maintaining P83 and P84, just not in the model directly.

 

While I appreciate the theoretical consistency that this change would add, from an implementation perspective, this would bring more complexity than value.

I do not understand what increases the complexity: If I have in RDFS two paths  P83-E54-P90 AND P83-E54-P90, and the ambiguity how to use P90a, P90b together with these paths, OR I have a single path Pxxx-E54 that splits into P90a, P90b, then, in the end I have again two paths: Pxxx-E54-P90a AND Pxxx-E54-P90b and no ambiguity to use P83 or P90a.

So where is the added complexity? I see it only reduced, but I may be wrong!

My second question was if, since we have bound the Dimension already to temporal durations in the definition of Pxxx, we should express that by a subclass of E54.

Best,

 

martin

 

Overall, I’m not in favor of the deprecation, but am not averse to adding had_duration separately, with the potential to deprecate 83 and 84 if a holistic approach to date and number intervals can be devised.

 

Thanks!

 

Rob

 

From: Crm-sig <crm-sig-bounces@ics.forth.gr> on behalf of Martin Doerr <martin@ics.forth.gr>
Date: Friday, February 15, 2019 at 9:18 AM
To: crm-sig <Crm-sig@ics.forth.gr>
Subject: [Crm-sig] Issue 397

 

Dear All

 

As discussed in Berlin, I proposed to deprecate P83, P84, because in competes with an interval interpretation of P90, and :

Introduce instead Pxxx had duration, Domain:  E52 Time-Span, Range: E54 Dimension
and use the P90, P90a, P90b as adequate

or introduce  an Exxx Temporal Duration , subclass of E54 Dimension, and define subproperties in RDFS ending in xsd:duration.

 

Here my definition:

 

Pxxx had duration (was duration of)

Domain:              E52 Time-Span

Range:                E54 Dimension

Quantification:    one to one (1,1:1,1)

 

Scope note:         This property describes the length of time covered by an E52 Time-Span. It allows an E52 Time-Span to be associated with an E54 Dimension representing duration (i.e. it’s inner boundary) independent from the actual beginning and end. Indeterminacy of the duration value can be expressed by assigning a numerical interval to the property P90 has value of E54 Dimension.

 

Examples:        

§  the time span of the Battle of Issos 333 B.C.E. (E52) had duration Battle of Issos minimum duration (E54) has unit (P91) day (E58) has value (P90) (E60)

 

In First Order Logic:

                           Pxxx(x,y) E52(x)

                           Pxxx(x,y) E54(y)

 

Comments?

------------------------------------------------------------------------------------------------------

See:

P83 had at least duration (was minimum duration of)

Domain:              E52 Time-Span

Range:                E54 Dimension

Quantification:    one to one (1,1:1,1)

 

Scope note:         This property describes the minimum length of time covered by an E52 Time-Span.

 

It allows an E52 Time-Span to be associated with an E54 Dimension representing it’s minimum duration (i.e. it’s inner boundary) independent from the actual beginning and end.

Examples:        

§  the time span of the Battle of Issos 333 B.C.E. (E52) had at least duration Battle of Issos minimum duration (E54) has unit (P91) day (E58) has value (P90) 1 (E60)

 

In First Order Logic:

                           P83(x,y) E52(x)

                           P83(x,y) E54(y)


P84 had at most duration (was maximum duration of)

Domain:              E52 Time-Span

Range:                E54 Dimension

Quantification:   one to one (1,1:1,1)

Scope note:         This property describes the maximum length of time covered by an E52 Time-Span.

It allows an E52 Time-Span to be associated with an E54 Dimension representing it’s maximum duration (i.e. it’s outer boundary) independent from the actual beginning and end.

Examples:        

§  the time span of the Battle of Issos 333 B.C.E. (E52) had at most duration Battle of Issos maximum duration (E54) has unit (P91) day (E58) has value (P90) 2 (E60)

In First Order Logic:

                           P84(x,y) E52(x)

                           P84(x,y) E54(y)

 

-- 
------------------------------------
 Dr. Martin Doerr
              
 Honorary Head of the                                                                   
 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 
 
 Vox:+30(2810)391625  
 Email: martin@ics.forth.gr  
 Web-site: http://www.ics.forth.gr/isl 

 

-- 
------------------------------------
 Dr. Martin Doerr
              
 Honorary Head of the                                                                   
 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 
 
 Vox:+30(2810)391625  
 Email: martin@ics.forth.gr  
 Web-site: http://www.ics.forth.gr/isl