Cumulative content of Working Group Meetings in 2022

What is the relationship between Lot and Procedure?

When do we talk about “procedure definitions” (like a plan description) and procedure execution recording/accounting (like a travel journal)?

What is DPS?

Which procedure types can be single-stage and multi-stage?

What is the difference between procedure stages and technique stages

no techniques are typically used

may lead to a Framework Agreement (FA)

no techniques are typically used

may lead to a Framework Agreement (FA)

no techniques are typically used

may lead to a Framework Agreement (FA)

One “part” for Northern hotels (parts of DPS but not Lot)

One “part” for Southern hotels (parts of DPS but not Lot)

One “part” for 4x4 SUVs

One “part” for sedans

There is a FA on Airline tickets (divided into three “things”)

What is T1, T2, T3?

Which procedure types can be single-stage and multi-stage?

What is the difference between procedure stages and technique stages?

Competitive dialogue - No

Competitive tendering - no

Innovative partnership - No

Neg-w-call - No

Neg-wo-call - No

Open - Yes

Restricted - Yes

Oth-mult - ?

Oth-single - ?

Phase - a distinct period or stage in a series of events or a process of change or development

Stage - a period or step in a process, activity, or development

Implement DPS/FA, procedures and sub-procedures

Re-examine the procedures and sub-procedures concepts, and their relations to Lot and Purpose

In DPS we have MiniCompetition AwardOutcome and NOT the LotAwardOutcome

The submission statistical information is at the Lot level, in the DPS/FA this information is at the MiniCompetition Level

Consider the split of the process information

CPV code pairing (re-model purpose)

Modifications modelling

Contract

Perhaps also touch on the Winner Role, which may be played by people and organizations, and sometimes even multiple ones, that don’t necessarily for an epo:OrganizationGroup.

OfferingParty maybe it should be an EconomicOperatorParty. But we have it covered in the definition.

Definitions on all three parties were revised and accepted.

Closing GitHub issue 388 ==== Signatory role removal

The signatory subrole is used in a Contract Notice to reference to the person which will sign the contract.

Subrole presence per notice is checked: https://docs.ted.europa.eu/eforms/1.3.2/schema/all-in-one.html#roleSubrolePresencePerNoticeTable

To be solved in a next meeting.

The GroupLeader class was removed since we already have epo:leadBy predicate between epo:OrganisationGroup and org:Organization.

But not all groups have legal name so the cardinality for epo:hasLegalName is changed to 0..1

Closing GitHub issue 386.

The lead buyer in Contract Notice can differ in the Contract Notice and Contract Award Notice corresponding to the mini-competition.

Presenting examples of an instance diagram for lead buyer.

In a joint procurement, all the Buyers are responsible and one of them might be the lead for awarding.

This doesn’t mean we have an OrganizationGroup.

Created a new concept epo:LeadBuyer as a subclass of epo:Buyer defined as: “A role of an agent who is a Buyer and takes the administrative lead of the procedure.
WG approval 22-11-2022”

We need to model DPS and Framework agreement in order to be able to map correctly.

Discussing an example of award.

Buyers can be specified for the Procedure for the pre-award phase and for the Contract (Purchase and Framework Agreement) for the post-award phase.

However, already in the pre-award it is possible to know who will be the buyers in the Contract (post-award).

A Buyer can be responsible either for the procedure or for the purchase contract.

Responsible is not the same as the leader.

A lead can sign the contract.

Joint procurement means that a procedure is the responsibility of more than one buyer. One of the responsible buyers has to be the lead or they can use a ProcurementServiceProvider to delegate the ancillary activities to, meaning there is no lead.

In a single stage procedure there is

In a multi stage procedure there is

Restricted Procedure types Disallowed

All the rest

Can publish a Prior Information Notice (PIN) if you want

Publish a Call for Competition (CN)

ESPD Request has to be published at the same time as CN (elsewhere)

Specifications can be published (elsewhere)

The request to participate is submitted by the Tenderer

Request to participate is evaluated

Tenders that pass the Exclusion grounds and Selection criteria are admitted to the DPS

The Buyer triggers the (RE-)opening of the competition, when needed,

Tenderers submit tenders

The Evaluation Committee (set-up by the Awarding-Buyer) evaluates and creates an evaluation report

Based on the evaluation report, an Award Decision (based on award criteria only) is created (by the Awarding-Buyer)

