[Crm-sig] P90 etc.

Stephen Stead steads at paveprime.com
Thu Mar 8 19:55:43 EET 2018

Gets my vote.

Wide is good


Stephen Stead

Tel +44 20 8668 3075 

Mob +44 7802 755 013

E-mail  <mailto:steads at paveprime.com> steads at paveprime.com

LinkedIn Profile  <https://www.linkedin.com/in/steads/> https://www.linkedin.com/in/steads/


From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of Richard Light
Sent: 08 March 2018 17:30
To: Robert Sanderson <RSanderson at getty.edu>; Martin Doerr <martin at ics.forth.gr>
Cc: George Bruseker <george.bruseker at gmail.com>; crm-sig <crm-sig at ics.forth.gr>
Subject: Re: [Crm-sig] P90 etc.



I'm suggesting that we take a step back from this sort of ad hoc decision making, as noted two messages down.  We can come back to the question of which RDF properties to use once we are equipped with information on community practice as well as W3C/ISO norms.

If the group agrees, I propose to draft a call for examples of RDF practice which we can put out to the MCG and MCN lists (for the museum community), and to whatever library and archive lists we can find.


On 08/03/2018 16:28, Robert Sanderson wrote:




Could you clarify why you have changed your mind about rdf:value?


> I recommend NOT to recommend rdf:value


In particular, in the last week you said:


“CRM-SIG normally works reactively: When a good community practice emerges, this is taken up.”




“Whatever the vast majority is  and rdf:value does the job, I have no objections to its use.
Just define precisely what you use it for. We can add that to our guidelines. It is already standard rdf.”







From: Crm-sig  <mailto:crm-sig-bounces at ics.forth.gr> <crm-sig-bounces at ics.forth.gr> on behalf of Richard Light  <mailto:richard at light.demon.co.uk> <richard at light.demon.co.uk>
Date: Thursday, March 8, 2018 at 12:02 AM
To: Martin Doerr  <mailto:martin at ics.forth.gr> <martin at ics.forth.gr>
Cc: George Bruseker  <mailto:george.bruseker at gmail.com> <george.bruseker at gmail.com>, crm-sig  <mailto:crm-sig at ics.forth.gr> <crm-sig at ics.forth.gr>
Subject: Re: [Crm-sig] P90 etc.



Thanks for updating the string part of the RDF implementation doc.

I was thinking last night that maybe we should focus our RDF efforts on exactly this issue: the representation of the CRM primitive classes E60, E61 and E62 in RDF.  The current RDF document is becoming quite wide-ranging in its scope, and (for example) you have questioned whether certain sections belong in it.  If we concentrate on this single aspect of the broader RDF issue, I think we can produce something which is of practical value relatively quickly.  In particular, I would like to devote time to this during the Lyon meeting.

It seems to me that there are three elements which need to be considered when recommending an approach:

*	the CRM's own view on what information should be expressible, and how (in an abstract sense) it should be represented 
*	RDF and other W3C/ISO recommendations and standards for representing string-type information 
*	the view of communities of practice on the issues involved, and the solutions they have come up with 

In particular I think it important that we should consult widely on this issue, and be seen to take account of existing community practice.

Best wishes,


On 06/03/2018 17:54, Martin Doerr wrote:

Dear Richard,

It would be really great if you could join our next meeting!

We need your help to finish the RDF guidelines.
I have rewritten the string part in the google doc:

"Recording string



mentioned in point 3 above, the RDFS Schema does not implement the CRM primitive classes E60 Number, E61 Date or E62 String.  Instead it specifies rdfs:Literal as the range of properties which would otherwise take one of these values:

*	P3_has_note
*	 [String]
*	P57_has_number_of_parts
*	 [Number]
*	P79_beginning_is_qualified_by
*	 [String]
*	P80_end_is_qualified_by
*	 [String]
*	P81_ongoing_throughout
*	 [Time primitive] [but see Note 8 above and section on dates below]
*	P82_at_some_time_within
*	 [Time primitive] [but see Note 8 above and section on dates below]
*	P90_has_value
*	 [Number]


recommended RDFS implementation of the CIDOC CRM may further refine the range of these properties to more specific datatypes, if not yet done.




