Is Software a Concept?

Submitted by Kostas Maistrelis on · last edited
🌱 Seedling

Is Software a Concept? — Summary of Conclusions

Notes from a discussion on SKOS modeling, ontology, and the type/token distinction, starting from the question of whether ex:git skos:related ex:opensource is a valid triple.

The starting point: SKOS formalities

  • skos:related (via skos:semanticRelation) has rdfs:domain and rdfs:range of skos:Concept.
  • Under open-world OWL semantics, using it with a non-concept produces no inconsistency — instead it produces an entailment: the subject is inferred to be a skos:Concept.
  • So the error, where there is one, is a modeling error, not a formal one. (SHACL changes this: a shape can make it a validation failure.)
  • Additionally, skos:related expresses associative (horizontal, non-hierarchical) relations between peers. Relations of instantiation or categorization (e.g., Mona Lisa → painting) are the wrong kind of relation for it entirely — that’s rdf:type / dcterms:type territory, inherited from the thesaurus RT relation (ISO 25964), which presupposes neither term is an instance or narrower term of the other.

Why “git is software, not a concept” is contestable

  1. Type/token: “Git” is not a physical object but an abstract type; the copies on disks are tokens. A type is already closer to an abstract entity than to a thing.
  2. SKOS is deliberately agnostic: skos:Concept means only “unit of thought” in a knowledge organization system. A thesaurus entry “Git (software)” is a perfectly legitimate skos:Concept. LCSH does this systematically.
  3. Classification is purpose-relative: Wikidata models Git thing-oriented (instance of: version control software); a CS thesaurus models it concept-oriented. Both are correct in their context.

Why the distinction still matters

  • There is a real difference between talking about git (subject indexing) and describing git (asserting properties: license, release date). A concept has no MIT license; the software does.
  • Collapsing both into one node yields use/mention confusion in RDF form.
  • foaf:focus exists precisely to bridge the two as separate nodes: the KOS concept and the real-world entity it is “about”.

The instance of alarm bell — and why it doesn’t settle things

  • Wikidata’s P31 (instance of) vs. P279 (subclass of) does encode particular-vs-class intent: Git is a software, not a category of software.
  • But instance-hood is level-relative, not absolute: classes can be instances of metaclasses, and Git-as-instance is still abstract — it has its own tokens (installations) that Wikidata simply doesn’t model.
  • Crucially, “concept” and “instance” are not opposites on the same axis. A thesaurus node about Git is a skos:Concept even while its referent is a Wikidata instance. Two projections, no contradiction.
  • Caveat: Wikidata’s P31 practice is notoriously inconsistent — evidence of design intent, not ontological authority.

The spatial-location objection

  • Objection raised: git does occupy physical space — bits on the release server’s storage.
  • Response: every copy is physical, but no copy is git. Counterfactual test: destroy the release server, git survives (restorable bit-for-bit from any clone). Tokens have locations; the type survives the destruction of any token.
  • Irony: git being a distributed VCS undermines the very idea of a privileged canonical copy — canonicity is social, not physical.
  • Contrast case: the Mona Lisa is a concrete particular all the way down. It has no tokens; copies of it are other objects. If it burns, it’s gone. This asymmetry is what makes the painting example clean and the git example murky.
  • Refined claim: not “git has no location” but “git has no unique, identity-fixing location.”
  • Steelman of the objection: a nominalist can hold that the type is nothing over and above its tokens plus the social practice maintaining them — in which case git “is located” the way a bird species inhabits the Mediterranean: distributedly. Defensible, but the location is then all clones worldwide, not the release server.

A proposed criterion and its leaks

Proposed: concepts live in minds; software lives in storage media and the practices around it.

  • Leak from the concept side: documented KOS concepts (a 50,000-entry thesaurus, dead taxonomies in LCSH) live in storage media and institutional practices — exactly where software was said to live. Popper’s World 3 (objective knowledge content, neither physical object nor mental state) fits them better than “in minds”.
  • Leak from the software side: software also lives in minds and practices — maintainers’ mental models, source code printed on paper (Lions’ Book), a memorized one-liner.

Refinement: the criterion tracks something real, but it’s not location — it’s the functional relation to the substrate. The cleaner differentia is executability: software is text with causal power when coupled to a machine; a concept is interpreted, never executed. Software is ontologically amphibious — sharing abstractness with concepts and causal efficacy with physical objects.

Meta-conclusions

  • “Software is and isn’t a concept” is not a contradiction but a recognition that the question “what is it?” presupposes a single context-free fact where there are (at least) two modelable entities: the artifact and the KOS concept, bridgeable via foaf:focus.
  • No single correct perspective exists — but perspectives are not all equal: some criteria survive counterexamples better than others, and that asymmetry is progress.
  • Epistemic relativity (how we classify) doesn’t cancel ontological reality (that there is something being classified) — but the thing’s existence doesn’t uniquely determine its classification either. (Critical Realist flavor.)
  • The complexity was not created by the discussion; it was revealed by it. After the untangling, design decisions (two nodes + foaf:focus) stop being conventions and become understood solutions.

🌱 All notes in the Digital Garden →