Selecting-Buyer requests to the (nearly) awarded Tenderers (wanna-be Winners) the evidence for selection criteria and exclusion grounds

Tenderers provide the evidence to the Selecting-Buyer

Selecting-Buyer evaluates the provided evidence and

All Tenderers are then told of the Award Decision (who was awarded and not + reasons on why and why not)

The contract is signed by the Awarding-Buyer and the Winners

Contract Award Notice (CAN) is published

In the case of DPS, the CAN is an Award Notice for the Contract, while in the case of normal (non-DPS) procedures the CAN is an Award Notice for Lots. [THIS IS DEBATABLE]

The opening of the competition under the DPS may be opened as a sub-procedure having its OWL Identified, yet linked to the “parent-DPS-procedure”. [THIS IS DEBATABLE]

In the DPS CAN, most likely, the contract number will be provided rather than a reference to the Lot number (in the Procedure).

DPS is open during the whole duration of the procedure. If a DPS is a setup to last for 2 years, then eC can register and apply under this DPS. DPS is a kind of FA where the procedure is open for a long period.

And when needed, a CA can launch a mini-competition, like the FA, whereas the EC that has the capability to submit a tender can submit its tender in that specific sub-competition.

In Italy, DPS is like a digital market internal to public institutions.

There is always a system that supports the DPS.

Is the procedure ID of the CAN the same as the one for CN?

The discussion on DPS should continue on Thursday, 24th Nov.

In a CAN for DPS it will be a Contract Number, not a Lot Number.

Usually define domain for properties that have a skos:Concept in range.

At the moment when generating the artefacts from UML model:

In model2owl transformation scripts should we add subclasses in the OWL core file or should these be in the restrictions?

