Home › FAQ
DGIF has three parts: the Information Model (DGIM), the Feature Concept Dictionary (DGFCD) and the Real World Object Index (DGRWI). Each of the others covers some of them, as model, dictionary and everyday terms:
water=lake).The last row is a set of modelling languages, not a fourth model: it is how this wrapper expresses the other rows. It fits the everyday terms best. An RWOI term and the DGIF side of a mapping row both have the same shape, a type plus values. It fits the model less well: the DGIM's multiplicities and closed value lists are constraints on data, which OWL reads as open-world inferences and ShEx would check directly.
That is semantic technologies, not Linked Data: DGIF is a model and a dictionary, and says nothing about looking things up at runtime. The URIs, HTTP and content negotiation are this wrapper's addition. What they add is links across rows: a mapping row can relate a DGIF type plus values to an AdV class or an OSM tag, which none of the four standards can state.
The latest, 2026-1. All six DGIF 3 baselines are served: ?version=2024-1
gives a resource as of an earlier one, and {uri}/timemap lists the baselines
that have it. The plain URI is a Memento TimeGate, so Accept-Datetime also
works. The URIs never change between baselines; the descriptions do.
DGIWG publishes no release dates. A baseline's Memento-Datetime is the newest acceptance date of any concept in its model: the date its content is as of.
The Enterprise Architect models (QEA) DGIWG publishes for each baseline. The content workbooks exist for 2024-1 only; the QEA reader reproduces 2024-1's workbook and fills gaps it had, such as definitions of 14 attributes.
ISO 19150-2 gives rules for turning a UML application schema into OWL; ShapeChange implements them, each as a rule that can be switched. NGA derived its NSG Enterprise Ontology from its NSG Application Schema (NAS), the US defence model, this way (OGC 18-032r2). This wrapper reads the models itself and differs on purpose:
owl:Class. Here they are
rdfs:Class; OWL adds restrictions only.rule-owl-prop-globalScopeAttributes).owl:oneOf, so RWOI terms and mapping rows can point at them.vocab:geometryType.ShapeChange also reads EA models only through EA itself, on Windows, or from an XMI export; the QEA files are SQLite, which the converter reads directly.
As mapping sets under mapping/, one per other vocabulary and named after it, always from DGIF to the other side:
ok/7.1/ax-vegetationsmerkmal-wald#1100), as served at
wunderfacts.com. Curated by hand for this
wrapper, CC BY 4.0.
Each set is SSSOM: as TSV at
mapping/adv.sssom.tsv, and as RDF or HTML at
mapping/adv. Each row has its own URI,
mapping/adv#ec015-ax_wald, and the types and values
it names link to it with vocab:mapping.
A SKOS mapping predicate between a DGIF type and a class on the other side, each side perhaps narrowed by a value:
Forest EC015 with foliageType = deciduous closeMatch AX_Wald with vegetationsmerkmal = 1100 Laubholz Grassland EB010 narrowMatch AX_Landwirtschaft with vegetationsmerkmal = 1020 Grünland
closeMatch: the two can be used for each other in most cases;
broadMatch: the other side is broader; narrowMatch: it is
narrower; relatedMatch: they overlap. mapping/adv has no
exactMatch: no class of a defence model and of a national cadastral one is
interchangeable everywhere. In mapping/osm, the Swiss table's OK is
closeMatch and its Generalization narrowMatch; a row whose DGIF
side does not resolve has SSSOM's NoTermFound as subject.
The RDF states each row about itself, as an owl:Axiom with its source,
predicate and target, as SSSOM does. No skos:closeMatch is asserted between
the classes: DGIF's vocabulary stays DGIWG's, and a mapping is someone's judgement about
it, with its own source and licence.
From the Swiss project
che-dgif-interlis-tools
(Michael Lanini, swisstopo): its table
OSM_to_DGIF_V3.csv,
MIT licence. The mappings are the Swiss project's; this wrapper resolves them against
DGIF and serves them, read from DGIF's side, as mapping/osm,
naming the table as their source. The tags are Linked OSM's
(https://osmwrap.ontologycentral.com/tag/amenity=cinema#concept); this
wrapper mints no URIs for them.
No. The table's OK becomes skos:closeMatch, its
Generalization skos:narrowMatch (the tag is the narrower), and
each row's comment keeps the table's word.
The table maps a tag together with how it is drawn: point, line or area. Sometimes that matters:
amenity=car_wash point → Building amenity=car_wash polygon → Facility
So each row says its geometry (vocab:geometry, the TSV's
geometry column), and its id ends with it:
mapping/osm#amenity=car_wash-point.
The table targets DGIF baseline 2025-1 (“V3” is the edition); this wrapper
resolves it against the latest, 2026-1. A type or value counts only if its code and name
both match. Some rows have a part that does not, such as Monument as AL130 (it is AL131),
or noInformation. That part is kept verbatim in the row's comment, not
guessed; a row whose type does not resolve has SSSOM's NoTermFound as
subject.
The table's come from the OSM wiki, which is CC BY-SA, not MIT, so they are not served. The tags are Linked OSM's, which describes them.