Linked Open Data for Ancient Metallurgy

Tackling Legacy Data practically

2026-07-09T00:00:00Z

So, I’ve got my ontologies sorted and my vocabularies in place. But none of that matters much if I don’t have real data to work with. That’s where this 2002 paper comes in.

Curious for the paper itself?

Chemical Composition and Lead Isotopy of Metal Objects from the "Royal" Tomb and Other Related Finds at Arslantepe, Eastern Anatolia

doi.org

Why This Paper?

Here’s the thing: I needed a real-world example that exposes the messy, complicated data issues we face in archaeometallurgy. And this paper by Hauptmann, Schmitt-Strecker, Begemann, and Palmieri is perfect.

Arslantepe—a 30-meter-high tell in Eastern Anatolia—has a "Royal Tomb" complex from the Early Bronze Age, packed with objects made from alloys that have been analyzed for both trace elements and lead isotopes. It’s a goldmine of data, but it’s also a minefield of modelling challenges.

The Six Challenges It Throws At Us

Working through this paper, I quickly realized it forces me to confront six critical modelling questions that keep coming up in legacy archaeometallurgical literature:

1. The Unknowns: Fragments Without Types

So, there are metal fragments in the assemblage that can’t be assigned a definitive typology. They’re just... fragments. No clear morphology, no easy classification. This is a fundamental issue in archaeology: how do you represent objects when you don’t have enough information to classify them? It’s not just about missing data—it’s about structural uncertainty in your knowledge model. If we can’t handle unknowns gracefully, we can’t model real-world archaeology.

2. The Double Analysis: Trace Elements + Lead Isotopes

The paper presents both trace element compositions and lead isotope ratios for the same artifacts. This isn’t just about storing two datasets—it’s about linking analytical methods that tell different stories. Trace elements speak to alloy composition and technological choices; lead isotopes reveal provenance and trade networks. The challenge? Modelling these as complementary but distinct lines of evidence that together tell a richer story about the object’s history.

3. The Chronology Puzzle: Multiple Complexes, Different Dates

Arslantepe’s Royal Tomb and Palace hoard belong to different archaeological complexes with distinct chronological attributions. This is where stratigraphic reality meets data modelling: sites don’t have single dates, they have complex temporal layers. The question is how to represent objects that belong to different phases, with different dating methods, and sometimes overlapping timeframes—without flattening the archaeological record into oversimplified categories.

4. The Fuzzy Data: ">0.1%", "<0.5%", "Not Detected"

The paper includes qualitative descriptors like ">0.1%", ">0.5%", or "not detected" rather than precise values. This is real analytical data—not sloppy work, but the nature of detection limits and measurement uncertainty. The modelling challenge is preserving this nuance while still making the data queryable. If we force everything into exact numbers, we lose the honesty of the original analysis. If we treat it as text, we lose the ability to reason computationally.

5. The Spearhead Problem: One Artifact, Two Samples

Two samples were taken from different parts of the same spearhead—one from the blade, one from the socket—yielding different results. This exposes a fundamental tension in archaeometallurgical data: the artifact (the conceptual whole) vs. the sample (the physical fragment analyzed). How do we maintain the relationship between them? How do we track that sample A and sample B come from the same object, but represent different materials or manufacturing processes? Get this wrong, and you lose the very connections that make the data meaningful.

6. The ID Chaos: Excavation, Lab, and Publication Systems

The artifacts carry three different identifier schemes from different contexts. This is the reality of legacy data integration: every institution, every project, every publication creates its own system. The challenge isn’t just technical—it’s conceptual. How do we reconcile that "Tomb 16/H/50" in the excavation log, "AR-23" in the lab notebook, and "Fig. 3, no. 12" in the paper all refer to the same physical object? Without solving this, we can’t link datasets, and without linking datasets, we can’t do meaningful cross-project research.

The Roadmap: From Paper to Queryable Data

So here’s my plan: over the next series of posts, I’ll tackle each challenge systematically.

Next Post: Modelling Unknowns: Fragments, Fuzzy Values, and Probabilistic Typing

Deep dive into CIDOC-CRM + Getty AAT for uncertain classifications
Implementing a lean apllication of CIDOC-CRM for the given use-case.

Following Post: The Analytical Workflow: Linking Trace Elements and Lead Isotopes with AFO

Step-by-step mapping of measurements (fuzzy or not) based on AFO

Later Post: Temporal Modelling: Arslantepe’s Stratigraphy in PeriodO

How I extended PeriodO with local phases
Experimenting with a hierarchy for chronological phases

Final Post: The Full Arslantepe Dataset: Querying the Triple Store