In the uml2owl transformation document (https://github.com/OP-TED/model2owl/blob/master/doc/uml2owl-transformation/uml2owl-transformation.pdf) are presented all the transformation rules and in which layer they belong: core ontology, data shape (SHACL shape) and reasoning (restrictions) layer.

Below is a snippet from that document where we can see that the domain and range of associations are in the reasoning layer and the range is also in SHACL shapes layer.

But there seems to be a bug because the domain for properties derived from the "dependency connectors" are missing.

This bug should be fixed.

In the latest release version, ePO 3.0.1, a Result Notice belongs to the Notice module.

Only the epo:Notice class is now in the ePO core module.

This issue is transferred to the model2owl repository: https://github.com/OP-TED/model2owl/issues/114

There is a list of more specific comments regarding this issue.

In OCDS, the term Tender refers to something else than in ePO. We have a class from Procedure, which is the process, and we also have a term of the actual Tender as a noun. In OCDS, Tender refers to the entire process of tendering.

ePO 3.0.1 was used to get the following comments:

What is a Dynamic Purchasing System (DPS)? DPS is open during the whole duration of the procedure. If a DPS is a setup to last for 2 years, then eC can register and apply under this DPS. DPS is a kind of FA where the procedure is open for a long period.
And when needed, a CA can launch a mini-competition, like the FA, whereas the EC that has the capability to submit a tender can submit its tender in that specific sub-competition.
QUESTION: Is there a specific notice to set up a DPS? To be checked in D24?

Set up a meeting with who is the coordinator of the DPS subgroup.

What is an eAuction Technique? Contracting authority can be set up on a digital platform (exclusively). Very similar to eBay, but the offer is not increasing, but decreasing.
Sometimes they organise the auction in rounds.

This technique influences ONLY the submission stage.

Procedure types that can have eAuction:

Presenting the proposal that was implemented in a previous WGM (2022-10-04).

epo:ReviewObject might need a revision in the future. Decided to leave it as it is for the time being..

The award decision is between a tender and a contract so its position is good.

Revise definition from epo:ProcurementObject. The proposed definition “The whole or a division of goods, services or works to be procured” is more of a description of the concept and not a definition for it.

Answering the question “what are the attributes of the epo:ProcurementObject describing?” might give us a better definition.

In the epo:ProcurementObject there is nothing about the subject matter, but only in epo:ProcurementElement.

Discussed the case where we have a Direct Award Procedure which is followed by a contract signing.

The relation epo:hasOverallPurpose between epo:Procedure and epo:Purpose is deleted since it is no longer needed. Instead of this one, we will use epo:hasPurpose between epo:ProcurementObject and epo:Purpose.

Trying to decide whether a Lot is recurrent or only the procedure can be recurrent. For the moment it was decided to keep the attributes epo:isRecurrent and epo:hasRecurrenceDescription at the epo:ProcurementObject level.

Decided to move at-voc:contract-nature at the level of epo:ContractTerm level from epo:Purpose, as in the diagram below:

In eForms, the title and description of Lot and Procedure were in the Purpose Business Group, BG-2.

Also, recurrence and recurrence description are on the Purpose level, but they do not seem to belong there.

Should the contract nature be moved back?

The definitions for epo:Lot, epo:Procedure and epo:PlannedProcurementPart are about different nature of things so they need to be aligned to cover all three aspects:

https://github.com/OP-TED/ePO/issues/382

We should check whether the definition for our classes can have an OCDS reference added.

This issue should be discussed in a future WGM.

Can the despatcher be a different organisation than the seller?

In case of a service, the supplier of the service is the same as the despatcher.

We can not use the verb provide because it means supply.

Added definition:

Prefix is epo-ful.

It would be useful to model which “party” can play this role: buyer side, seller side or third party (acting on behalf of the seller or acting on behalf of the buyer).

Added definition:

Primary Roles:

Secondary Roles:

Primary:

Secondary:

Tertiary:

Discussing relations from epo-ord:Order:

These relations seem to be mixed.

Changed epo-ord:isDeliveredByDespatcher to epo-ord:isSentByDespatcher.

Changed epo-ord:isDeliveredToDeliveree to epo-ord:isDeliveredToConsignee.

Deliverer and carrier are synonyms, but the definitions that we provided in ePO for these two roles make them not synonyms.

epo-ord:Deliverer seems to be copied over from ePO 2.0.2 from Order Reification diagram.

Decided to merge Deliverer and Carrier into the same role.

Added definition for Carrier:

The prefix for this role is epo-ful: since the Carrier is not known in the ordering phase.

Some new GH issues (381, 382, 383) were discussed and need to be approached.

We need to try and react soon to these new issues.

We need a consistent way of mapping for section 5 whether we have the lot number or the contract number.

It was agreed that if the lot was not mentioned and there was only one lot, the lot was taken from section II.

How to approach the mappings if we have multiple lots, but without the lot numbers specified.

if there is no award there is no contract and therefore there is no instantiation

If the contract is awarded you can infer from the ontology that the contract exists.

I’m not sure therefore that we have to create a link that can be inferred.

The title could be for the lot if it is a non-award.

If awarded then the title will be the contract title.

If non-award then the title will be the lot title.

If we have a contract number, the RDF should have one as well.

If we have a lot number, the RDF should have one as well.

The excel maps correctly to the authority table economic-operator-size however the rdf shows a boolean see 348503-2021

The authority table is not listed in the resources

This needs to be documented in the mappings: although in xml we say it does not exist we need to explain that.

If the SME checkbox is checked we will "reuse" the Organization instance, and we will add epo:Business as an additional type.

If an Organization is not an SME does not mean it should be a large SME.

This issue can be closed as we agreed that the current representation is the best that we can do.

epo:refersToProcedure between epo:ResultNotice and epo:Procedure should be renamed since it’s too general.

Decided to change the source class for epo-not:refersToProcedure to make it a super-property from epo:ResultNotice to epo:Notice

Decided to have the prefix epo: for all relations going from epo:Notice.

Propose to add a new code in the at-voc:non-award-justification to cover this specific subsection: "No tenders or requests to participate were received or all were rejected".

Decided to use a different predicate, epo:hasAwardedValue that goes from epo:LotAwardOutcome to epo:MonetaryValue.

Added a new GH issue 161.

This needs to be changed.

The relation for regulation implementation should go from epo:Notice to at-voc:legal-basis.

If we include the regulations, we have to change the name “legal-basis” of the controlled vocabulary.

Changed epo:hasImplementationRegulation to epo:isBasedOnImplementationRegulation wit the following definition: “Indicates under which regulation a notice is created.
WG Acceptance 06/09/2022”

How to signal the difference between SF notices and eForms notices?

epo:Notice is part of ePO core.

Keeping all predicates that go from epo:Notice in the Notice module with the prefix epo-not.

The RDF for PPDS should contain all these predicates from the notice module.

Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.

The name Beneficiary gives more information.

Need → Initiation of Need fulfilment request → Provision of the need fulfilment means.

Changing the definition for epo-ord:Originator

When the Buyer creates a framework contract, it does not catch the real Originator.

Creating epo:Beneficiary with the following definition: “The role of an agent that consumes the goods and on whose behalf makes the purchase.

Adding as a requirement that the Buyer can also originate the order.

epo-ord:Originator should be moved to epo:Originator in the core module. To be discussed in the future meeting.

Separate the Notice systematisation (Notice module) from the Notice content (NoticeContent module)

In the Notice module we have instances created from the values of CV like in the example below:

We are constraining a class to a specific value of a property (Directive 23 in the image above)

There is a controlled list for all notice subtypes in eForms.

Restricting cardinalities for epo:hasNoticeType

The namespace prefix to be used should be epo-not:

The notice package from ePO core should be moved to the Notice module.

Check all attributes from epo:Document and decide what namespace should be used (epo:hasPublicationDate) and if they should be moved at the Notice level.

For the moment what is in the Document class should stay there and decide what can be moved in the future.

The package notice classes seem ok. Check and validate this package.

Creating pmc:at-voc:notice-type with a comment that this value is not part of the notice type controlled vocabulary yet.

If it is a D24, then it is a Prior Information Notice.

If it is a D25, then it is a Periodic Indicative Notice.

epo-cat:Certifier “A role of an agent that assesses the conformance of an Item to a set of requirements and grants the certificate as a proof of conformance.

epo-cat:CertificationLabel “Concept that stands for a set of norms, expectations, standards and policies.

epo-cat:ItemDescription “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.

epo-cat:ItemCertificate “”

epo-cat:hasPricePercentage “The factor relative to the price charged in addition.

epo-cat:hasCertificationNumber “The unique identifier of the certificate.

epo-cat:hasAttributeType “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.

epo-cat:hasFixedAmount “The predetermined monetary value charged in addition to the price.

Added epo-cat:hasReferenceURI attribute on the class epo-cat:CertificationLabel with the following definition: “A reference to where the label specification (norms, expectations, standards and policies) can be found.

epo:hasValidityPeriod “The property indicating when the ItemCertificate is in force.

epo-cat:issuedByCertifier “Relation indicating the Certifier responsible for providing the ItemCertificate.

epo-cat:attestedByLabel “Relation indicating the conformance subject represented by a CertificationLabel.

epo-cat:hasCertification “The property providing the proof of conformance.

epo-cat:hasBaseQuantity should be mandatory, so the cardinality was set to 1.

epo-cat: hasLeadTime changed to epo-cat:hasExpectedDeliveryTime with the following definition: _“The expected amount of time between the order and delivery of an item. _

There is a collection of requirements and there are several labels. Each of these associations provide certification schemes.

It is not good to look at that only from the label perspective.

There is a connection between the requirement set and the procurement criteria, and some of the labels can serve as a fulfilment as a procurement criteria.

CCCEV might be used in these circumstances. Might complement these labels.

Some subtypes of criteria can constitute a requirement for a particular label.

Directive 2014/24 mentions the following:

CCCEV should be revised and compared with the actual modelling of Environmental/Social labels.

Information Concept (CCCEV) seems to be a Label concept, based on the definition.

To the currently proposed model of Item labels we should add concepts from CCCEV as presented in the diagram below:

Certification is on the item.

The eCatalogue module developed is only for the exchange of information between catalogue providers and receivers.

Any additional requirement for other use cases should be added as a github issue.

The GitHub ticket can now be closed.

We made considerable changes between the beta release and the final release. This discussion will have an impact on the model.

Having a status seems reasonable, but if we commit to a status we also need to commit to a process, to the status of phases, etc.

Then why not add the epo:isTerminated boolean at the level of Competition notice or DPS?

Are Procurement Relaunch BT-634 and PIN Competition Termination BT-756 mutually exclusive? Probably not. We can not see that from the eForms mapping.

We should choose the minimum for this release.

Should we add a boolean at the procurement object level?

But in the future we need to refer to that procurement object.

Relaunch and recurrence information are about the rules of succession of procedure. The difference is that the recurrence information is announced at the beginning of the procedure, and the relaunch is in the end.

We don’t need to distinguish if it is a termination of the competition or DPS. We can infer this based on the previous notice reference. (see standard form F03, section IV.2)

We need to create a proper systematisation of techniques and classes.

Change StatusInformation to ProcurementProcessInformation

Add specific booleans for Competition and DPS

Create a link to a previous notice

This should be refactored in a future release.

This is a new specific ontology project coming from the University of Luxembourg.

Judgement cases will be used for this project.

The model can emerge from the already existing data. Some requirements that are important for the modelling come from the data.

This can be linked to eOrdering and eCatalogue ( see GH 355)

The request is to change the name of predicate epo:involvesBuyer to a more representative naming, like epo:isResponsabilityOfBuyer.

Also, the boolean attribute epo:isResponsibleForProcedure won’t help in the case of knowing which is the procedure that the specific buyer is responsible for.

Investigating how the ECLASS classification system describes items in a structured manner.

We should treat this as an additional custom description of an item.

The relation dct:requires replaces epo-ecat:hasRequirementItem.

The relation dct:hasPart replaces epo-ecat:hasComponent.

If we are sure that the concepts in the Core Vocab cover everything that we have in the ePO model we can use it directly.

If we need additional things typical to the domain we should extend the model.

EAP model

OWL core, OWL restrictions, SHACL shapes,

HTML generated by EA with diagrams

Glossary of terms (classes, properties, attributes)

Documentation explaining where the assets are and how to navigate them ==== Publication plan:

Revise in the WG narrower

Revise in the WG broader

Publish ==== Feedback

Need Tenderer and Submission view

DOLCE in Core vocabularies might be inconsistent

The objects over time view is valuable ==== User experience

Main objects over time

Unfold phases

Unpack what is relevant for each phase ( which objects/types? ) === Action points

Prepare and publish a glossary of classes and properties/attributes

Find a way to make the model easily presentable

Contextual information hierarchies/relation diagrams needs reworking

Add connections between roles and objects

Make sure that the roles have the context clearly indicated

Make a diagram for

Finally put all the classes in a flat list

Hide links to objects that are not part of the core

Model the Award Decision

Show how terms are associated to a Procedure, Lot, Contract

Presenting the FIBO model with agent-in-role pattern.

epo:Contract - epo:LotAwardDecision: rename the relation from epo:includesLotAwardOutcome into epo:isResultOfLotAwardDecision

epo:ContractTerm should be connected to the epo:Contract and not the epo:Lot (?)

Upper level ontology

Phase/contex organised notice content

Procurement role is directly involved in the procurement process;

Procurement subrole is secondary to the procurement process;

Related role is not involved in the procurement process.

There are multiple types of values:

The BTs should not be mentioned in the ePO definitions. Proposing to remove these in another place. Maybe as notes in the diagrams.

The value-type document should be saved somewhere in the github.

A tender is usually composed of documents, one of them being a financial offer. The document that is the financial offer contains the financial offer value.

Should we remove the source of the epo:hasFinancialOffer relation from epo:Tender to epo:FinancialOffer?

When modelling the ESPD response we will need the epo:FinancialOffer class.

The goal is to make sure that ePO covers at best the eForms and standard Forms.

The ESPD should be a module itself and eOffer as well.

Moving epo:TechnicalOffer and epo:FinancialOffer to eOffer module.

Moving epo:ESPDResponse and epo:ESPDRequest to ESPD module.

The StatisticalInformation classes should remain in the ePO module.

Replace TenderLot with Tender in all attributes: check epo:StatisticalInformation.

We need epo:StatisticalInformation at the Result Notice level and Lot level.

This information is published only in Result, DAP and Completion Notices.

LotGroup is defined in ProcedureTerm.

Tender is always submitted on a Lot (never on a LotGroup)

Tender may be subject to grouping by a LotGroup (at most one)

/!\ This means that we still need to think about how to represent the financial offer for a LotGroup in the context of a LotGroup Tender submission.

What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings.

Renamed the relationship in BT-27 from epo:hasInitialEstimatedValue to the already existing one in the model, epo:hasEstimatedValue. This is because the predicate is attached to the Lot/Procedure it implies that it is the initial value and no temporal reference is necessary.

Rename epo:hasTotalFrameworkValue to epo:hasTotalFrameworkAgreementValue

All relationships to epo:MonetaryValue that contains the word “Framework” should be renamed so that we add “Agreement” as well.

Rename relationship for eForms BT-156, Group Framework Value, to epo:hasFrameworkAgreementValue.

Presenting the example for the lot award decision situation:

Proposing to have a ProcedureObject as a superclass for Lot and LotGroup:

We need to connect the LotGroup with some Term classes in the ePO model.

Presenting a new example of Tender Submission:

Presenting an example of the awarding:

There were two isSubjectTo relations:

These two seem redundant after merging Tender with TenderLot.

The attributes from the SubmissionTerm class are mixed between Tender and Submission related attributes.

The guarantee and the electronic Signature are not at the Submission level.

We might need to create a TenderTerms class.

The bi-directional epo:attaches/epo:isAttachedIn relation between Tender and TenderDocument does not seem right as well.

A document may attach another document.

Removed any epo:attaches/epo:isAttachedIn relations from subclasses of epo:Document and create an unidirectional relation epo:attaches/epo:isAttachedTo at the epo:Document level.

Changing the definition for epo:Document with the following:

epo:RequestForClarification is on the EO side, but has nothing to do with the Tender (not a Tender Document).

The RequestForClarification, RequestForParticipation and ExpressionOfInterest are not generalisations of TenderDocument.

TenderDocument is no longer needed.

The association attaches / isAttachedTo should be replace by associatedWith.

The attaches predicate between Tender and ESPD response, Technical Offer and Financial Offer should be subproperties of associatedWith within any AP that will be created.

Investigate whether we need to create a TenderTerms class. (to distinguish between the action of submission and the content of submission)

When (In which situations) LotGroup is relevant and when it is not?

Does the LotGroup have its own award criteria or reuses those of the composing lots?

Is the LotGroup a subclass of Lot? They seem to share lots of attributes in common, and for this reason a common super-class would come in handy for good modelling. For example both of them may have FrameworkAgreementTerms, various criteria, estimatedValues, etc.

Then the same applies to TenderLotGroup, if such a class is necessary at all?

It was noted that the award criteria are not dependent upon a group of lots because the award criteria are applied before grouping the lots.

The Working Group had troubles understanding the Directive and the eForms concerning the Group of Lots value. It looks like the market could do synergies combining groups of lots but still the award criteria are set for the individual lots. An issue could be raised to eForms once the WG has clarified its findings especially concerning BG 330 Group award which seems to be in contradiction with recital 79 of Directive 2014/24/EU. It was also noted that the ontology covers scenarios that may not exist in all Member States.

LotGroup is merely a grouping of lots, without many attributes of its own, or …​

LotGroup is (almost) like a Lot, which overrides the properties of composing lots. For example, Lot "estimated values" will be overridden by the LotGroup values.

SelectionCriteria of a LotGroup can override (take precedence on the sum of the two) the SelectionCriteria of individual Lots or keep the SelectionCriteria of the individualLots.

LotGroup is a collection, it is not another type of Lot. It is a mechanism to group lots and differentiate selection criteria.

What is the connection between TenderLots to Lots and Groups? Is there a better way of calling the TenderLot?

TenderLot: Part of the tender that applies to the related lot. Additional Information: See also the definitions for Tender and Lot for a complete understanding. (apparently no longer needed)

Tender: Information submitted by the economic operator to specify its offer regarding one or more lots or the whole procedure, in response to the call for tender. (WG approval 07/11/2018)

List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing

What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings

epo:Location has been removed

epo:Address has been changed to locn:Address (with specific attributes and definitions)

All predicates from epo classes to epo:Location were moved to locn:Address and renamed to epo:hasAddress and epo:hasRegisteredAddress

Replaced epo:LocationCoordinate with dct:Location (with specific attributes and definitions)

Added locn:Geometry class (with specific attributes and definitions)

epo:hasLocationCoordinate should be deleted

locn:Address should be linked to locn:Geometry

Should we move epo:hasOpeningPlace to dct:Location? Double check if epo:OpeningTerm is a spatial object

It seems that epo:Location class was not removed; it should be removed

In eForms we use L3 NUTS code, but if we align to core location they provide locn:adminUnitL1 and locn:adminUnitL2

Should we consider INSPIRE instead of Core Location or ask Core Location to make changes in order to be more flexible

Should locn:adminUnitL1 link to at-voc:country instead of at-voc:nuts?

What can we do with locn:adminUnitL2? Keep it linked to at-voc:nuts.

We miss level 3 of at-voc:nuts. We could add a predicate for L3.

Ask Core Location for details on how we can go to L3 NUTS.

Change the model to the following diagram and test it with real data.