Need a (generic) concept for archaeological context

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.

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

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:

identified by some Place Appellations, including coordinates, geometry and/or UIDs, names, etc
the location for some Physical Stuff (or not in the case of Cut features) and finds
have Spatial Relationships with other places (ie physical context relationships)
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:

Physical Properties (colour, texture, composition, etc)
sample it through part decomposition Events
the Deposition Event itself and any subsequent Modification Events, both natural and anthropogenic
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

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. :)

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

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/lawdi/LAWD/issues/3#issuecomment-18913395 .

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.

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.

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.

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:
rdf:type crm:E22_Man-Made_Object rdf:type crmeh:E53_Place dcterms:isPartOf 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.

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 https://github.com/sfsheath/LAWD/commit/6441f2957ce838c10dd7baca280f99b54524b8da#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.

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

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.

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.

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.

In CRMEH we modelled EHE0007 Context as a 'stratigraphic unit'

Our level of certainty comes from modelling real world field process & data where someone has defined a Context by excavating and recording it as a stratigraphic Context. Agreed this not always a simple black & white process in the field, but the CRMEH is a model of that stratigraphic method of investigation.

If you are not recording stratigraphic units then you may need another concept that may have some relationship to EHE0007 Context

Sent from my iPhone

On 7 Jun 2013, at 02: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.

Keith, Thanks for that clarity and for joining this conversation. Yes, the proposed lawd:ArchaeologicalContext can be the ontological type of resources that are not stratigraphic units. It is conceived independently of any fieldwork method, or even of fieldwork at all (though that's probably pushing the point too far).

And as result of your input, I'm mor confident about when I can use crmeh:EHE0007 and look forward to doing so.

Hugh, that's a fine use case. More broadly, an object remains logically part of a lawd:ArchaeologicalContext separately from what happens to it after collection from or assignment to a context (perhaps after reconstruction of an object broken up for movement through the art market, or as you say, on the basis of subsequent spatial/other grouping). Maintaining awareness of context is incredibly important to archaeological work (that's not news to any of us, of course) so a robust representation of that logical relationship is important. 'dc:isPartOf' and 'lawd:foundAt' are both good options.

And further mental exercises around possible relationships between objects and lawd:ArchaeologicalContext can bring out the utility of dc:isPartOf... It's not uncommon to find pieces of a single object within more than one lawd:ArchaeologicalContext. When excavation is involved, it's usual to logically assign the notionally restored "complete" object to the earliest context. By that relationship, all pieces of the object become "part of" that. That avoids double (or more) counting of objects. And this is particularly useful when a broken piece that was found in a later context carries information directy relevant to the earlier phase. As in, an inscription with a date but for which the dateable part was found on the surface or as spolia. It's well worth thinking of that as part of the earlier context.

Thanks for the discussion of some of the predicates to use also Seb. We do have some data with conjoining / refitting fragments, and that sounds good to model. I don't think I want to mint a new resource for a breaking event, and a simple dc:isPartOf predicate sounds pretty useful.

So, back to my original RDF outputs I posted at the begining of this thread, do they seem reasonable? Any suggestions for improvement? I'm happy to also reference lawd:ArchaeologicalContext for as a type.

"some rough context information (sometimes only identifiers!) and we lack my more detail about the contexts" "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."

Eric, happy to provide detail for Catalhoyuk faunal identifiers you may have. Our vocabulary is apparently distinctive. As you know, "context" is not in the Catal vocabulary; people here say our "Unit" is close. Units are in (of, from) "Spaces" which have phases/levels. There are "X-Finds" but not "Finds" (in the controlled vocabulary, anyway). I could go on...;^)

As I (principally me within our team of 2) launch into this effort, a first step will be some UML of what we have so as to discuss it more readily. Too early to say whether a mapping to CIDOC (EH or otherwise) is indicated.

p.s. greeting to others in this thread whose names and work I know but whom I haven't met

Morning :-) Thread has grown somewhat since I was last here, great stuff! A few comments on supposed complexity and the need for clarity here.