Live SPARQL endpoint demonstration
Example queries addressing all six challenges

As always, if you have thoughts, suggestions, or just want to nerd out about archaeometallurgical data modelling, write me an Email to info@lod-am.net or (if you have a GitHub account) in a comment below.

The Vocabularies - Finding the Right Words for My Data

2026-06-30T00:00:00Z

So, I’ve got my infrastructure sorted and my ontologies in place. But ontologies alone aren’t enough—I also needed controlled vocabularies to fill them with meaningful, consistent data. And since my research isn’t limited to the Mediterranean or the Near East, I needed vocabularies that could handle global coverage while still letting me add my own terms when needed.

Pleiades: For Sites and Places

For archaeological sites, Pleiades was the obvious choice. It’s a community-driven gazetteer with a strong foundation in Classical studies, but it’s actively expanding to cover the whole ancient world. The best part? I can add new sites myself—critical for my work outside the traditional Mediterranean focus.

It’s not the most formal option out there, but it’s open, linked, and practical. And since it’s already widely used in digital humanities, it integrates well with CIDOC CRM.

PeriodO: For Cultures and Periods

When it comes to cultures and chronological periods, I went with PeriodO. Why? Because it’s designed specifically for defining and linking time periods, and it supports scholarly assertions—meaning I can add my own period definitions when the existing ones don’t fit.

It’s not the most comprehensive vocabulary out there, but it’s flexible, global, and RDF-native. And unlike some other options, it doesn’t lock me into a specific region or timeframe.

Getty AAT: For Feature and Object Types

For feature and object types, I chose the Getty Art & Architecture Thesaurus (AAT). It’s the international standard, with over 30,000 terms covering everything from amphorae to weapons to architectural features. It’s comprehensive, multilingual, and—most importantly—widely adopted.

The trade-off? It’s not the easiest to extend. But for a global project like mine, the interoperability it offers far outweighs the occasional need to propose a new term or create a local extension.

Allotrope Framework: For Scientific Analytics

For the scientific side of things, I needed a vocabulary that could handle chemical compositions, dating methods, and material analyses. The Allotrope Framework Ontology (AFO) fit the bill perfectly. It’s purpose-built for analytical chemistry and materials science, and it’s already used by major organizations in the field.

It’s not specifically designed for archaeology, but that’s okay—it’s RDF-based, open-source, and it works. And since I’m using it alongside CIDOC CRM, I can link my archaeological objects directly to their scientific results.

FABIO: For Literature

Here’s where I made a slight pivot. In my last post, I mentioned FRBRoo for literature as an ontology. But after some more thought, I realized FRBRoo is overkill for my needs. I don’t plan to model literature entities in extreme depth—I just need something simple, like a Zenodo entry.

That’s why I switched to FABIO (FRBR Aligned Bibliographic Ontology). It’s lightweight, FRBR-aligned, and perfect for tracking publications with basic metadata like titles, authors, dates, and DOIs. It’s not as comprehensive as FRBRoo, but it’s a lot simpler—and that’s exactly what I need, including controlled vocabularies for the those entries.

The Big Picture

So here’s my vocabulary stack:

Pleiades for sites
PeriodO for cultures and periods
Getty AAT for feature and object types
Allotrope Framework for scientific analytics
FABIO for literature

Together, they give me a balance of global standards and flexibility. Where comprehensive vocabularies exist (like Getty AAT and Allotrope), I use them. Where I need the ability to add custom entries (like Pleiades and PeriodO), I’ve chosen vocabularies that let me do just that.

Curious for the itty-bitty details?

View LOD-AM/vocabularies on GitHub →

As always, if you have thoughts, suggestions, or just want to talk vocabularies, you know where to find me: info@lod-am.net or (if you have a GitHub-Account) in a comment below.

The Ontologies - Choosing the Right Tools for the Job

2026-06-29T00:00:00Z

So, I’ve got my homelab running, my website set up with Eleventy, and my triple store humming away with Fuseki. But none of that matters much if I don’t have a solid way to structure the data. That’s where the ontologies come in.

Curious for the itty-bitty details of the deployment of the triple store?

View LOD-AM/triplestore on GitHub →

Why Ontologies Matter

I needed a way to represent archaeological objects, scientific analytics, and literature in a way that’s both meaningful and interoperable. Since I’m not reinventing the wheel here, I looked for established standards that fit my needs—and my FOSS philosophy.

CIDOC CRM: The Foundation

For the archaeological core, CIDOC CRM was the obvious choice. It’s the international standard for cultural heritage data, widely adopted, and designed for exactly what I’m doing. Yes, it’s event-based, which can get complex. But here’s the thing: I don’t need to model every single event in the history of an artifact. I’m focusing on what matters—the objects themselves, their materials, their locations, and the scientific analyses performed on them. For everything else? I’ll add it later if I need it.

