Need a (generic) concept for archaeological context

[ekansa]

We need an entity for archaeological context. A context can have different kind of scale, and may be arbitrarily defined or defined by some observed boundaries (changes in soil, cuts, or features). I'm very open to discussion on how this would relate to various CRM entities (E53.Place, E26.Physical_Feature, etc.).

I don't know if we need to differentiate (archaeological) "site" from "context". A "site" is a term used in convenience and is really hard to define formally, especially in a way that can see any agreement.

[ekansa]

Back to this issue, I want to clarify a few things. Mainly, I'm interested in what people would want to do with a linked data concept for archaeological context. The nuances of archaeological contexts are highly case-specific, and there probably isn't much of a use case for comparing highly nuanced contextual records across multiple datasets. The modeling would be very expensive and complicated, and I doubt that in practice models could be used consistently enough to inspire any confidence.

For Open Context, this may mainly be to differentiate contexts from finds (artifacts, ecofacts), in which case, pretty generic context concepts would be fine, just to indicate that a given Web resource describes a context and not something else. That may be sufficient.

We're experimenting with the English Heritage CIDOC-CRM extensions (http://purl.org/crmeh#) and here are some examples below. Any feedback for this draft use would be welcome:

(1) A bone found in an archaeological context: http://www.w3.org/RDF/Validator/rdfval?URI=http%3A%2F%2Fopencontext.org%2Fsubjects%2F0CF37A48-3C8D-45CA-C7D8-58C2B9F03889.rdf&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED

(2) A an archaeological context record: http://www.w3.org/RDF/Validator/rdfval?URI=http://opencontext.org/subjects/C39B7060-0CA0-4C15-FDE9-025D6CDA32E4.rdf&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED

(3) A description of a site area (a subdivision of an archaeological site. Site areas usually don't have much to do with observed stratigraphic or deposition observations, but are typically a convenient way to subdivide different aspects of an excavation project): http://www.w3.org/RDF/Validator/rdfval?URI=http://opencontext.org/subjects/FC96A49E-FE12-488B-4EFF-02D4E147B885.rdf&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED

(4) An archaeological site (with link to Pleiades): http://www.w3.org/RDF/Validator/rdfval?URI=http://opencontext.org/subjects/871B9EF8-BC68-4190-5F8A-00882C0040A4.rdf&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED

[pauljcripps]

A modelling for this is already done, you're welcome to use it. Nice and generic. Very semantically robust and highly atomic. It's also not that complex, just a handful of events (with types), places and physical stuff: The Events are the core of it, supported by the use of Place (and Physical Stuff)
http://www.cidoc-crm.org/docs/Ontological_Modelling_Project_Report_%20Sep2004.pdf

Some interesting implementations through the STAR and STELLAR projects (English Heritage / University of Glamorgan), drawing on heterogeneous datasets.

In short, context is represented by a Place which allows it to be:

1. identified by some Place Appellations, including coordinates, geometry and/or UIDs, names, etc
2. the location for some Physical Stuff (or not in the case of Cut features) and finds
3. have Spatial Relationships with other places (ie physical context relationships)
4. defined by someone ie an archaeologist excavating it, with documentation produced in this Event

The Physical Stuff (for layers and deposits such as fills) arrived there in the place that is a Context through some Deposition Event and allows us to describe:

1. Physical Properties (colour, texture, composition, etc)
2. sample it through part decomposition Events
3. the Deposition Event itself and any subsequent Modification Events, both natural and anthropogenic
4. relate it spatially and temporally to other Events such as Finds Deposition Events, through which objects get deposited.

It's all tied together through Events, which allows us to talk about finds Deposition Events, Sampling (Part Decomposition Events) stratigraphic relationships (through order of Events), dating through finds (either through Finds Manufacture and Deposition Events and/or scientific measurements), etc. So relative chronology through Event sequences tied to absolute dating (where available) through eg pottery, scientific dating, etc

And there is plenty good reasons for wanting to do this across diverse archaeological excavation datasets. See Cripps & May, 2010 for a discussion on this and how forming patterns from the ontological framework can really help with the modelling.

Sites and Site Subdivisions are also Places. True, definition of an archaeological site (ie monument or group of monuments, observed or implied) can be tricky but easiest to use site in this context (ie archaeological excavation) to mean a spatio-temporal container for some archaeological works. So repeated digs over years would each count as individual 'sites' but could be related to heritage assets, monuments, places, locations, etc as needed. This is based on the model used in developer funded archaeology in the UK and seems to work quite well. Sidesteps the issue of definition of archaeological sites/monuments, them being a different concept.

hth, and discussion always welcome - i'm back working on this again after a short break (of a decade!) focussing this time on the spatial components in more detail.
atb,
P

To OO or not to OO? – Revelations from defining an ontology for an archaeological information system
Paul Cripps, Keith May (2010)
Beyond the artefact – Digital Interpretation of the Past. Proceedings of CAA2004 - Prato 13-17 April 2004

[ekansa]

Thanks Paul, here is a great blog post from https://twitter.com/kgeographer here: http://kgeographer.com/wp/place-v-space/

I don't have that paper Paul. Can you send it? Also, any suggestions on how to improve our RDF? I want to keep it simple but not dumb, if you know what I mean. :)

[CurlyMay]

Hi Eric,
In response to the point "I'm interested in what people would want to do with a linked data concept for archaeological context".
I think defining the stratigraphic units (contexts) used to differentiate different archaeological data are crucial to how we would ask questions that involve 'reasoning' e.g. "Which Finds come from contexts that pre- or post-date others? - ie which contexts are stratigraphically above or below others and that exhibit similar patterns of deposition/formation or similar finds from other sites?" Also any questions about Groups and Phases (e.g. which Buildings were Phased to the 2nd Century) both within and across different sites of broadly similar overlapping Periods are I think going to raise further questions about which Contexts formed, or were part of, those Groups or Phases and what was contained in those contexts.

At least that is how we've used stratigraphic relations in CRM-EH, based on CIDOC CRMs modelling of Allen's temporal operators.

BW
Keith

[ekansa]

HI Paul,

OK, this makes sense to me. My main concern is that we often don't have a
lot of information on context. People that want to publish data with us are
often specialists (zooarch or other) that have their data, some rough
context information (sometimes only identifiers!) and we lack my more
detail about the contexts. So I need something that degrades gracefully in
cases where we're missing information.

It may be good to try to sort this out in the context of real data and a
real research reuse. That would help me identify where we should best
invest in better modeling. I'm very game to play around if you know of
folks with data that can be fruitfully linked up with some of the material
we're publishing.

Best!
-Eric

On Tue, Jun 4, 2013 at 7:41 AM, CurlyMay notifications@github.com wrote:

Hi Eric,
In response to the point "I'm interested in what people would want to do
with a linked data concept for archaeological context".
I think defining the stratigraphic units (contexts) used to differentiate
different archaeological data are crucial to how we would ask questions
that involve 'reasoning' e.g. "Which Finds come from contexts that pre- or
post-date others? - ie which contexts are stratigraphically above or below
others and that exhibit similar patterns of deposition/formation or similar
finds from other sites?" Also any questions about Groups and Phases (e.g.
which Buildings were Phased to the 2nd Century) both within and across
different sites of broadly similar overlapping Periods are I think going to
raise further questions about which Contexts formed, or were part of, those
Groups or Phases and what was contained in those contexts.

At least that is how we've used stratigraphic relations in CRM-EH, based
on CIDOC CRMs modelling of Allen's temporal operators.

BW
Keith

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-18913395
.

[sfsheath]

I am also looking for robust handling of minimal information situations. I don't always know where my contexts are in physical space so I'm not sure they can be crm:E55_Place. It is very rare (maybe never?) for me to know the CRM events that seem to be necessary to tie my data together using that model. I'm also hoping to express that something falls into the wide and loosely construed category of "Archaeological Context" with a single triple that has rdf:type as the predicate. So Eric's use of EHE0007_Context is appealing, so long as I ignore the subclass to (an old?) version of the CIDOC-CRM.

Expanding the conversation a little bit, I'm looking for a "3-triple" solution to sharing the broadly used idea that "An object comes from a context". Something along the lines of

<my_prefix:object1> <rdf:type> <crm:E22_Man-Made_Object>
<my_prefix:context1> <rdf:type> <crmeh:EHE0007_Context>
<my_prefix:object1> <dcterms:isPartOf> <my_prefix:context1>

I don't much mind what the object of the 2nd triple is, and same with the predicate of the 3rd. But I don't want to have to say more than this to allow this idea to be discoverable and reusable for many use cases.

Only concern is adding in the crmeh: prefix. Just wary of prefix growth. I would be happy to see a lawd:ArchaeologicalContext Class that had some form of "owl:equivalentClass" qualification.

[CurlyMay]

You do not need to have precise spatial coordinates to use the concept of Place. In fact in our modelling we have a separate entity CRM E47 Spatial Coordinates to relate (Context)Place to Spatial depiction, if we have one.

