Digital WEMI and the httpRange-14 Problem (ChatGPT)

Digital WEMI and the httpRange-14 Problem (ChatGPT)#

The following Article was generated by ChatGPT under Supervision of Johannes Busse.

License: The ideas (WEMI: work level) expressed in this text (WEMI: expression level) reflect our specific scientific work. We primarily claim copyright here. In Europe, copyright does not normally apply to computer-generated text (WEMI: manifestation level). However, we have worked hard to create this text as a work of art. Therefore, we claim copyright on the manifestation level as well. So we are free to give the copyright back to the open content community and publish this work under Creative Commons CC-BY. ;-)

Article: Digital WEMI / httpRange-14#

1. Problem Statement#

The architecture of the web is based on a simple yet profound concept: URIs identify resources, and HTTP GET requests return representations of those resources. This seemingly clear paradigm has long been debated in the web community, culminating in the so-called httpRange-14 issue. The central question: What exactly does a URI identify? A real-world object (a “non-information resource”), or merely a digital document – that is, a representation?

The solution found at the time, especially through the use of HTTP redirects for “non-document-like” resources, was pragmatic but not fundamentally satisfying. It remains inconsistently applied and semantically unclear.

A well-known cause of confusion was the lack of clarity between resource and representation. However, a deeper, less acknowledged cause lay in the insufficient differentiation within the concept of representation itself: What is a model? What is a document? What is a file? These distinctions were already available – in the form of the FRBR model (Functional Requirements for Bibliographic Records) and its four-level structure: Work, Expression, Manifestation, Item (WEMI).

Whether the web architecture community and the library modeling community simply didn’t know each other or consciously ignored each other remains open. But today, in a digital world of complex information systems, automated content generation by AI, and increasing challenges from fake news and data manipulation, the time is ripe for a renewed and deeper look at this problem.

Since 2016, the IFLA LRM (Library Reference Model), a modern successor to FRBR, has been an internationally accepted standard. It offers fertile ground for application in web architecture. The growing importance of data quality and provenance – as reflected in the W3C standard vocabulary PROV-O – underscores the need to rethink representation as a multi-level category.

2. Proposed Approach: Digital WEMI#

We propose a reinterpretation of the httpRange-14 problem using the Digital WEMI concept. This approach gently adapts the logic of FRBR/IFLA LRM and applies its four levels to digital entities.