CIDOC CRM gives me interoperability with museums, archives, and other cultural heritage systems. And since it’s an ISO standard, I know it’s not going anywhere.

FABIO: For the Literature

Archaeology relies heavily on literature—often old, often without DOIs. I needed a way to reference papers, reports, and books in a structured way. FABIO, is allined with CIDOC CRM specifically for bibliographic data, so it's a very straight forward way to go.

FABIO lets me model works, expressions, manifestations, and items in a way that’s compatible with both libraries and museums. And crucially, it handles legacy literature without DOIs just fine. I can use local identifiers, author names, titles, dates—whatever I have. It’s not perfect, but it’s flexible enough for my needs.

Allotrope Framework: For the Science

The tricky part was the scientific analytics. I needed an ontology that could handle chemical compositions, dating methods, and material analyses. After some research, I landed on the Allotrope Framework Ontology (AFO).

AFO is designed for analytical chemistry and materials science. It lets me represent measurements, units, techniques, and results in a structured way. It’s not specifically built for archaeology, but that’s okay—it’s RDF-based, open-source, and it works. And since I’m using it alongside CIDOC CRM, I can link my archaeological objects directly to their scientific analyses.

But to be very sure (and to use my day-time job connections as good as possible), I am trying to get in touch with specialists from NFDI4Chem to evaluate this idea.

The Pragmatic Approach

Now, I’ll be honest: I’m not creating formal mappings between these ontologies (yet). For now, I’m using direct links—objects carry analysis results, literature refers to objects, and so on. It’s simple, it works, and it lets me focus on building the actual data.

Is this the most elegant solution? Probably not. But it’s pragmatic. As a one-person project, I need to move fast and stay flexible. If LOD-AM grows, I can always refine the model later.

Putting It All Together

So here’s the stack:

CIDOC CRM for the archaeological objects and their context
FRBRoo for the literature
Allotrope Framework for the scientific analytics

Together, they give me a solid foundation that’s interoperable with the wider cultural heritage and scientific communities. And since all three are FOSS-friendly, they fit perfectly with the rest of my setup.

Curious for the itty-bitty details?

View LOD-AM/ontologies on GitHub →

As always, if you have thoughts, suggestions, or just want to nerd out about ontologies, you know where to find me: info@lod-am.net or (if you have a GitHub-Account) in a comment below.

The Infrastructure - A Homelab for LOD-AM

2026-06-28T00:00:00Z

So, how does LOD-AM actually run? The answer might surprise you: under my desk. That’s right—this entire project lives on two old Fujitsu mini PCs that I picked up second-hand for next to nothing. Welcome to my homelab.

Keeping Costs (and Energy) Low

I’m a firm believer in doing more with less. The two mini PCs powering LOD-AM cost me almost nothing upfront, and their energy consumption is minimal. My entire homelab—LOD-AM included, plus a handful of other private services—uses about 0.6 to 0.75 kWh per day. That’s less than a single load of laundry. The only other expense? A Strato subscription for the domain and related services. That’s it. No cloud bills, no surprise fees. Just a couple of humble machines doing their job quietly, 24/7.

Free Software All the Way

I’m a strong supporter of the Free Software Movement, so it should come as no surprise that FOSS is at the heart of everything I do. My notebook runs Garuda Linux—a distro I can wholeheartedly recommend. I code in VS Codium, the open-source counterpart to VS Code. Even the AI assistant helping me build this? Mistral, open-source and running wherever I need it. And for virtualization, I rely on Proxmox, the rock-solid foundation of my homelab. One compromise I made from those principles, is the usage of GitHub. I have to admit, that was a decision out of convenience. I am used to GitHub and the integration with Mistral is so easy to use and I wanted to give you, the reader, the ability to leave comments and reactions here as well. I am using Giscus to do that and this little app is depended on GitHub-Discussions. But as always I am happy to learn. Maybe there are going to be better, more FOSS alternatives to switch to.

The Backbone: Two LXC Containers

Within Proxmox, two LXC containers form the backbone of LOD-AM. One hosts the website, built with Eleventy. The other is home to the triple store. Simple, lightweight, and efficient—exactly what I need.

Choosing a Triple Store: The Evaluation

Early on, I had to decide which triple store to use. I evaluated a few options:

