Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aligning ePO Metadata with CDM and Redefining epo:Document Class hierarchy #735

Open
6 tasks
costezki opened this issue Jan 21, 2025 · 0 comments
Open
6 tasks
Assignees
Labels
module: ePO core ePO core type: feature request something requested to be implemented in a future release type: use case Use Case (User story)

Comments

@costezki
Copy link
Collaborator

costezki commented Jan 21, 2025

Context and Problem Statement

The current structure of the ePO ontology models both the content of procurement notices and their metadata, but the boundary between these two is ambiguous. This has led to a modelling approach that is disconnected from the Common Data Model (CDM) maintained by the Cellar team. To enhance interoperability, semantic alignment, and conceptual clarity, a discussion is needed to revisit how metadata and content are separated in ePO. The overarching goal is to eliminate redundancy, leverage CDM for metadata modelling, and create robust links between ePO content and CDM's FRBR-structured metadata.

The ePO ontology currently models procurement notices in a manner that intertwines content description (the actual data within procurement notices) and metadata management (descriptive information about the notice itself). This approach results in duplication of metadata modelling already addressed by the Common Data Model (CDM), particularly its FRBR-structured metadata for works.

Image

In the CDM, metadata for any type of work (including procurement notices) is handled comprehensively. A new relation is being introduced in CDM (after a technical discussion with the Cellar team):
Manifestation realisedInGraph xsd:AnyUri, which connects manifestations to specific graph URIs. For procurement notices, this can be interpreted as: Manifestation realisedInGraph epo:Notice.

To align with this evolution, the ePO ontology must be updated to:

  1. Remove metadata modelling already covered by CDM and eliminate redundant constructs.
  2. Introduce appropriate links between ePO's Notice content and CDM's metadata structure, e.g., connecting epo:Notice content with cdm:Manifestation, cdm:Expression, or cdm:Work.

Objectives

  • Separate content modelling in ePO (focusing on the core data of procurement notices) from metadata management (delegated to CDM).
  • Align ePO with CDM by leveraging its metadata model, specifically cdm:ProcurementNotice, while ensuring all necessary metadata properties are preserved or added to CDM if absent.

Proposed Actions

  1. Refactor epo:Notice Class:

    • Transform epo:Notice into a content-focused class:
      • Retain properties that describe the intrinsic data content of procurement notices.
      • Remove properties related to metadata management, as these are within CDM's scope.
  2. Align Metadata with CDM:

    • Leverage the existing cdm:ProcurementNotice class in CDM to manage metadata for ePO notices.
    • Audit the cdm:ProcurementNotice class to confirm all required metadata fields are present.
    • If necessary, propose extensions to CDM for additional metadata fields not currently covered.
  3. Introduce Links Between ePO Content and CDM Metadata:

    • Establish clear relations between ePO content (epo:Notice) and CDM metadata entities:
      • For instance: epo:Notice describedBy cdm:Manifestation/cdm:Expression/cdm:Work.
  4. Eliminate Redundancy:

    • Remove overlapping properties or structures in epo:Document and epo:Notice that duplicate CDM’s metadata model.
    • Assess if epo:Document still serves a distinct purpose or should undergo further restructuring.
  5. Ensure Consistency with New CDM Relations:

    • Support the new CDM property: Manifestation realisedInGraph xsd:AnyUri.
    • Ensure alignment in how this property is used in relation to epo:Notice.

Tasks

  • Audit epo:Notice and epo:Document for metadata properties already modelled in CDM.
  • Create a mapping of existing ePO metadata properties to CDM’s FRBR-based model (Work, Expression, Manifestation).
  • Identify gaps in CDM’s cdm:ProcurementNotice and propose extensions if necessary.
  • Refactor epo:Notice to focus on content, removing metadata-related properties.
  • Define and implement relations between ePO content (epo:Notice) and CDM metadata entities.
  • Validate the updated model with use cases to ensure functionality and alignment.

Expected Outcomes

  • A leaner, more focused epo:Notice class representing only the content of procurement notices.
  • Metadata for ePO notices fully managed within the CDM framework, ensuring consistency and interoperability.
  • Clear links between ePO content and CDM metadata, leveraging cdm:Manifestation and related entities.
  • Reduced redundancy and improved maintainability across ePO and CDM ontologies.

Broader Implications

This update strengthens interoperability between ePO and CDM, ensuring alignment with broader semantic web standards. By leveraging the CDM model, ePO can focus on domain-specific content while benefiting from a robust and reusable metadata structure. This refactor also simplifies the ontology, making it more accessible and easier to maintain in the long term.

Discussion Points:

  • Are there any properties in epo:Notice that cannot be modelled in CDM?
  • What potential challenges could arise in linking ePO content to CDM metadata?
  • How can we best test and validate the updated model for real-world use cases?
@costezki costezki added type: feature request something requested to be implemented in a future release module: ePO core ePO core type: use case Use Case (User story) labels Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: ePO core ePO core type: feature request something requested to be implemented in a future release type: use case Use Case (User story)
Projects
None yet
Development

No branches or pull requests

2 participants