Firstly, the is no requirement or 'must' about any of the Events or intervening objects in a chain of relationships. But it is often very useful to record their presence in some way. Else if other data emerges, there is little or no scope for further linkage. I would argue for making any representations as explicit as possible else there is less advantage over more 'traditional' models such as those found in many relational databases where the relationships are implicit (see for example many of the csv downloads at the ADS which look a bit like this, lots of fieldnames such as 'found in' and 'date' ie properties attached directly to records in a very unsemantic way). What if we would like to do research regarding dating of sites using one dating scheme based on pottery sequences which has more recently been revised in light of new knowledge...? Knowing who made assertions and with what evidence would be very helpful cf having some 'date' value attached directly to a context. Without the longer, 'complex' chains of events, the resultant expression will be a bunch of properties associated in some way with a concept; this makes it very hard to eg use reasoning over such structures. Simplicity here may actually be counter-productive if it degrades semantic clarity, making any linked data potentially misleading at worst or at best limiting what can be done with it. Yes, does result in some extra linkages (hence this idea of complexity) but as in many cases we do not know anything about the intervening nodes in the graph, only the start and end points, such an approach is still descriptive, it is not 'requiring' these data to be present. If this is a problem, these longer paths can always be shortcutted; as long as the shortcut explicitly represents a particular path, it shoudl then be possible to traverse either way through the graph and any reasoner will be able to know that the long path is the same as the shortcut. So we get the best of both worlds.

Second, I would argue for clarity over what is meant by context. A context can generically be seen as some basic unit of information from archaeological fieldwork. Different from the more theoretical construct of knowing where something comes from. So the former can be a spit or other arbitrary definition or a stratigraphic unit in a single context recording style approach. If all is needed is to say an object 'came from' x (eg for historical data) then that does not need to be as specific as a CRM-EH context, the linked data just needs to express that some deposition event led to that object ending up in the Place where it was eventually found, be that a trench, a site or even a town/city/state/etc. Crucially though, a context in this sense is a Place as only through Place can we use spatial relationships effectively. The Object does indeed form part of the physical material found at such a Place, and the use here of physical material allows us to use partOf and similar relationships as needed. The case described by Seb of water action leaving some finds in a new situation is a good example of this, as this presumably applies to recorded archaeological data where we can infer some of this at point of excavation, rather than applying to much less detailed historical data where we would be unlikely to have some information: the material is deposited through some event, various events then affect the arrangement of the deposits and finds (note we may need to refer to these events if we wish to associate with linked data regarding hydrology, geology, etc) before the finds are ultimately excavated and assigned to a context (ie a spit, block, single context, etc) with the Place being defined at point of excavation by an archaeologist (in CRM-EH terms, that would produce the plan and GIS depiction and other records such as laser scans of of the bounds of the context).

The bit about lawd:foundAt could be seen as a shortcut for the longer chain of CRM events and classes that more precisely describes what happened. But beware of the conflation of concepts and the semantic ambiguity it potentially introduces if this meaning is not explicitly defined. When we are talking about context, we are either talking about a) the material of the deposit and any finds therein, which obviously does not apply to cut type features which have no material present or b) the spatial configuration of that material, ie the place in which it resides. In many cases we as archaeologists blur this semantic distinction which can lead to inconsistencies (such as the colour of a cut or the coordinates of an object).

Also, the idea of assigning a 'complete' object made up of parts from different contexts to the earliest context worries me a bit as it creates similar ambiguity; why not just assert which pieces cames from which contexts, then assert that a person (or person) assigns some dates to that collection of objects, which by inference provide a date which can be used to describe one or more of the contexts in some way. As Eric says, having a resource to describe the breaking of a pot (event) may not (or may be in some specific cases!) all that useful, but events to describe the production, deposition and eventual finding (through the excavation ie destruction of the original context) certainly are. The events to describe classification and ascription/assignment of dates/periods (of which there may be many, potentially conflicting) are similarly essential to allow for multi-vocality and expression of inference; having simple properties attached to objects here really doesn't adequately described what's going on through either the processes in the past or those being conducted now to investigate the past.

So what I'm saying is complexity isn't necessarily a) complex or b) bad or c) avoidable ;-) Explicit shortcuts where needed, semantic clarity and focus on concepts and also event based models make for really powerful constructs for archaeological research.

hth & atb, P.

and sorry for the double posting deletion thing if that caused any probs - Firefox went nuts mid edit... also sorry for delays in responding then a mega essay - bit too much on at present for keeping on top of individual posts then (as usual) lots to say. ttfn, p

lawdi / LAWD

Need a (generic) concept for archaeological context #3