how to directly link epo:AgentInRole to org:Organization without Intermediate Instance?

[cristianvasquez]

We find epo:AgentInRole instances pointing to intermediary foaf:Agents, linked afterwards with owl:sameAs

Looking into the code, I see this is a Supporting instance for connection between Agent and Organization

But we don't see this as necessary, an org:Organization is a foaf:Agent and can be linked directly

We want the data to be simplified, and avoid owl:sameAs. instead of:

:someOrg a org:Organization .

:someReviewer a epo:Reviewer ;
    epo:playedBy :tpo-001

:tpo-001 a org:Organization ;
         owl:sameAs :someOrg .

We want epo:PlayedBy to point directly to the organization like this

:someOrg a org:Organization .

:someReviewer a epo:Reviewer ; 
    epo:playedBy :someOrg .

This approach simplifies the data structure.

I would want to know if there is a nuance I don't see at the moment for this choice, please comment.

The following is an extract of model v.4.0.0

[cristianvasquez]

In general: We want to minimize the amount of owl:sameAs triples used, for example:

• The public will download parts of our dataset and not necessarily count with a reasoner.

But in general, we don't want to add complexity. See a related paper: https://www.w3.org/2009/12/rdf-ws/papers/ws21

[schivmeister]

This is a special situation that is beyond the limits of the technology used in this project (RML), which we are treating with a special workaround, in this case owl:sameAs. It was a challenge made known during the initial CM evaluation and we were asked to come up with a suitable solution.

This is documented in the CM, if you look at the Mapping Notes (public) of the last of the secondary mappings for the field OPT-301-Lot-ReviewInfo (which you may find with the XPath Condition cac:AppealInformationParty/cac:PartyIdentification/cbc:ID/@schemeName='touchpoint' or exists(cac:AppealInformationParty/cac:PartyIdentification/cbc:ID[starts-with(text(), 'TPO-')])), as follows:

Here we link to the epo:ReviewProcedureInformationProvider instance the org:Organization of the epo:ContactPoint that has the specified Technical Identifier.

The organisation that will be linked via the epo:playedBy property will be identified by constructing a deterministic IRI to a placeholder entity, which is instantiated with the specific touchpoint Technical Identifier and linked to the organisation at that level with owl:sameAs, in the following manner:

Organization_TPO-X owl:sameAs epd:Organization_ORG-X AgentInRole_X epo:playedBy Organization_TPO-X

This is a special case beyond the conceptual mapping as RML does not facilitate complex n-degree lookups and filtering with relative paths (which we would need in this case to look up the Organization of the TouchPoint). It will not work if Company ever becomes repeatable.

What we mean here by complex n-degree lookups and filtering with relative paths are XPath lookups with predicates involving other relative XPaths, like the following:

/*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization[efac:TouchPoint/cac:PartyIdentification/cbc:ID[text()=/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AppealTerms/cac:AppealInformationParty/cac:PartyIdentification/cbc:ID/text()]]/efac:Company/cac:PartyIdentification/cbc:ID/text()

This is something one might imagine to look up the Organization of the TouchPoint, by doing all sorts of clever filtering. This, however, is not going to work, because the XPath processor can only understand a relative XPath in relation to the context node (whatever precedes or comes with the predicate).

As a workaround, we are able to create an intermediate entity when we come across the TouchPoint, which we can repurpose to link to the actual entity. That is what we do here, by instantiating an owl:sameAs relationship through a proxy entity, with information we have access to at that XPath.

This not only establishes a link that can be queried by the user, albeit with slight adjustments (typical in LOD querying where owl:sameAs instances are commonplace) but can be materialized with inference "out-of-band", at an earlier stage in the process, such that these relationships are normalized.

[cristianvasquez]

Thank you for the clear explanation.

I'm unsure of the most straightforward approach to solving this challenge. It will likely require some additional research.