The Events too are not always matched to a single piece of data, but we use the concept of a ContextEvent (e.g. Context deposition) to enable us to model the stratigraphic relationship that:
A. If a context exists so that we can record it then Some event must have led to its existence
B. The ContextEvent is stratigraphically before/after the next/previous ContextEvent

Expressing Finds in Contexts will be useful, but watch out for how you use it if your concept of Context also covers "Cuts" or "negative contexts" since Finds do not form parts of e.g. Pit Cuts which we have modelled as Places or 'surfaces' between other contexts.

Best wishes
Keith

On 4 Jun 2013, at 20:48, Sebastian Heath notifications@github.com wrote:

I am also looking for robust handling of minimal information situations. I don't always know where my contexts are in physical space so I'm not sure they can be crm:E55_Place. It is very rare (maybe never?) for me to know the CRM events that seem to be necessary to tie my data together using that model. I'm also hoping to express that something falls into the wide and loosely construed category of "Archaeological Context" with a single triple that has rdf:type as the predicate. So Eric's use of EHE0007_Context is appealing, so long as I ignore the subclass to (an old?) version of the CIDOC-CRM.

Expanding the conversation a little bit, I'm looking for a "3-triple" solution to sharing the broadly used idea that "An object comes from a context". Something along the lines of

rdf:type crm:E22_Man-Made_Object
rdf:type crmeh:EHE0007_Context
dcterms:isPartOf

I don't much mind what the object of the 2nd triple is, and same with the predicate of the 3rd. But I don't want to have to say more than this to allow this idea to be discoverable and reusable for many use cases.

Only concern is adding in the crmeh: prefix. Just wary of prefix growth. I would be happy to see a lawd:ArchaeologicalContext Class that had some form of "owl:equivalentClass" qualification.

—
Reply to this email directly or view it on GitHub.

[sfsheath]

E53_Place starts with "This class comprises extents in space, in particular on the surface of the earth, in the pure sense of physics:" That's not what I'm looking for when thinking about a potential lawd:ArchaeologicalContext Class. It's too specific and tied to the physical world. I also don't want to have to subclass E53_Place to distinguish the object of triples where the subject is lawd:origin.

Take my triples from above but now with E53_Place:

<my_prefix:object1> <rdf:type> <crm:E22_Man-Made_Object>
<my_prefix:context1> <rdf:type> <crmeh:E53_Place>
<my_prefix:object1> <dcterms:isPartOf> <my_prefix:context1>

The 2nd triple in no way communicates that my_prefix:object1 is from an archaeological context. In the part of my work to which LAWD applies, this is a triple that is going to appear along with others that are heterogenous in nature. Citations of primary texts, references to people, references to historical events. For all of these I need (and for some I already have) robust solutions that allow the entities to be strongly typed.

Again, I want to communicate that something is a context with one triple, aka "No blank nodes!!"

I will also be indicating that objects are in contexts where I am not the publisher of the context. As in, secondary scholarship that I bring to publication, and which discusses an object, noting that it is from a particular context. But it makes no further assertions about that context and shouldn't. I want to indicate in unambiguous fashion that the context appearing as a "named entity" in the text is a lawd:ArchaeologicalContext and indicate where further info can be found.

And I do appreciate the utility of the something like crm:ContextEvent. I think I'm right in saying that LAWD is not trying to re-invent that level of specificity. So stratigraphic relationships are out of scope. Rather LAWD is focused (I think) on patterns that promote triple-minimization, in particular fewer blank-nodes, with broad and loosely defined predicates and classes.

So I think I'm on the verge of nominating lawd:ArchaeologicalContext. I'll model it in my fork of the repo and see what people think.

[CurlyMay]

It will be interesting to see what Definition of ArchaeologicalContext you come up with.
Keith

On 5 Jun 2013, at 12:17, Sebastian Heath notifications@github.com wrote:

E53_Place starts with "This class comprises extents in space, in particular on the surface of the earth, in the pure sense of physics:" That's not what I'm looking for when thinking about a potential lawd:ArchaeologicalContext Class. It's too specific and tied to the physical world. I also don't want to have to subclass E53_Place to distinguish the object of triples where the subject is lawd:origin.

Take my triples from above but now with E53_Place:

<my_prefix:object1> rdf:type crm:E22_Man-Made_Object
<my_prefix:context1> rdf:type crmeh:E53_Place
<my_prefix:object1> dcterms:isPartOf <my_prefix:context1>
The 2nd triple in no way communicates that my_prefix:object1 is from an archaeological context. In the part of my work to which LAWD applies, this is a triple that is going to appear along with others that are heterogenous in nature. Citations of primary texts, references to people, references to historical events. For all of these I need (and for some I already have) robust solutions that allow the entities to be strongly typed.

