CRMarchaeo - Congratulations and further comments

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.):

 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 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.

Posted by Martin      24/1/2015

 Dear Keith,

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.

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?

Christian-Emil
 

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.

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