eCatalogue metadata

[idolum]

Based on the CWA 17028:2016-101 and the current ePO, the header of a catalogue can be modelled as follows:

Some of the required concepts/attributes have generic definitions, which fit the catalogue purpose, but are not specific enough. Some example:

• Catalogue identifier: A unique identifier of the instance of the concept (catalogue). (epo:ID)
• Catalogue name: A short text representing an instance of the class (catalogue). (epo:Name)
• Catalogue validity period: A time interval or a duration of a catalogue’s validity. (epo:Period)
• Contract reference: A reference to a contract the catalogue is based on. (epo:Contract)

In particular, the scope of a Catalogue identifier is open. Does the Catalogue identifier to be gloally unique or just in a context of a given contract or seller/catalogue provider?

The following new classes and attributes are required. Proposal for definitions:

• Catalogue version: The version identifier of the catalogue revision.
• Source catalogue identifier: Identifier of the existing, already received catalogue that this message should be acted upon, so that no discrepancies occur between the suppliers and customers information.
• Catalogue action code: Code specifying how a received catalogue should be used against existing catalogue lines sent in previous catalogues, so that no discrepancies occur between the sellers and buyers information. Describes how to treat existing items, not part of the received catalogue and those that are included (unchanged, changed or deleted). Default action is to fully replace the source catalogue.
• Catalogue issue date: The date on which the catalogue instance was issued.
• General payment conditions: Textual description of the general payment conditions that apply to all items in the catalogue.
• Process control: Information about the specification that apply 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.

[costezki]

We started implementing a set of attributes. This is what we covered so far and more will follow.

• Catalogue version -> epo:Document::epo:hasVersion
• Catalogue issue date -> epo:Document::epo:hasPublicationDate (see definition: Date of formal issuance of the document. Note: this attribute is equivalent to dct:issued.)

There are some of the attributes, however, we do not fully understand. Can you please clarify the following:

• Source catalogue identifier

• Catalogue action code

• General payment conditions - Is the Catalogue, in your understanding, linked directly to the Lot? If yes then the mapping would be Lot::isSubjectToContractTerm -> ContractTerm::hasPaymentArrangement. The definition of a payment arrangement is: Information about financial clauses that will govern some economic aspects of the execution of the contract. Additional Information: These clauses usually refer to financial and payment provisions.

[idolum]

@costezki Thank you! Regarding your questions:

• Source catalogue identifier: An example:

  • Catalogue Provider sends a catalogue with id "1"
  • Catalogue Provider sends an updated catalogue with id "2"
  • In this case the Source catalogue identifier would "1" to express the fact that "2" is a following version of "1"
  • Catalogue Provider sends an updated catalogue with id "3"
  • Source catalogue identifier would "2"
  • and so on

• Catalogue action code: A code that states how a new catalogue should be applied to an existing one, like

  • should it replace it completed
  • update it
  • extend it

Both terms are related to the various ways how catalogues are updated and versioned. I can explain it in more detail in one of the next meetings.

[muricna]

Decision 20.01.2022 For the change to a catalogue the CatalogueID stays the same but the version changes. ActionCode to become ChangeTypeCode at document level. This code informs the CatalogueReceiver how the catalogue has been changed. This information is about the data being changed and not the implementation. Veit: To report back if this is ok with his stakeholders.
To provide change type code.

[andreea-pasare]

@idolum, @muricna: How about a generic approach of annotating entities/resources with informations about actions or their changed state? In any case, we have to choose one or another.

[muricna]

@andreea-pasare With this solution, how would you deal with the temporal aspect?

[andreea-pasare]

The below model was proposed: Need to further discuss the name of the controlled vocabulary to be used (action-code vs. operation-code or activity-code)

[giorgialodi]

What does it mean that a "document announces a catalogue"? Sound strange and very old fashion :)

[idolum]

What does it mean that a "document announces a catalogue"? Sound strange and very old fashion :)

Maybe "realizes" or "instantiates" a catalogue?

[idolum]

@costezki Incoporated the draft into the WG5 data model. One question: What about the other catalogue attributes:

• Id of the Catalogue
• Name of the Catalogue
• General Payment Conditions for the Catalogue

The first two ones should not be an issue to added them. Regarding the general payment conditions you wrote above

Is the Catalogue, in your understanding, linked directly to the Lot? If yes then the mapping would be Lot::isSubjectToContractTerm -> ContractTerm::hasPaymentArrangement. The definition of a payment arrangement is: Information about financial clauses that will govern some economic aspects of the execution of the contract. Additional Information: These clauses usually refer to financial and payment provisions.

Then the catalogue should be linked to the Lot? The definition fits, but not sure about the "linking". I will check this.

[andreea-pasare]

@idolum:

• the ID of the catalogue is provided at the level of the document, using epo:hasID predicate.
• added the epo:hasName attribute on the epo:CatalogueDocument concept.
• renamed the epo-ecat:announcesCatalogue to epo-ecat:instantiatesCatalogue.

Waiting for feedback on General Payment Conditions for the Catalogue.

[idolum]

@costezki @andreea-pasare Thank you! Works for me!

Regarding the General Payment Conditions: If the catalogue falls under a framework agreement, this would work. But if don't such a link to a contract or framework agreement exist, this information cannot be provide. I think here of cases where a catalogue is submitted as part of tender.

[costezki]

We have added epo-ecat:hasSpecificPaymentArrangement attribute with the following description:

Information about payment conditions applied to all items in the catalogue.

Additional information: This property may need to be used together with the payment arrangements provided in the ContractTerms, where such terms exists.

WG approval 30/06/2022