Issue 267: CRMarchaeo - Congratulations and further comments
Posted by Keith May on 25/09/2014
We understand that the latest version 1.2 of CRMarchaeo (http://www.ics.forth.gr/isl/index_main.php?l=e&c=711) is due to be presented at the SIG meeting next week. This is welcome news and very good progress.
However despite some of us having been closely involved in the early 'birth & development' of these extensions We are not sure at this point what the latest trajectory for comments on CRMarchaeo is?
Is there a mechanism whereby the current version will be made open for 'Review' to CRM-SIG members who cannot attend the meeting, either before, after, or as part of the agenda of the meeting and if so can you provide direction on that?
The last version we saw (after CAA Paris) dated April2014 looked very positive and definitely reflected major progress and excellent efforts towards completing this complex work. However it remained unclear at that time (and still) how some of our feedback on more detailed modelling of the stratigraphic and physical relationships that derived from CRM-EH modelling (http://www.cidoc-crm.org/docs/Ontological_Modelling_Project_Report_Sep2004.pdf) and further research potential arising from implementations of such modelling during the STAR project (http://hypermedia.research.southwales.ac.uk/kos/star/) had been represented in the drafts of CRMarchaeo. We’d particularly like to see a bit more detail on the physical relations (such as Filled by, Fill of, Cut by, Cuts) between A8 Stratigraphic Unit and A2 Stratigraphic Deposit Unit and A3 Stratigraphic Interfaces, along with more consideration of the stratigraphic inferencing that is proposed for A5 Stratigraphic Modification using AP13 'Has stratigraphic relation'. The suggestion for an appendix that "illustrates an example for stratigraphic and spit excavation and shows how these two types of excavation methodology would be represented with CRMarchaeo" sounds like a very helpful idea, but I don't know if that has been achieved yet?
Also we note that the reference document for CRMarchaeo still has a number of scope notes to be completed (e.g. A5 Stratigraphic Modification) which makes consideration of some of these issues harder.
There are no dramatic incompatibilities between CRMarchaeo as it now stands and CRM-EH. The further modelling of CRM-EH took a slightly different path and clarified the CRM-EH classes, subtyping them where necessary to achieve a more explicit model, but one which is geared to representing the single context recording methodology used in the UK (and more widely). The more generic approach taken in CRMarchaeo is to accommodate a broader range of excavation techniques (Spits, Planum, Locus, etc).
For the enhancement of CRMarchaeo we can provide more detailed feedback on the following if directed how.
Some clarification on the relationship between A2 and A3 is needed, particularly wrt AP12. Likewise with the A2 genesis and contains/confines. 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 research 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.
So the main question we have is how best to feed these elements into the process for acceptance and use of CRMarchaeo?
In 31st joined meeting of the CIDOC CRM SIG, ISO/TC46/SC4/WG9 and the 24th FRBR - CIDOC CRM, discussing the CRMarcheo made the following comments:
· Achille and Paola will improve the scope notes.
· The status of the document is a draft under revision by Gerald Hiebel . (new version by Gerald is attached to this issue)
· Gerald will communicate with EH-CRM Keith May.
· Carlo and Gerald will work together on how to represent AP14
Heraklion, Crete, October 2014
Posted by Keith May, Doug Tudhope, Ceri Binding, Paul Cripps 23/01/2015
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.):
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
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 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:
@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.
Posted by Martin 24/1/2015
Thank you very much! Will you be able to attend and explain details?
I would however
like to explain the methodology we follow. All models we make and recommend in CRM-SIG are
evidence based on existing data structures. The level of detail is deliberately limited to that
needed to explain and integrate existing documentation practice. Any other expert requirement
or wish we regard as subject for research and not for standardization. This is in no ways ignoring
the validity and need of such a request, it is only a question of practicality to be sure only consolidated
concepts enter standardization.
If you propose:
"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."
we need evidence of documentation structures that are significantly used and express such forms. Otherwise,
please propose a compatible extension.
Please note, that there is no sense of restriction to the properties declared in any CRM model when you use the model, because subsumption of properties make any extension imply the previous one automatically.
The concern is that standardization must make sure concepts are sufficiently stable, not only useful.
Note also, that no model is ever "closed". Extension is not a question of closing, but of functional specialization.
A way forward could be to explore all "physical relationships vocabularies" across countries, and when this can be consolidated, we can update CRMarcheo. For that, we would need volunteers!!.
I fully agree that "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 "
The issue is mathematically and epistemologically absolutely non-trivial. A student of mine has just
finished a Master Thesis on this problem. See also his paper:
"Fuzzy Times on Space-time Volumes
Manos Papadakis, Foundation of Research and Technology - Hellas (FORTH), Greece" in e-Challenges 2014.
It appears that several Allen relations cannot be applied to real research as they are represented in CRM currently, because they rely on un-physically precise time-intervals.
I'd argue that this is another important issue not yet mature for standardization.
The POPs are now possible, CRM RDFS is officially extended by "property classes". A reasoning component can
infer a subproperty solution and vice-versa, so, logically, both are equivalent now, performance wise, they are not .
Please let me know, if this already covers your concerns with the current version, or not.
All the best,
Posted by Christian Emil 1/2/2015
CRMarchaoe is interesting and seems to be well founded. However, the property AP14 justifies(is justification of) is a property between properties. This may make it impossible to express the model in first order logic since such a construction at least at a first glance of second order. Any comments?
Posted by Paul Cripps on 8/2/2015
Hi Martin, all,
Both Keith and I will be in attendance for discussion. Looking forward to seeing everyone in Oxford.
Just to firm up proposals for discussion relating to archaeological extensions, there are three main issues arising:
1. Physical Relationships
2. Refinement of Allen to give a robust ‘stratigraphically before/after’ relationship
3. Implementation of these POPs
Beginning with 3, I think some examples of how this can be achieved in the way you mention would be good and probably sufficient.
2 is essential to be able to make sense of stratigraphy. Would a specialisation here suffice, this could easily be illustrated and given a scope note. It would basically have to describe the situation of being directly before (in the sequence of stratigraphic events) but not necessarily directly before (wrt its timespan).
1 is essential as it forms a core part of archaeological documentation. All single context based recording systems (and their resultant documentation) include physical relationships as it is from the observation, description and documentation of these that stratigraphic sequences are inferred. A key physical relationship for example is cuts/cut by. With respect to built structures, whether a component is ‘butted to’ or ‘bonded with’ tells us about the construction sequence. Having the kind of logic Keith notes as part of the semantic structure would be more useful for the kinds of checking/validating (eg of Harris matrices), querying and inferencing we would like to be able to do; eg Being able to visualise a timeline by eg artefact dating vs recorded physical relationships vs inferred stratigraphic relationships would be a good use case for archaeological resources. Using subclasses/subproperties rather than types+vocabs would also give greater robustness due to more focussed domain/range/properties.
See you in Oxford,
In the 32nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 25th FRBR - CIDOC CRM Harmonization meeting and during the presentation of CRMBA by of Paola Ronzino, the sig assigned to Achille and Paola to write the introduction of CRMarcheo, to add text to the figures. The examples should be from a real or fictitious excavation and in collaboration they will improve the scope note and the examples.
Two weeks before the Nuremberg meeting, they will send a new version of CRMarcheo without buildings. Then we will have a second version with the buildings.
Oxford, February 2015
In 33rd meeting the crm - sig decided the following.
- A unified view should be added in the text of CRMarcheo.
- It should be clear what CRMarcheo does not enforce.
- EH-CRM is more specific while CRMarcheo is more general.
- Achille should send communicate with Keith for mapping CRMarcheo and EH – CRM. Also Achille should check with Gerald the coverage with archaeological records and CIDOC CRM, the classes that are instantiated.
-The scope note of A3 should be revised.
- The crm-sig decided that that PIN Prato will be responsible for the CRMarcheo from now on.
This is issue is closed. The discussion for CRMarcheo will continue to the issue 282.