[Crm-sig] CRMArcheo and CRM-SIG in Oxford

Christian-Emil Smith Ore c.e.s.ore at iln.uio.no
Sun Feb 1 23:37:47 EET 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

>-----Original Message-----
>From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of martin
>Sent: Saturday, January 24, 2015 6:11 PM
>To: crm-sig at ics.forth.gr
>Subject: Re: [Crm-sig] CRMArcheo and CRM-SIG in Oxford
>
>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.
>
>All the best,
>
>Martin
>
>On 23/1/2015 8:36 μμ, May, Keith wrote:
>
>
>	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
>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.
>
>
>
>
>
>
>	_______________________________________________
>	Crm-sig mailing list
>	Crm-sig at ics.forth.gr
>	http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
>--
>
>--------------------------------------------------------------
> Dr. Martin Doerr              |  Vox:+30(2810)391625        |
> Research Director             |  Fax:+30(2810)391638        |
>                               |  Email: martin at 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           |
>--------------------------------------------------------------




More information about the Crm-sig mailing list