To go back to 'uncertain information', could I share our experience with uncertainty in location data. Quite a few of our conrtibutors are engineers so we adopted an engineering approach, where uncertainy is coded in the site records as a numeric score alongside the locations. This is done at quite a simplistic level but this way it is clear for our visitors to understand and contribute back to
Accuracy Rating This refers to the accuracy of the location we give, either Lat/Long or OS map reference. 5 - co-ordinates taken by GPS or official recorded co-ordinates 4 - co-ordinates scaled from a detailed map 3 - co-ordinates scaled from a bad map 2 - co-ordinates given are of the nearest village 1 - co-ordinates given are of the nearest town In this way we can add sites that are really quite inaccurate, eg information we have gleaned from a news report or scaled from a not very good map. Once the site data is in our system, other contributors will come along and refine the data, so over time the accuracy converges. We show these accuracy scores on our pages and also on our KML and data downloads so that users are not misled by seemingly accurate long/lat locations. In a similar vein we we codify Access, Condition and 'Ambience' to a 5 digit score. This is of course an oversimplification and rather subjective but having this data allows us to do some interesting things by applying filters to our site data. For example we can filter to show sites in Morbihan (France) with disabled access: http://www.megalithic.co.uk/search.php?query=&country=6&category=0&county=556&sitetype=&days=0&condition=&ambience=&access=4 I am interested in how a similar approach could be applied to dating, to codify records with a large variation in accuracies into the same field structure - from very approximate dating such as 'Late Neolithic' - essentially a 'preset' time period, but which could be combined with increasingly more accurate dates from various radiocarbon or even Bayesean sources. (Each 'type' of date could be indicated with a different label) I would see this being stored in a linked table of several fields, including a base numeric date format to allow mathematical filtering, a separate numeric accuracy field, (eg assuming simplification to a bell curve standard deviation). A code to indicate the type of date and a field to store a source reference. Simplistically the numeric part could be eg 2700BC +/-500 years or 2875BC +/-25 years. Could Arches be set up to store fields like this? Thanks Andy On Thursday, March 27, 2014 9:41:26 AM UTC, [email protected] wrote: > > Another example could > be the questionable relationship of a findspot to a certain > archaeological period. To make it even more difficult, different authors > could have different thoughts on that. > > As far as we can see, the expression of such "uncertainty" is not > covered by Arches yet. Is there a concept for the integration of such > data in the future? We are currently thinking into potential solutions > but are struggeling to find adequate expressions for uncertain > information in CIDOC. > > thanks, Thomas > -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
