Re: [Crm-sig] Intervals in E60
Dear all, I'd just like to support Jim Salmon's statement and Franco's. Computing with data values is not an issue for the CRM. Only interfacing to respective systems. For instance, use GeoSPRQL strings to couple a triple store with PostGIS. Also the CRM is *not *a representation language. For this purpose use notes or XML. "3 feet 6 inches" is a pure representation/ tagging problem. The model below, regarding a Dimension to be a sum of two Dimensions, is definitely wrong, because there is no empirical point after 3 feet. This composition is not the observed one. The observed length is split up by reading a yardstick. The CRM is an ontology. To which degree xsd datatypes are declared or not, is not our concern. For "red" as result of quantitative observation, we could use an "8-bit RGB" unit, and declare for instance a value to be (190,25,30). Just to say a thing is "red", we can use a P2 has type "Red Thing". A "Red Thing" is definitely not (255,0,0). What is the cultural-historicallly relevant definition of red? E.g., the use of yellow in China reserved to the emperor? Is that a question of RGB values? How would you encode the use of imperial Yellow? I kindly ask all contributors to this issue FIRST to say *what serious research question* a query across collections and other cultural historical facts about such values supports. Otherwise, all presented models are *quite irrelevant *for the CRM, and pure representation questions. Whatever local extensions for representation you propose, if they are subsumed by P3 has note, they will pop up with the object when queried. Problem solved. No standards needed. The strength of the CRM is exactly to draw the line to the detail not needed for global questions All the best, Martin On 7/1/2017 1:56 μμ, Richard Light wrote: On 2017-01-07 12:25 AM, Robert Sanderson wrote: Which is born out by the ontology in the casting to RDF, in that the range is rdfs:Literal, not xsd:integer. Good catch, thank you! So, it would be valid to say, for example: _:red a E54_Dimension ; P90_has_value “red” ; P91_has_unit . I don't think you can get away with that one! P90 has range /E60 Number/, and that is explicitly defined to be "computable (algebraic) values such as integers, real numbers, complex numbers, vectors, tensors etc.". And thus the observation that “Red Square” in MOMA is red could be a Measurement of that Dimension? The concern, of course, is that some implementations will use “16” (the string) and others 16 (the integer), which are not comparable. To which the obvious answer is, I fully realize: Don’t do that then. An RDF 1.1 Literal [1] consists of a string value and a datatype IRI, which specifies how the string should be interpreted, via a lexical-to-value mapping. Thus, by the time your "16" is expressed in RDF 1.1, it will be equipped with an IRI which tells you how to interpret its string value (as xs:string or xs:integer). In the case of string values, there is also the option of specifying a language tag. So there is no ambiguity in the RDF logical representation, once we arrive at that point. The CRM properties /P90_has_value/ and /P91_has_unit /give us the means to record these string values and datatype IRIs (so long as we can agree on a syntax for expressing 'complex' Dimensions which consist of a number of value-unit pairs). However, RDF 1.1 defines a number of built-in data types [2], and these don't match up to the types of unit we want to express. They are effectively [most of] the XML Schema datatypes, recycled. Dates and times are pretty well-served, but there is nothing to support linear measurements (m/mm, ft/inches) or currency. We could invent IRIs for these units as custom datatypes [3]. Alternatively, we could take a measurement in feet and inches and record it as Rob has done below, but with explicit typing of the values: _:total a Dimension ; consists_of [ a Dimension ; value "3"^^xs:decimal ; unit ], [ a Dimension ; value "6"^^xs:decimal ; unit ] . While the [abstract] definition of E60 Number does indeed include intervals, it is not clear to me how one would actually express these in RDF. Best wishes, Richard [1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal [2] https://www.w3.org/TR/rdf11-concepts/#xsd-datatypes [3] https://www.w3.org/TR/owl2-syntax/#Datatype_Definitions Rob On 1/4/17, 6:57 PM, "Stephen Stead" wrote: Not commenting on everything but " The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. " The value is tied (via P90) to an instance of E60 Number not a number. E60 Number includes, explicitly, intervals. Rgds SdS Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 e-mailste...@paveprime.com
Re: [Crm-sig] Intervals in E60
Richard, I think that your example about lengths is irrelevant. If you are referring to a real measurement, ISO/IEC 8 should be used, and mm is just 0.001 m. So one unit only, the standard one, and all lenghts, in serious scientific work, are in m. If one is dealing with historic documents, then there is a plethora of complicated unita and recordimg lengths stated in ancient ways requires a totally different approach. In other words, in my opinion, the right place to store ft and inches is in a (folkoristic) note and use ISQ instead. Of course, the above is almost off-topic here, it just serves to state that the ft-inch CRM issue is not an issue. Best Franco Il sabato 7 gennaio 2017, Richard Light ha scritto: > > On 2017-01-07 12:25 AM, Robert Sanderson wrote: > > Which is born out by the ontology in the casting to RDF, in that the range is > rdfs:Literal, not xsd:integer. Good catch, thank you! > > So, it would be valid to say, for example: > > _:red a E54_Dimension ; > P90_has_value “red” ; > P91_has_unit . > > I don't think you can get away with that one! P90 has range *E60 Number*, > and that is explicitly defined to be "computable (algebraic) values such as > integers, real numbers, complex numbers, vectors, tensors etc.". > > And thus the observation that “Red Square” in MOMA is red could be a > Measurement of that Dimension? > > The concern, of course, is that some implementations will use “16” (the > string) and others 16 (the integer), which are not comparable. To which the > obvious answer is, I fully realize: Don’t do that then. > > An RDF 1.1 Literal [1] consists of a string value and a datatype IRI, > which specifies how the string should be interpreted, via a > lexical-to-value mapping. Thus, by the time your "16" is expressed in RDF > 1.1, it will be equipped with an IRI which tells you how to interpret its > string value (as xs:string or xs:integer). In the case of string values, > there is also the option of specifying a language tag. So there is no > ambiguity in the RDF logical representation, once we arrive at that point. > > The CRM properties *P90_has_value* and *P91_has_unit *give us the means > to record these string values and datatype IRIs (so long as we can agree on > a syntax for expressing 'complex' Dimensions which consist of a number of > value-unit pairs). However, RDF 1.1 defines a number of built-in data > types [2], and these don't match up to the types of unit we want to > express. They are effectively [most of] the XML Schema datatypes, > recycled. Dates and times are pretty well-served, but there is nothing to > support linear measurements (m/mm, ft/inches) or currency. We could invent > IRIs for these units as custom datatypes [3]. Alternatively, we could take > a measurement in feet and inches and record it as Rob has done below, but > with explicit typing of the values: > > _:total a Dimension ; > consists_of [ > a Dimension ; > value "3"^^xs:decimal ; > unit ], [ > a Dimension ; > value "6"^^xs:decimal ; > unit ] . > > > While the [abstract] definition of E60 Number does indeed include > intervals, it is not clear to me how one would actually express these in > RDF. > > Best wishes, > > Richard > > [1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal > [2] https://www.w3.org/TR/rdf11-concepts/#xsd-datatypes > [3] https://www.w3.org/TR/owl2-syntax/#Datatype_Definitions > > > Rob > > On 1/4/17, 6:57 PM, "Stephen Stead" > wrote: > > Not commenting on everything but > " The scopenotes for Dimension recommending intervals seem to be out of > date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. " > The value is tied (via P90) to an instance of E60 Number not a number. > E60 Number includes, explicitly, intervals. > Rgds > SdS > > Stephen Stead > Tel +44 20 8668 3075 > Mob +44 7802 755 013 > E-mail ste...@paveprime.com > > LinkedIn Profile http://uk.linkedin.com/in/steads > > -Original Message- > From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr > ] On Behalf Of > Robert Sanderson > Sent: 04 January 2017 18:39 > To: Richard Light > ; > crm-sig@ics.forth.gr > Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency > > > Hi Richard, > > I agree that the Currency should be constant unless the monetary system > changes, regardless of the changing value. However that’s not what is > implied by Monetary_Amount being a subclass of Dimension, where the actual > value is independent of the approximation. For the subclass to be valid, the > features of the parent class must be valid for the child class (All Persons > are Actors, and all of the features of Actor are valid for Person). Ergo, > the proposed structure is invalid, or the scope notes for Dimension should be > changed to say that 6 inches is the face value, not the independent absolute
Re: [Crm-sig] Intervals in E60
On 2017-01-07 12:25 AM, Robert Sanderson wrote: > Which is born out by the ontology in the casting to RDF, in that the range is > rdfs:Literal, not xsd:integer. Good catch, thank you! > > So, it would be valid to say, for example: > > _:red a E54_Dimension ; > P90_has_value “red” ; > P91_has_unit . I don't think you can get away with that one! P90 has range /E60 Number/, and that is explicitly defined to be "computable (algebraic) values such as integers, real numbers, complex numbers, vectors, tensors etc.". > And thus the observation that “Red Square” in MOMA is red could be a > Measurement of that Dimension? > > The concern, of course, is that some implementations will use “16” (the > string) and others 16 (the integer), which are not comparable. To which the > obvious answer is, I fully realize: Don’t do that then. An RDF 1.1 Literal [1] consists of a string value and a datatype IRI, which specifies how the string should be interpreted, via a lexical-to-value mapping. Thus, by the time your "16" is expressed in RDF 1.1, it will be equipped with an IRI which tells you how to interpret its string value (as xs:string or xs:integer). In the case of string values, there is also the option of specifying a language tag. So there is no ambiguity in the RDF logical representation, once we arrive at that point. The CRM properties /P90_has_value/ and /P91_has_unit /give us the means to record these string values and datatype IRIs (so long as we can agree on a syntax for expressing 'complex' Dimensions which consist of a number of value-unit pairs). However, RDF 1.1 defines a number of built-in data types [2], and these don't match up to the types of unit we want to express. They are effectively [most of] the XML Schema datatypes, recycled. Dates and times are pretty well-served, but there is nothing to support linear measurements (m/mm, ft/inches) or currency. We could invent IRIs for these units as custom datatypes [3]. Alternatively, we could take a measurement in feet and inches and record it as Rob has done below, but with explicit typing of the values: > _:total a Dimension ; > consists_of [ > a Dimension ; > value "3"^^xs:decimal ; > unit ], [ > a Dimension ; > value "6"^^xs:decimal ; > unit ] . While the [abstract] definition of E60 Number does indeed include intervals, it is not clear to me how one would actually express these in RDF. Best wishes, Richard [1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal [2] https://www.w3.org/TR/rdf11-concepts/#xsd-datatypes [3] https://www.w3.org/TR/owl2-syntax/#Datatype_Definitions > > Rob > > On 1/4/17, 6:57 PM, "Stephen Stead" wrote: > > Not commenting on everything but > " The scopenotes for Dimension recommending intervals seem to be out of > date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. " > The value is tied (via P90) to an instance of E60 Number not a number. > E60 Number includes, explicitly, intervals. > Rgds > SdS > > Stephen Stead > Tel +44 20 8668 3075 > Mob +44 7802 755 013 > E-mail ste...@paveprime.com > LinkedIn Profile http://uk.linkedin.com/in/steads > > -Original Message- > From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Robert > Sanderson > Sent: 04 January 2017 18:39 > To: Richard Light ; crm-sig@ics.forth.gr > Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency > > > Hi Richard, > > I agree that the Currency should be constant unless the monetary system > changes, regardless of the changing value. However that’s not what is > implied by Monetary_Amount being a subclass of Dimension, where the actual > value is independent of the approximation. For the subclass to be valid, the > features of the parent class must be valid for the child class (All Persons > are Actors, and all of the features of Actor are valid for Person). Ergo, > the proposed structure is invalid, or the scope notes for Dimension should be > changed to say that 6 inches is the face value, not the independent absolute > value. > > Regarding the URI discussion, the URI would not be the value of the > Monetary_Amount, just its identifier. > For example, if three artworks each sold for $100, the instance of > Monetary_Amount referenced from each Purchase can be the same instance. In > short hand: > > _:p1 a Purchase ; > transferred_ownership_of _:object1 ; > sale_price . > > _:p2 a Purchase ; > transferred_ownership_of _:object2 ; > sale_price . > > _:p3 a Purchase ; > transferred_ownership_of _:object3 ; > sale_price . > > a MonetaryAmount ; > value 100 ; > currency . > > > And from your second email, I agree (per your point 3) that P181 is > unnecessary if a Monetary_Amount is a Dimensio
Re: [Crm-sig] Intervals in E60
Which is born out by the ontology in the casting to RDF, in that the range is rdfs:Literal, not xsd:integer. Good catch, thank you! So, it would be valid to say, for example: _:red a E54_Dimension ; P90_has_value “red” ; P91_has_unit . And thus the observation that “Red Square” in MOMA is red could be a Measurement of that Dimension? The concern, of course, is that some implementations will use “16” (the string) and others 16 (the integer), which are not comparable. To which the obvious answer is, I fully realize: Don’t do that then. Rob On 1/4/17, 6:57 PM, "Stephen Stead" wrote: Not commenting on everything but " The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. " The value is tied (via P90) to an instance of E60 Number not a number. E60 Number includes, explicitly, intervals. Rgds SdS Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 E-mail ste...@paveprime.com LinkedIn Profile http://uk.linkedin.com/in/steads -Original Message- From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Robert Sanderson Sent: 04 January 2017 18:39 To: Richard Light ; crm-sig@ics.forth.gr Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency Hi Richard, I agree that the Currency should be constant unless the monetary system changes, regardless of the changing value. However that’s not what is implied by Monetary_Amount being a subclass of Dimension, where the actual value is independent of the approximation. For the subclass to be valid, the features of the parent class must be valid for the child class (All Persons are Actors, and all of the features of Actor are valid for Person). Ergo, the proposed structure is invalid, or the scope notes for Dimension should be changed to say that 6 inches is the face value, not the independent absolute value. Regarding the URI discussion, the URI would not be the value of the Monetary_Amount, just its identifier. For example, if three artworks each sold for $100, the instance of Monetary_Amount referenced from each Purchase can be the same instance. In short hand: _:p1 a Purchase ; transferred_ownership_of _:object1 ; sale_price . _:p2 a Purchase ; transferred_ownership_of _:object2 ; sale_price . _:p3 a Purchase ; transferred_ownership_of _:object3 ; sale_price . a MonetaryAmount ; value 100 ; currency . And from your second email, I agree (per your point 3) that P181 is unnecessary if a Monetary_Amount is a Dimension. And an equivalent case of pounds, shillings and pence for your point 4 would be also important to take into account for currency. Both could be solved by allowing sub-values of a larger whole: _:total a Dimension ; consists_of [ a Dimension ; value 3 ; unit ], [ a Dimension ; value 6 ; unit ] . The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. The approach taken by timespan with begin_of_the_begin and end_of_the_end might be appropriate to duplicate here, if recording the precision is important. Rob On 1/4/17, 12:23 AM, "Crm-sig on behalf of Richard Light" wrote: On 2017-01-03 11:01 PM, Robert Sanderson wrote: All currency amounts have an absolute value that changes constantly due to inflation and markets, and there’s no way to associate a date with the amount instance to capture this. This seems somewhat in conflict with being a subclass of Dimension, which is “the true quantity, independent from its numerical approximation, e.g. in inches or in cm.” – in other words the absolute value, independent of the unit, which is in this case the currency. Assuming that E96 Purchase is a subclass of E7 Activity, it will have the opportunity to record an associated date. I think you are over-thinking what it is feasible to record here: if a specified price was paid for an object on a specified date, surely that's all you need to record - in fact it's all you can record. It is for others to make their own deductions as to the 'real' value (in some sense) of that monetary amount. As a thought experiment, if the unit of an “inch” were to change definition to be exactly 2.5 centimeters, then I believe from the description of Dimension, that the lengths would remain the same in absolute value, and we would need a new unit for “new inches”. This is not practical for currency, as we would need new units constantly … which is also forbidden by the scope notes of currency: “One monetary system has only one currency”. So how are we to deal with comparisons over time? I think that the only case where we should b
