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 theemail 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
<http://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 |
--------------------------------------------------------------
