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:[email protected]] On Behalf Of martin >Sent: Saturday, January 24, 2015 6:11 PM >To: [email protected] >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 > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > >-- > >-------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: [email protected] | > | > 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 | >--------------------------------------------------------------
