Martin, 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.” and “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.” Thanks, Rob From: Crm-sig <crm-sig-boun...@ics.forth.gr> on behalf of Richard Light <rich...@light.demon.co.uk> Date: Thursday, March 8, 2018 at 12:02 AM To: Martin Doerr <mar...@ics.forth.gr> Cc: George Bruseker <george.bruse...@gmail.com>, crm-sig <crm-sig@ics.forth.gr> Subject: Re: [Crm-sig] P90 etc. Martin, 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, Richard 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 values As 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] * The recommended RDFS implementation of the CIDOC CRM may further refine the range of these properties to more specific datatypes, if not yet done. Recording names Apart 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 Documenting 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. In cases where there is nothing more to say about the E41_Appellation, P1_is_identified_by should be replaced by rdfs:label (“rdfs:label is an instance of<https://www.w3.org/TR/rdf-schema/#ch_property> rdf:Property<https://www.w3.org/TR/rdf-schema/#ch_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 > rdfs:Literal<https://www.w3.org/TR/rdf-schema/#ch_literal>. Since RDFS does not qualify the range of rds:label further, we cannot formally make rdfs:label a subproperty of P1_is_identified_by or vice-versa. We can only register the convention and take care that query systems retrieve labels together with instances of P1_is_identified_by . 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: "xsd:decimal<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal>, xsd:float<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#float>, xsd:double<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#double>, xsd:hexBinary<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#hexBinary>, xsd:base64Binary<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#base64Binary>, xsd:integer<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#integer>, xsd:nonPositiveInteger<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonPositiveInteger>, xsd:negativeInteger<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#negativeInteger>, xsd:long<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#long>, xsd:int<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#int>, xsd:short<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#short>, xsd:byte<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#byte>, xsd:nonNegativeInteger<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonNegativeInteger>, xsd:unsignedLong<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedLong>, xsd:unsignedInt<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedInt>, xsd:unsignedShort<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedShort>, xsd:unsignedByte<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedByte>, xsd:positiveInteger",<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#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"? Best, Martin -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(2810)391625 | Research Director | Fax:+30(2810)391638 | | Email: mar...@ics.forth.gr<mailto:mar...@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
