Queries and the round trip

The figure is rebuilt from the graph by SPARQL alone. Nothing is hard-coded in the renderers — margins, row height, colour ramp and sort order are all read from the lado:Figure node — so a quantity missing from the export causes the rebuild to fail rather than to fall back on a constant.

The queries below are the ones the pipeline runs, reproduced from the code. They are also written out as standalone .rq files beside the query page, for use against an endpoint.

Figure constants

PREFIX lado: <http://archaeology.link/ontology#>
SELECT ?padYears ?extremeStubYears ?rowHeight ?svgWidth
       ?marginLeft ?marginRight ?marginTop ?marginBottom
       ?bandPadding ?colourRamp ?rowOrder
WHERE {
  ?fig a lado:Figure ;
       lado:padYears ?padYears ; lado:extremeStubYears ?extremeStubYears ;
       lado:rowHeight ?rowHeight ; lado:svgWidth ?svgWidth ;
       lado:marginLeft ?marginLeft ; lado:marginRight ?marginRight ;
       lado:marginTop ?marginTop ; lado:marginBottom ?marginBottom ;
       lado:bandPadding ?bandPadding ; lado:colourRamp ?colourRamp ;
       lado:rowOrder ?rowOrder .
}

One row of the figure

PREFIX lado: <http://archaeology.link/ontology#>
PREFIX crm:  <http://www.cidoc-crm.org/cidoc-crm/>
PREFIX time: <http://www.w3.org/2006/time#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?site ?findspot ?effStart ?effEnd
       ?qInterval ?qStart ?qEnd ?qRepetition
       ?uncStart ?uncEnd ?uncInterval
       ?minDatemin ?maxDatemax ?maxDatemin ?minDatemax
       ?nStamps ?nDies
       ?avgDatemin ?avgDatemax ?sigma ?k
WHERE {
  ?row  a lado:PlotRow ; lado:renders ?ts .
  ?fs   crm:P4_has_time-span ?ts ; rdfs:label ?findspot ;
        crm:P89_falls_within ?place .
  ?place rdfs:label ?site .

  ?ts time:hasBeginning/time:inTimePosition/time:numericPosition ?effStart .
  ?ts time:hasEnd/time:inTimePosition/time:numericPosition       ?effEnd .

  ?ts lado:minDatemin ?minDatemin ; lado:maxDatemax ?maxDatemax ;
      lado:maxDatemin ?maxDatemin ; lado:minDatemax ?minDatemax ;
      lado:nStamps ?nStamps ; lado:nDies ?nDies ;
      lado:avgDatemin ?avgDatemin ; lado:avgDatemax ?avgDatemax ;
      lado:sigmaYears ?sigma ; lado:kFactor ?k .

  OPTIONAL { ?ts  lado:qInterval        ?qInterval }
  OPTIONAL { ?ts  lado:qStart           ?qStart }
  OPTIONAL { ?ts  lado:qEnd             ?qEnd }
  OPTIONAL { ?ts  lado:qRepetition      ?qRepetition }
  OPTIONAL { ?row lado:uncStartYears    ?uncStart }
  OPTIONAL { ?row lado:uncEndYears      ?uncEnd }
  OPTIONAL { ?row lado:uncIntervalYears ?uncInterval }
}
ORDER BY ?avgDatemin

Era convention

PREFIX lado: <http://archaeology.link/ontology#>
SELECT ?era WHERE { ?m a lado:DatingModel ; lado:eraConvention ?era }

Model parameters

PREFIX lado: <http://archaeology.link/ontology#>
SELECT ?kMin ?kMax ?tau ?w
WHERE { ?m a lado:DatingModel ;
          lado:kMin ?kMin ; lado:kMax ?kMax ;
          lado:tau ?tau ; lado:volumeWeight ?w . }

Reaching the interval boundaries

The path from a dating to its numeric boundaries runs through the OWL-Time constructs rather than through a shortcut property:

?ts time:hasBeginning/time:inTimePosition/time:numericPosition ?effStart .
?ts time:hasEnd/time:inTimePosition/time:numericPosition       ?effEnd .

This is deliberate. A local lado:startYear would have been shorter, but it would be invisible to any consumer reasoning over OWL-Time. As a property path the standard route costs one line.

The round trip

After rendering, the pipeline compares the SPARQL results against the original CSV, field by field, matching rows on site and findspot rather than on position:

SPARQL variable CSV column
effStart eff_start
effEnd eff_end
qInterval q_interval
qStart q_start
qEnd q_end
qRepetition q_repetition
uncStart unc_start_years
uncEnd unc_end_years
uncInterval unc_interval_years
minDatemin min_datemin
maxDatemax max_datemax
maxDatemin max_datemin
minDatemax min_datemax
nStamps count_stamps
nDies n_dies
avgDatemin avg_datemin
avgDatemax avg_datemax
sigma sigma_eff
k k_eff

The current state is agreement to 0.00 × 10⁰ on every field.

This check is what makes the modelling claim testable. Two different figures — the classic and the modern rendering — are produced from the same graph, which means the information genuinely resides in the graph rather than in either renderer.

What the value table shows

The modern figure carries a table beside the time axis, covering what the web application shows only on hover, plus the whisker annotations:

Column
interval
n
sigma
unc start
q start
q int
unc end
q end

A hover popup is unavailable in print and in an SVG appendix. Placing the values in fixed columns makes them all visible at once, and removes the collision that occurred when the annotations were positioned against the whiskers themselves.