from the seven properties listed above, there are a number of situations where the fully-worked-out path to a string value leads to an unduly long chain of classes and properties.  For example:

E55_Type > P1_is_identified_by

> E41_Appellation > P3_has_note > E62_String


an instance of E41_Appellation with a URI of its own, is only useful if the instance is expected to be either an object of discourse regardless what it identifies, such as etymology or name variants etc., or if it needs an extended content model with meaningful

parts, such as a street address. 


cases where there is nothing more to say about the E41_Appellation, P1_is_identified_by


be replaced by rdfs:label (“rdfs:label is an instance of

 <https://www.w3.org/TR/rdf-schema/#ch_property> rdf:Property

that may be used to provide a human-readable version of a resource's name”, in: RDF Schema 1.1)

E55_Type > rdfs:label >

 <https://www.w3.org/TR/rdf-schema/#ch_literal> rdfs:Literal.


RDFS does not qualify the range of rds:label further, we cannot formally make rdfs:label a subproperty of


or vice-versa. We can

only register the convention and take care that query systems retrieve labels together with instances of


. The fact that the same

name “Martin Doerr” may appear in different encodings is inevitable. It is recommended to use name spelling conventions from library cataloguing rules and SKOS properties for instances of  E55_Type.


Please comment!

I have discussed with George that we should make several distinctions:

Only digitized content can be stored in-line in the KB as Literal. 

There must be a comparable way to point to a digitized content via URI, URL, or literal. All representations of Symbolic Objects in electronic form are ambiguous wrt the the intended level of symbolic interpretation: Is it the bits, or the Latin1 characters, or characters + font make up its identity?

We must distinguish between digital content of a symbolic object, a general "note" about an individual, and values in a mathematical/ physical space. 

I recommend NOT to recommend rdf:value: 

"5.4.3 rdf:value rdf:value is an instance of rdf:Property <https://www.w3.org/TR/rdf-schema/#ch_property>  that may be used in describing structured values. rdf:value has no meaning on its own. "

We definitely need a recommendation for names, regardless how complex it becomes.

When we created the RDF version, there were no datatype recommendations. Now, that there are, we should remove "rdfs:Literal from all properties in which it is unambiguous.

I kindly ask you to check https://www.w3.org/TR/2004/REC-rdf-mt-20040210/#dtype_interp for  compatible datatypes. This must be well-justified. E.g., "P57_has_number_of_parts [Number]" should have range: 

"xsd:nonNegativeInteger", and not "xsd:decimal". 

E60 Number could be any value from the mathematical multidimensional spaces made of real numbers, such as RGB images. We have no super-representation in RDFS/XSD. We can enumerate compatible datatypes:

 <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal> "xsd:decimal,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#float> xsd:float,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#double> xsd:double,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#hexBinary> xsd:hexBinary,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#base64Binary> xsd:base64Binary,   <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#integer> xsd:integer,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonPositiveInteger> xsd:nonPositiveInteger,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#negativeInteger> xsd:negativeInteger,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#long> xsd:long,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#int> xsd:int,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#short> xsd:short,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#byte> xsd:byte,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonNegativeInteger> xsd:nonNegativeInteger,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedLong> xsd:unsignedLong,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedInt> xsd:unsignedInt,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedShort> xsd:unsignedShort,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedByte> xsd:unsignedByte,  <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#positiveInteger> xsd:positiveInteger",

E61 Timeprimitive could be completely replaced by xsd:dateTime, without causing incompatibilities if more precision/ coverage would be needed.

"Spaceprimitive" should be a WKT string, I think.

Should E62 be xsd:string, or would that cause another outcry to be too complex? 

If someone does not convert values into xsd, is that "incompatible"?





 Dr. Martin Doerr              |  Vox:+30(2810)391625        |
 Research Director             |  Fax:+30(2810)391638        |
                               |  Email: martin at ics.forth.gr <mailto:martin at ics.forth.gr>  |
               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               |
             Web-site: http://www.ics.forth.gr/isl           |


Richard Light 


Richard Light 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180308/62d3f9e1/attachment-0001.html>

More information about the Crm-sig mailing list