GraphDB: Polished, user-friendly, and powerful. But the free version comes with hard limitations—on the number of repositories, the size of your data, and more. For a project like this, where I want to experiment without hitting artificial walls, that was a dealbreaker.
Apache Jena Fuseki: Fully open-source, no restrictions, and battle-tested. Yes, it’s a bit rougher around the edges. The interface isn’t as sleek, and you’ll need to roll up your sleeves for some configurations. But it’s real FOSS—no strings attached.
Blazegraph: Another solid open-source option, known for performance. But its future was uncertain, and I wanted something with stable, long-term support.

Why Fuseki Won

In the end, the choice was clear: Apache Jena Fuseki. I’d rather use a less polished but truly free and open solution than a more polished one that locks me into limitations. For LOD-AM, flexibility and freedom matter more than a pretty interface. Fuseki gives me both.

The Big Picture

So here’s the setup: old hardware, free software, and a DIY spirit. It’s not the most powerful infrastructure out there, but it’s mine. It’s cost-effective, energy-efficient, and—most importantly—it lets me focus on what matters: the data, the connections, and the research.

And if you’re reading this, you’re seeing the result. A project built on the belief that you don’t need expensive tools or corporate solutions to do meaningful work. Sometimes, all you need is a couple of old PCs, a commitment to free software, and the willingness to figure things out as you go.

As always, if you have questions, suggestions, or just want to geek out about homelabs and triple stores, drop me a line at info@lod-am.net or (if you have a GitHub-Account) in a comment below.

How I started

2026-06-27T00:00:00Z

Hi again, it’s me—Fabian. In the About-Post, I introduced LOD-AM as my personal sandbox for experimenting with Linked Open Data in archaeometallurgy. Today, I want to share how this sandbox actually became a website you can visit. The short answer: Eleventy, Bootstrap 5, and JavaScript—with a little help from an AI assistant.

Why Eleventy?

I needed a tool that would let me focus on content and data, not on fighting with complex build systems. Eleventy fit the bill perfectly. It’s a static site generator that’s fast, flexible, and—most importantly—unopinionated. No forced folder structures, no convoluted configuration. Just files in, HTML out. And since it’s JavaScript-based, I can use the same language to both build my site and interact with my triple store. That simplicity is exactly what I needed for a project where the data, not the framework, should be the star.

Bootstrap 5: Pragmatism Over Perfection

Here’s a confession: I’m not a web designer. I never claimed to be, and I have no intention of becoming one. My interest lies in the data, in the connections between entities, in making sense of archaeometallurgical information. So when it came to making this site look presentable, I turned to Bootstrap 5.

It’s a pragmatic choice. Bootstrap gives me responsive design, accessibility, and a clean look without requiring me to dive into the depths of CSS. Yes, it’s perhaps the easy way out. But my goal here isn’t to win design awards—it’s to create a functional, user-friendly space where I can share my work and display the entities from my triple store. And Bootstrap lets me do that efficiently.

Connecting the Dots: JavaScript and the Triple Store

The core of LOD-AM is the triple store, my RDF-based database where I’m collecting and connecting data on ancient metallurgy. But a database is only as useful as your ability to interact with it. That’s where JavaScript comes in.

With Eleventy’s JavaScript-friendly nature, I can query my triple store using SPARQL and fetch the data directly into my site. Whether at build time or client-side, I can pull in entities, display their relationships, and keep the content dynamic without sacrificing the simplicity of a static site. It’s not always seamless—there are plenty of moments debugging queries or troubleshooting data models—but it’s effective. And that’s what matters.

Curious for the code?

View LOD-AM/website on GitHub →

A Modern Workflow: Mistral and GitHub

Now, here’s something I won’t hide: this website is pretty much a vibe coding attempt. I’m using Mistral to help me write, debug, and refine the code. Am I a developer? Not really. But I don’t need to be. Mistral helps me bridge the gaps in my knowledge, allowing me to focus on what I do know—my data and my research.

Connecting Mistral with the GitHub repository has been a game-changer. It’s the most effective approach I’ve found to build this site without getting bogged down in the technical weeds. I can iterate quickly, test ideas, and fix issues without spending hours on Stack Overflow. The result? A workflow that lets me spend my time where it matters: working on the data, exploring the connections, and turning LOD-AM into something useful.

The Bigger Picture

So here we are: a website built with Eleventy, styled with Bootstrap, powered by JavaScript, and assisted by AI. It’s not the most sophisticated setup, nor is it the most polished. But it’s effective. It lets me share my work, display my data, and document my journey without the overhead of becoming a full-stack developer.

This project is still very much a work in progress. But with these tools and this approach, I’m able to focus on what really matters: the data, the connections, and the insights. And if you have thoughts, suggestions, or just want to share your own experiences, I’d love to hear from you at info@lod-am.net or (if you have a GitHub-Account) in a comment below.