Issue 267: CRMarchaeo - Congratulations and further comments

Starting Date: 
2014-09-25
Status: 
Done
Closing Date: 
2015-02-12
Background: 

Posted by Keith May, Paul Cripps, Doug Tudhope, Ceri Bindingon  on 25/9/2014

Dear CRM-SIG,

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.
 

In Summary, 

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  Gerald Hiebel  on 21/10/2014

Dear Keith,

Thanks for the message and sorry for the late reply from my side. Chryssoula is preparing the latest version of CRMarchaeo for the CRM-SIG minutes and will send it around with the tasks that have been assigned and discussed.

As I just finished the parts that have been discussed in the CRM-SIG meeting, I send you preliminary this latest version as I do not know when Chryssoula will be able to send out the minutes and I wanted to do it for a long time. Please have a look at the proposed theoretical solution for relating stratigraphic to physical relationships. How to implement it is not clear to me yet, but I am not a guru there.

What we would need is a paragraph on EHCRM compatibility. Maybe you could make a proposition or we work together on something? Still scope notes have to be improved....

Best,

Gerald

Posted by Keith May on 29/10/2014

Hi Gerald,

I’m happy to work with you on a piece of text for the CRMarchaeo documentation to cover CRM-EH/CRMarchaeo compatibility – indeed it’s something I think we’ll need to advertise in future presentations and in papers more widely as the CRMarchaeo comes into wider circulation and use and people will want to know how it fits with earlier CRM-EH work.

I like the inclusion in the document of the stratigraphic diagrams which certainly help to explain the fundamentals for archaeologists (and even with the ‘spit’ inserted to refer to differing methodologies! J ).

We briefly mentioned in the previous email to CRM-SIG that we don’t see any ‘dramatic incompatibilities between CRMarchaeo as it now stands and CRM-EH“  .

But how we phrase the ‘degree of compatibility’ in the text for the document, for me and Paul, rather depends on the degree to which the comments about the stratigraphic relations and reasoning sent to CRM-SIG are taken on board.

I cannot see in the text document you have sent that it has accounted for some of the issues we highlighted with how Cuts, Fills and Interfaces actually relate.

While an A3 Interface (of E55 type ‘cut’) can/will confine an A2 deposit (of E55 type ‘Fill’)

A3 Interfaces (of type cut) always also ‘cut’ other A2 deposits which they do not AP12 confine

e.g. In the section example Fig 4. A3 [3] does ‘AP12 confine’ but it also physically ‘cuts’ (4) & (15) without AP12 confining them at all.

I still don’t think this works as currently shown in the modelling inserted in the document (and I think is not helped by “AP5 Cuts” relation being used for the archaeological activity of A1 Excavation Process Unit excavates an A8 Stratigraphic Unit).

I also note a highlight in the scope note text of A3 which may relate to some uncertainty on this.

One event of removal process may produce many stratigraphic interfaces - I wouldn’t say so. It produces One stratigraphic interface, and Many physical interfaces.

1 stratigraphic relation = 1 event (of uncertain duration). I think that’s pretty fundamental to stratigraphic recording.

I do think some of this might be helped if we see what you mean by the outcome of  “Chryssoula is preparing the latest version of CRMarchaeo for the CRM-SIG minutes and will send it around with the tasks that have been assigned and discussed”

Paul wrote some fuller comments which I only outlined in my email to the CRM-SIG for the sake of brevity, and because I was hoping for a response that suggested who we should actually address them to. I am sending these now to you, Maria and Martin (see attached for ref), as they may help explain more of the specific issues and how we think they might be resolved.

The CRMarchaeo is already very good, but I think it would be great if we can just get these small but important revisions/additions included, which are also supported from Doug and Ceri’s actual implementation experience in STAR, and which I think will raise issues if ARIADNE plans to implement CRMarchaeo using actual archaeological data.

Posted from Gerald Hiebel on 10/11/2014

Sorry for the late response, it always takes me some time to get my head around the CRMarchaeo issues;-).

1.       Great that we can work together CRM-EH/CRMarchaeo compatibility

2.       Question on “How Cuts, Fills and Interfaces actually relate”

We moved the type “Cut, Fill, ...” to the property “AP11.1 has type” which is attached to “AP11 has physical relation”, as displayed in Figure 5 and 7. So A3 [3] can have several  “physical relations” of type “cuts” to other “A8 Stratigraphic Units” like illustrated in Figure 5.

Apart from that an A3 may “AP12 confine” several A2 Volume Units (We came up with “Volume” instead of “Deposit” based on your earlier comments, what is your opinion?).