Again, I want to communicate that something is a context with one triple, aka "No blank nodes!!"

I will also be indicating that objects are in contexts where I am not the publisher of the context. As in, secondary scholarship that I bring to publication, and which discusses an object, noting that it is from a particular context. But it makes no further assertions about that context and shouldn't. I want to indicate in unambiguous fashion that the context appearing as a "named entity" in the text is a lawd:ArchaeologicalContext and indicate where further info can be found.

And I do appreciate the utility of the something like crm:ContextEvent. I think I'm right in saying that LAWD is not trying to re-invent that level of specificity. So stratigraphic relationships are out of scope. Rather LAWD is focused (I think) on patterns that promote triple-minimization, in particular fewer blank-nodes, with broad and loosely defined predicates and classes.

So I think I'm on the verge of nominating lawd:ArchaeologicalContext. I'll model it in my fork of the repo and see what people think.

—
Reply to this email directly or view it on GitHub.

[sfsheath]

As indicated on twitter, I've taken a first try at language that instantiates lawd:ArchaeologicalContext as an rdfs:Class and which places that class within the scope of rdf/linked data enabled archaeological discourse rather than necessarily within the scope of any alternate and fully-articulated model or any particular assumption about field work practices. As in, we must not use must. ;-) [1]

You can see it at sfsheath@6441f29#ontology/lawd.rdf (though I forgot to edit the comment [whoops]).

It includes:

<rdfs:comment>The LAWD class ArchaeologicalContext is an indication that an rdf:Resource with this rdf:type can be used in archaeological discourse to assert and infer information about the circumstances of discovery, reliability and location of the resource itself and of entities that are associated with the context.</rdfs:comment>

"Human discourse" has analogy with Linked Data "Follow your nose". Dereference the URI said to be a lawd:ArchaeologicalContext to find further information that may be useful in your understanding of the rdf resources that are said to be from that context. As with rdfs:seeAlso there are no guarantees about the nature of the information that you'll get when you perform that dereference. In a perfect world, there might be rich CIDOC-CRM data. But the world ain't perfect so be careful out there.

I haven't issued a pull request yet but, Hugh, how would you react to one? Thanks. -S.

[1] Though I have repeated the owl:equivalentClass pattern adopted for other LAWD classes. Just as a convenience.

[ekansa]

Seb,

I think this works very well for the kinds of data we publish in Open Context, where in practice, we typically do not have a great deal of information about "archaeological contexts". I feel more comfortable about making assertions that acknowledge the ambiguity typical in real world practice where data sharing still isn't totally routine, and happens in a piecemeal, fragmentary way.

The CRMEH seems like a great model to aspire toward, especially for a project like Catalhoyuk with lots of data ranging from rich context descriptions down to finds descriptions, people, etc.

I guess I'm wondering what I should do. In some cases, I can tell the difference between a "CRMEH: site subdivision" (or "CRMEH: area of investigation") and a "CRMEH: context"), and I can rdf:type entities with some degree of confidence. However, I'm not sure that I necessarily want to imply that my typing to these different CRMEH entities carries with it the whole mess of inference implications. This reflects why I've hesitated in using the CRM at all. While the data we publish clearly relates to these shared elaborate models, I'm not comfortable in claiming the data conforms to these models. If you know what I mean.

Anyway, as I ready your points Seb, it looks like you are working toward having http://lawd.info/ontology/ArchaeologicalContext act as some sort of mediator that can be used to say "here's a very loosely defined 'archaeological context' which may or may not conform to the modeling characteristics of contexts in the CRMEH".

[hcayless]

Sebs,

My initial reaction is that I'm not sure you really want that owl:equivalentClass there if you're distinguishing this from the CRMEH extension class. If you do mean it, I'm not sure what you gain over just using crmeh:Context. I don't think there are any constraints as to how much or how little data you have to hang off a crmeh:Context. Presumably it might just have a label, for example. In your example above, I don't think you could say dc:isPartOf , since a crmeh:Context is a crm:Place and an object can't be part of a spatial extent, but you could say lawd:foundAt as Eric does in his examples, and I think that would be fine. The role LAWD would play then would be just to enable you to record that one fact without having to model an event system in order to do it.

[sfsheath]

Hugh,

I think it's right that owl:equivalentClass is not the appropriate connection between the proposed lawd:ArchaeologicalContext and crmeh:Context or crm:Site/Place (excuse my not using the E #'s). And perhaps it doesn't need connection out to any other ontologies at all. Though some documentation of illustrative semantic overlap is nice in a "we want to be as friendly as possible" sort of way.

