Dear CRM-SIG, In advance of the Oxford meeting, and with regard to on-going development of CRMarchaeo, Martin has asked me to post some of the "major issues you see (structural questions / concerns) to crm-sig for discussion in time before the meeting, so we can estimate the time we need to discuss".
I would refer you to the email I already sent to CRM-SIG on 25th Sep 2014 which I think still summarises a number of queries several of us (cc'd here) have, which are still relevant to the latest version 1.2.1 (draft). I saw my email posted on 26th Sep 2014 as Crm-sig Digest, Vol 92, Issue 18 Subject - "Congratulations and further comments". I've included an (edited) summary paragraph of that email here below for reference. 1. Some clarification on the relationship between A2 Stratigraphic Volume Unit and A3 Stratigraphic Interface is needed, particularly with respect to AP12 Confines. 2. Likewise with the A2 genesis and contains/confines. 3. Also more could be done to represent the temporal relationships for the events leading to the stratigraphic sequence/matrix which is so integral to relating much of the other data from excavations. We think from STAR project research (ref: http://intarch.ac.uk/journal/issue30/tudhope_index.html) that some sub-properties of Allen, to accommodate stratigraphic sequences, may be required and prove very beneficial for integration and inferencing over stratigraphically related datasets (e.g. a 'Stratigraphically directly before/after' is not necessarily temporally synonymous with the Allen p120 Occurs Before/Occurs After). It would be advantageous if such small but very significant amendments could be incorporated in the CRMarchaeo model rather than requiring further extensions in the future. Following on from those comments we have had some further discussions by email (but not at SIG as far as I know) dealing particularly with points 1. & 2. Above. I have included (or added to) relevant extracts from those emails below: With regard to choosing how to express the properties of archaeological Physical Relationships (AP11): I believe what we need is a way to explicitly 'semantically' express that some Physical Relationships only 'make sense' between A2s (deposits/volumes) and A3s (cuts interfaces) while some only 'make sense' between A2s and A2s; and some only between A3 (cut interface) and both A2s - A3s. So expressing this archaeologically: A2 (deposit) Fills A3 (cut interface) - but cannot be a relationship with A2 i.e. A2 (deposit) cannot Fill an A2 (deposit) A3 (cut interface) Is Filled by A2 (deposit) - but cannot be a relationship with A3 i.e. A3 (cut) cannot 'is Filled by' an A3 (cut) A3 Cuts A2 or A3 - A3(cut) can 'Cuts' either A2 (deposit) or A3 (cut) A2 or A3 Is Cut by A3 - cannot have a 'is cut by' relationship with A2 (deposit) A2 (wall) Is bonded with A2 (wall) - cannot have a 'Is bonded with' relationship to A3 A2 (wall) Butts A2 (wall) - cannot have a 'Butts' relationship to A3 A2 (wall) Butted By A2 (wall) - cannot have a 'Butted by' relationship to A3 A2 Jointed with A2 (timber) - cannot have a 'Jointed with' relationship to A3 Following email exchanges with Gerald Hiebel and Martin, it was suggested that to express these archaeological relationships we should use 'properties of properties' (i.e. Properties: AP11.1 has type: E55 Type), rather than what was our preferred approach of using sub-properties. By further emails, Ceri Binding and I considered the ways to include the semantics of the above in RDF and the following email extracts outline our issues between using either 1) sub-properties or 2) Properties of Properties (PoPs): With sub-properties you can declare the type of thing permissible on both sides of the relationship (e.g.): archaeo:AP11c_fills rdfs:domain archaeo:A2_Deposit; rdfs:range archaeo:A3_cut_interface . You can't do that with the 'property of a property' approach (i.e. Properties: AP11.1 has type: E55 Type). I think we need to clarify exactly how this 'property of a property' pattern (let's call them POPs...) is actually meant to be implemented. A comment at the top of the current RDFS implementation of CRM says: RDF does not support properties of properties, therefore, users may create their own subProperties for CRM properties that have a type property such as "P3 has note": Instead of P3 has note (P3-1 has type : parts description) declare <rdf:Property rdf:about="P3_parts_description"> <rdfs:domain rdf:resource="E1_CRM_Entity"/> <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/> <rdfs:subPropertyOf rdf:resource="P3_has_note"/> </rdf:Property> Hence the sub properties approach as described. This "3.1" property and the 14 other similar POPs described in the CIDOC CRM documentation are NOT actually implemented in the available RDFS encoding. I had a (quick) look for other examples of implementation in CRM implementations: CIDOC CRM RDFS encoding - none of the POPs are implemented - none exist in the RDFS file (apart from that text note - advising to use sub-properties instead) ERLANGEN CRM - no POPs are apparent in their OWL encoding of CRM British Museum - Looked through their 'mapping manual' draft, 395 pages, no mention of any of the documented POPs. In the case of P3_has_note they have extended the CRM with sub-properties (precisely as described above) for specific note types - e.g. http://collection.britishmuseum.org/resource/bmo/PX_physical_description CLAROS - No usage examples of POPs found on CLAROSNET.org/wiki<http://CLAROSNET.org/wiki> where they document their RDF patterns and examples The problem in the context of ARIADNE is that I don't see the way to do it with controlled vocabularies as described by crmArchaeo for physical and stratigraphic properties. Gerald's answer characterised the POP pattern as "modelling with intermediate class" but I couldn't really visualise what that means. Taking the simple example of a resource having a note, where the note has a particular type: TURTLE: @prefix crm: < http://www.cidoc-crm.org/cidoc-crm/> . <x> crm:P3_has_note "this is the text"@en . Q. how/where would we attach a note type e.g. 'parts_description'? We can't directly attach it to the P3 property itself as the note type is really the type of this particular instance - i.e. other instances of P3 might have different note types. We cannot in any case reference property CRM P3.1 - it has no URI because it does not actually exist in any of the RDFS/OWL encodings. We cannot reference the possible various note types as they are expected to come from some external controlled vocabulary which does not exist (if it did it would not be agreed on!) The sub-property pattern seems to be THE way to approach this for RDF implementations, but in this instance we have been told it should be an optional future extension. Has anyone come across an instance of the POP pattern implemented in the way they describe so we can see how it is meant to be done? Sorry this is lengthy, but I feel it necessary to try to represent the different perspectives and inputs. Hope this is useful. Best wishes Keith May Doug Tudhope Ceri Binding Paul Cripps English Heritage is Changing From spring 2015, we shall become Historic England, a Government service championing England's heritage and giving expert, constructive advice, and English Heritage, a charity caring for the National Heritage Collection of more than 400 historic properties and their collections. This e-mail (and any attachments) is confidential and may contain personal views which are not the views of English Heritage unless specifically stated. If you have received it in error, please delete it from your system and notify the sender immediately. Do not use, copy or disclose the information in any way nor act in reliance on it. Any information sent to English Heritage may become publicly available.
