Working group meeting

Date: 18/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre

Agenda:

  • The old WGMeetings announcement

  • Continuing discussion regarding eCatalogue

Future agenda:

  • Continue discussing the attributes in the eCatalogue from GH Issue #284

    • Process control: Information about the specification that applies to the transaction.

    • Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.

    • Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.

    • Catalogue validity period: A time interval or a duration of a catalogue’s validity.

    • Contract reference: A reference to a contract the catalogue is based on.

    • Contract identifier: The identifier of the referenced contract.

    • Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.

    • Contract issue date: The date on which the contract comes into effect.

    • Contract subdivision: A relevant subdivision of the contract a catalogue refers to. === Discussion

Issue 284 - https://github.com/OP-TED/ePO/issues/284

  • Catalogue version - will map to the new added attribute epo:hasDocumentVersion.

We could adopt the FRBR model. We don’t need to incorporate the entire model.

A9NywpqTqGdLAAAAAElFTkSuQmCC

We should probably add a version to epo:Document. The argument for not adding is that if we have a new version it means it is a new Document.

The limitation of UML is that it does not allow us to import at runtime only without polluting the target model.

Work for this issue on a feature branch and then move it in the master branch.

  • *Catalogue Issue Date *maps to the already existing epo:hasPublicationDate in epo:Notice

epo:hasPublicationDate will be epo:hasIssuedDate in the new version.

Move epo:hasPublicationDate from epo:Notice to epo:Document.

Change epo:hasIssuedDate back to epo:hasPublicationDate in the new version.

Leave a comment to ask for more clarifications regarding this attribute.

  • Catalogue action code

  • Source catalogue identifier

  • General payment conditions - Ask if the catalogue is linked directly to Lot. If yes, the mapping will be epo:Lot epo:isSubjectToTerm epo:ContractTerm epo:hasPaymentArrangement.

Decisions:

  • Export eCatalogue model and import it into the master branch on GitHub to be easier to edit.

  • When we publish a new version of the UML model we should take out the eCatalogue module and reinclude it in the master branch after publishing.

  • Added epo:hasVersion attribute (epo:Text type [0 1])to epo:Document class with the following definition: “A number that identifies a specific state of a document.
    WG Approval 18/11/2021”

  • Move epo:hasPublicationDate from epo:Notice to epo:Document. Change epo:hasIssuedDate back to epo:hasPublicationDate in the new version.
    Change definition to the one from Dublin Core:

“ Date of formal issuance of the document.
Note: this attribute is equivalent to dct:issued.
(WG approval 18/11/2021)”