I am interested in using dc:isPartOf to relate resources to instances of lawd:ArchaeologicalContext. Its definition is is "A related resource in which the described resource is physically or logically included." [1]

I subsume the trope of archaeological discourse "Question: Where is that piece of pottery from? Answer: Context A." under the phrasing "logically included". If crmeh:Context being a crm:Place precludes that usage, then we really do need lawd:ArchaeologicalContext.[2]

lawd:foundAt probably does have a role in constructing these relationships as well. I hope it's OK to use that or dc:isPartOf as authors see best.

[1] http://dublincore.org/documents/dcmi-terms/#terms-isPartOf

[2] And here's a tangential discussion: It was written above that " A. If a context exists so that we can record it then Some event must have led to its existence". There are edge conditions that undermine such certainty. Surface contexts are really logical constructs into which material logically enters by a large number of processes, including subtraction of surrounding earth through water and wind action that leaves heavier material resting on a new surface, but not part of it. I can't tell you how much I want to avoid such scholastic hair splitting.

[hcayless]

Briefly, because I'm using my phone: I'd have thought that even if what you mean by context is a physical volume of earth, an object is only part of that context when it's in situ. Don't you need a different verb after its been removed?

Sent from my phone.

On Jun 6, 2013, at 21:31, Sebastian Heath notifications@github.com wrote:

Hugh,

I think it's right that owl:equivalentClass is not the appropriate connection between the proposed lawd:ArchaeologicalContext and crmeh:Context or crm:Site/Place (excuse my not using the E #'s). And perhaps it doesn't need connection out to any other ontologies at all. Though some documentation of illustrative semantic overlap is nice in a "we want to be as friendly as possible" sort of way.

I am interested in using dc:isPartOf to relate resources to instances of lawd:ArchaeologicalContext. Its definition is is "A related resource in which the described resource is physically or logically included." [1]

I subsume the trope of archaeological discourse "Question: Where is that piece of pottery from? Answer: Context A." under the phrasing "logically included". If crmeh:Context being a crm:Place precludes that usage, then we really do need lawd:ArchaeologicalContext.[2]

lawd:foundAt probably does have a role in constructing these relationships as well. I hope it's OK to use that or dc:isPartOf as authors see best.

[1] http://dublincore.org/documents/dcmi-terms/#terms-isPartOf

[2] And here's a tangential discussion: It was written above that " A. If a context exists so that we can record it then Some event must have led to its existence". There are edge conditions that undermine such certainty. Surface contexts are really logical constructs into which material logically enters by a large number of processes, including subtraction of surrounding earth through water and wind action that leaves heavier material resting on a new surface, but not part of it. I can't tell you how much I want to avoid such scholastic hair splitting.

—
Reply to this email directly or view it on GitHub.

[hcayless]

Just to follow up: isPartOf would work if what you mean by context is something like "the collection of objects found at this part of the site". Is that what you're after?

Sent from my phone.

On Jun 6, 2013, at 21:31, Sebastian Heath notifications@github.com wrote:

Hugh,

I think it's right that owl:equivalentClass is not the appropriate connection between the proposed lawd:ArchaeologicalContext and crmeh:Context or crm:Site/Place (excuse my not using the E #'s). And perhaps it doesn't need connection out to any other ontologies at all. Though some documentation of illustrative semantic overlap is nice in a "we want to be as friendly as possible" sort of way.

I am interested in using dc:isPartOf to relate resources to instances of lawd:ArchaeologicalContext. Its definition is is "A related resource in which the described resource is physically or logically included." [1]

I subsume the trope of archaeological discourse "Question: Where is that piece of pottery from? Answer: Context A." under the phrasing "logically included". If crmeh:Context being a crm:Place precludes that usage, then we really do need lawd:ArchaeologicalContext.[2]

lawd:foundAt probably does have a role in constructing these relationships as well. I hope it's OK to use that or dc:isPartOf as authors see best.

[1] http://dublincore.org/documents/dcmi-terms/#terms-isPartOf

[2] And here's a tangential discussion: It was written above that " A. If a context exists so that we can record it then Some event must have led to its existence". There are edge conditions that undermine such certainty. Surface contexts are really logical constructs into which material logically enters by a large number of processes, including subtraction of surrounding earth through water and wind action that leaves heavier material resting on a new surface, but not part of it. I can't tell you how much I want to avoid such scholastic hair splitting.

—
Reply to this email directly or view it on GitHub.