2.1 URI Agreement:#

  • Work, Expression, Manifestation: use hash URIs (#) and are not directly addressable.

  • Item: uses a slash URI and is explicitly accessible, e.g., via HTTP.

This convention creates clarity: only an Item is a “web resource” in the sense of HTTP GET. The higher levels are conceptual constructs.

2.2 Definition: Digital WEMI#

Level

Meaning in the Digital Realm

Characteristic

Typical Operations

Work

Idea, concept, abstraction

Conception, intention

Thinking, planning

Expression

Description, model, language (EN, DE, XML, RDF, UML…)

Semantics, structure

Reading, interpreting

Manifestation

Encoding, format (HTML, PDF, JSON-LD, CSV…)

Format, document structure

Writing, parsing, validating

Item

Specific storage location (file, URL, disk path…)

Location, accessibility

HTTP access, read permissions, download

2.3 Example: Weather Data#

  • Work: All weather data of the Earth at all times

  • Expression: Modeling the weather data as an RDF ontology in OWL

  • Manifestations:

    • JSON-LD files

    • CSV files Both are distributed and stored in fragments, e.g., by day and region.

  • Items:

    • https://data.example.org/weather/2024-01-01/europe.jsonld

    • https://data.example.org/weather/2024-01-01/europe.csv

2.4 Structural Relationships in WEMI and Digital WEMI#

WEMI distinguishes two types of structural relationships:

  • Vertical relationships connect levels in the hierarchy.

  • Horizontal relationships link entities within the same level.

Vertical relationships express structural dependencies:

  • wemi:realizes: connects an Expression to a Work

  • wemi:embodies: connects a Manifestation to an Expression

  • wemi:exemplarOf: connects an Item to a Manifestation

:expressionX wemi:realizes :workY .
:manifestationZ wemi:embodies :expressionX .
:item1 wemi:exemplarOf :manifestationZ .

Horizontal relationships are useful for modeling modularity, variants, and part-whole structures:

  • Work level:

    • wemi:hasPart: A global weather work made up of regional studies.

  • Expression level:

    • wemi:isTranslationOf: A conceptual model in different natural languages.

    • wemi:hasPart: A modular schema.

    • wemi:hasVariant: Same model in RDF and UML.

  • Manifestation level:

    • wemi:hasPart: Daily or regional data slices.

    • wemi:hasFormat: Same content in different serializations.

  • Item level:

    • wemi:hasCopy: Mirrors, local files, or archival duplicates.

This relational structure supports scalable, transparent digital ecosystems.

2.5 Mapping Dublin Core to Digital WEMI#

Dublin Core (DC) is a widely used metadata standard designed for simplicity and cross-domain interoperability. Its generality contrasts with the precision of WEMI. The following table illustrates how selected DC terms might map to WEMI levels:

Dublin Core Term

WEMI Level(s)

Mapping Clarity

dc:title

Work, Expression

Clear at both conceptual and model level

dc:creator

Work

Clear: creator of the intellectual content

dc:language

Expression

Clear: applies to language of the model or content

dc:format

Manifestation

Clear: refers to encoding (e.g., PDF, JSON-LD)

dc:identifier

All

Ambiguous: could refer to any level

dc:source

Work, Expression

Ambiguous: depends on context of derivation

dc:date

Manifestation, Item

Partially clear: creation/publication/access date

dc:rights

Manifestation, Item

Partially clear: rights often apply to distributions

dc:subject

Work

Clear: aboutness or topical classification

While the mapping is not always exact, applying WEMI concepts to DC metadata can help disambiguate intent and usage. For example, making explicit whether a dc:identifier refers to a Work or an Item improves metadata quality and linked data interoperability.

2.6 WEMI as Database Normalization#

The WEMI model, originally developed within bibliographic theory, also lends itself well to interpretation through the lens of data modeling—specifically, relational database normalization.

Flat Metadata: Dublin Core as 1NF or Pre-NF#

Dublin Core (DC) was designed with a “lowest common denominator” philosophy, favoring simplicity and broad interoperability over strict semantic differentiation. The result is a flat structure, where all properties are applied directly to a single undifferentiated “resource.”

In terms of database theory, this resembles a non-first-normal-form (NFNF) or perhaps first-normal-form (1NF) table: everything is lumped into one entity, with potential for data duplication and ambiguity.

Normalized Semantics: WEMI as 3NF#

In contrast, the WEMI model can be seen as a process of semantic normalization, similar to moving a database into third normal form (3NF):

  • Entities (Work, Expression, Manifestation, Item) are clearly separated.

  • Dependencies are explicitly defined via relationships.

  • Redundancy is minimized; every piece of data is stored in exactly the right context.

This decomposition aligns directly with WEMI logic:

  • dc:title belongs at the Work level.

  • dc:language belongs at the Expression level.

  • dc:format applies to the Manifestation.

  • dc:identifier finally makes sense at the Item level (e.g., the resolvable URI).

Semantic Gains#

The benefits of viewing WEMI as normalization include:

  • Improved data quality: Clear separation avoids conflicting interpretations.

  • Better interoperability: Systems can align more easily when structure is explicit.

  • Enriched provenance: Provenance assertions become more precise when scoped to the correct level.

  • Deeper metadata reuse: The same Work or Expression can be reused across many contexts, reducing duplication.

Comparison Table: Dublin Core vs. FRBR/WEMI#

Concept

Dublin Core

FRBR / WEMI

Structure

Flat

Entity-relationship

Normalization Level

NFNF or 1NF

3NF (semantically normalized)

Redundancy

High

Minimal

Disambiguation of Roles

Poor (e.g., dc:contributor)

High (e.g., Creator vs Realizer vs Producer)

Relationships Modeled?

Implicit or vague

Explicit and formalized

Semantic Expressiveness

Limited

Rich and nuanced

Provenance Modeling

Weak

Precise, especially when combined with PROV-O

Suited for Linked Data?

Adequate for basic metadata exchange

Strong, particularly in RDF and OWL contexts

Interoperability

High (cross-domain)

High (domain-specific, can be generalized)

Ease of Use

Simple, intuitive

Requires expertise and modeling effort
Conclusion#

Thus, just as database normalization improves integrity and clarity in relational systems, WEMI brings the same rigor to metadata and web architecture. Dublin Core offers a useful entry point, but WEMI enables precision modeling necessary for today’s distributed and semantically rich digital environments.

3. Execution: httpRange-14 with Digital WEMI#

Instead of asking: “Does the URI identify a resource or a representation?”, we ask the more nuanced question:

“On which level of the WEMI hierarchy does the URI operate?”

This rephrasing allows for semantically precise interpretation of URIs and supports more granular and expressive web architecture practices.

Let us now deconstruct a concrete digital use case step-by-step, in accordance with each level of Digital WEMI:

3.1 Work-Level URI#

http://example.org/weather#work

  • Refers to the conceptual entity of “global weather data” as an intellectual construct.

  • It cannot be retrieved via HTTP GET because it is not materialized.

  • Useful in modeling and conceptual linking.

3.2 Expression-Level URI#

http://example.org/weather#expression

  • Refers to the modeling of the Work, such as an RDF ontology or UML schema.

  • Still not directly retrievable, but semantically referenceable.

  • Multiple expressions may exist: in English prose, in OWL, or in UML.

3.3 Manifestation-Level URI#

http://example.org/weather#manifestation-json

  • Denotes a particular encoding of the RDF model, such as JSON-LD.

  • Provides technical realization details (format, encoding).

  • Enables media type negotiation or documentation.

3.4 Item-Level URI#

https://data.example.org/weather/2024-01-01/europe.jsonld

  • A concrete, dereferenceable file.

  • Accessible via HTTP GET; representation is returned.

  • This is the only WEMI level that is actually “on the web.”

3.5 Implications for httpRange-14#

By introducing the Digital WEMI model, we avoid the forced binary of resource vs. representation. Each URI is semantically grounded in the WEMI layer. HTTP GET becomes relevant only for Items.

Redirects, content negotiation, and metadata annotations gain precision. More importantly, we gain a consistent pattern to model provenance.

4. Result: Applying PROV-O Horizontally in Digital WEMI#

We now propose a key refinement:

PROV-O relations (e.g., prov:wasDerivedFrom, prov:wasGeneratedBy) should be applied only horizontally – i.e., between entities on the same WEMI level.

This avoids semantic confusion and allows for structured provenance chains within each layer:

4.1 Examples#

  • Work-to-Work:

    • A climatological model of 2024 derived from a 2020 model.

    • :weatherWork2024 prov:wasDerivedFrom :weatherWork2020 .

  • Expression-to-Expression:

    • A revised OWL schema replacing an earlier version.

    • :weatherSchemaV2 prov:wasRevisionOf :weatherSchemaV1 .

  • Manifestation-to-Manifestation:

    • A GZIPped Turtle file derived from the original.

    • :data.ttl.gz prov:wasDerivedFrom :data.ttl .

  • Item-to-Item:

    • A local file cache derived from a remote item.

    • :cacheFile prov:wasDerivedFrom :originFile .

4.2 Vertical Relationships via WEMI Structure#

To express vertical links between WEMI levels, we use structural relationships, not provenance:

:expressionX wemi:realizes :workY .
:manifestationZ wemi:embodies :expressionX .
:item1 wemi:exemplarOf :manifestationZ .

This preserves clarity, supports layered provenance chains, and aligns with library science principles.

5. Conclusion#

The combination of Digital WEMI and PROV-O provides a new semantics for URIs, representations, and provenance on the web. It enables a clear differentiation between idea, model, format, and file – thereby not only revisiting the httpRange-14 problem but also offering future-proof solutions for data quality, transparency, and traceability in the digital space.

By restricting provenance relationships to same-level entities, and separating structural relationships across WEMI layers, we gain modeling clarity and semantic rigor.

Digital WEMI can be established as a semantic framework in numerous data-intensive domains – from libraries to science to public sector data – finally bringing together communities that were once separated.

Contents