Do you think this model can describe the situation or are we missing something? Maybe we have to try to model all the relations in the example and then see if something is missing.

3.    “One event of removal process may produce many stratigraphic interfaces - I wouldn’t say so. It produces One stratigraphic interface, and Many physical interfaces. 1 stratigraphic relation = 1 event (of uncertain duration). I think that’s pretty fundamental to stratigraphic recording.”

I believe you are right here and we have to correct that.

4.       Maybe we should try to model an example with Pauls latest model and with CRMarchaeo to see what’s missing or if there are places where we are uncertain if the semantics are correct.

Does anybody has a suggestion how we proceed organisationally with the review process of CRMarchaeo. Some people are doing bits and pieces, but we probably need a place where to put the latest version for review and comments and maybe somebody to organise the collaboration.

 

Posted by keith May on 12/11/2014

Hi Gerald,

I note and agree your final point “but we probably need a place where to put the latest version for review and comments and maybe somebody to organise the collaboration.”

I guess a place that shows the latest reviewed version is something ARIADNE partners will need too in due course?

1. Yes, and should be easier if we get a place to share the ‘latest/current’ version.

3. Thanks for confirmation

4. Sounds good but not sure how much time/resource is available in the near future (i.e. Paul and me), but again a shared review space might help with that too ?

2. With regard to choosing how to express the properties of Physical Relationships:

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

In an email exchange with Ceri we considered the ways to include the semantics of the above and he sent the following outline of how to express the relationships in (generalised) RDF.

Yes 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 think it does matter, otherwise may just as well use a totally generic model with zero semantic implications:

:Fred has_property (has_type=’name’) “Fred”;

                has_property (has_type=’age’) “52”;

                has_property (has_type=’gender’) “male”.

Etc.

A slightly more complete answer, although only to the points you raised, not necessarily an exhaustive model of all possible physical relationships

– no property number identifiers but you get the idea:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix archaeo: <http://www.ics.forth.gr/isl/CRMarchaeo/> .

archaeo:fills rdfs:label "fills"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                rdfs:domain archaeo:A2_Stratigraphic_Deposit_Unit ;

                rdfs:range archaeo:A3_Stratigraphic_Interface ;

                owl:inverseOf archaeo:is_filled_by .

archaeo:is_filled_by rdfs:label "is filled by"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                owl:inverseOf archaeo:fills .

archaeo:cuts rdfs:label "cuts"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                rdfs:domain archaeo:A3_Stratigraphic_Interface ;

                rdfs:range [owl:unionOf (archaeo:A2_Stratigraphic_Deposit_Unit archaeo:A3_Stratigraphic_Interface)] ;

                owl:inverseOf archaeo:is_cut_by .

archaeo:is_cut_by rdfs:label "is cut by"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                owl:inverseOf archaeo:cuts .

archaeo:is_bonded_with rdfs:label "is bonded with"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                rdfs:domain archaeo:A2_Stratigraphic_Deposit_Unit ;

                rdfs:range archaeo:A2_Stratigraphic_Deposit_Unit .

archaeo:butts rdfs:label "butts"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                rdfs:domain archaeo:A2_Stratigraphic_Deposit_Unit ;

                rdfs:range archaeo:A2_Stratigraphic_Deposit_Unit ;

                owl:inverseOf archaeo:butted_by .

archaeo:butted_by rdfs:label "butted_by"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                owl:inverseOf archaeo:butts .

archaeo:jointed_with rdfs:label "jointed with"@en ;

                rdfs:subPropertyOf archaeo:AP11_has_physical_relation ;

                rdfs:domain archaeo:A2_Stratigraphic_Deposit_Unit ;

                rdfs:range archaeo:A2_Stratigraphic_Deposit_Unit .

N.B.  Gerald: Above & Below – seem to have ‘crept’ into the CRMarchaeo documentation for AP11 “has physical relation” but are Not physical relationships that EH (or MoLAS and others) specifically record in the field as a standard part of Single Context Recording. (if used they can create confusion with stratigraphic relationships, so although clearly such relationships exist - along with others like ‘adjacent’ - we would not include them in the AP11 scope note).

p.s. “Volume” instead of “Deposit” works OK I think and is certainly more generic to cover structural timbers, walls, etc – I can’t suggest anything better.

Hope that helps.

Current Proposal: 

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

Outcome: 

In the 33rd  CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 26th FRBR - CIDOC CRM Harmonization meeting, the crm - sig meeting 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.

Nuremberg, May 2015

Available Documents: 

Reference to Issues: