search

OP-TED / ePO

The eProcurement Ontology provides the formal, semantic foundation for the creation and reuse of linked open data in the domain of public procurement in the EU.
European Union Public License 1.2
59 stars 18 forks source link

Glossary - eDelivery address #137

Closed muricna closed 3 years ago

muricna commented 6 years ago

Correction of definition:

Instead of Identifier of a eDelivery service associated with a given transaction.

Write Identifier of an eDelivery service associated with a given transaction.

jseguraf commented 5 years ago

This terms is not used anymore in the glossary.

JachymHercher commented 5 years ago

What element in the ePO corresponds to eForms' BT-509 (Organisation eDelivery Gateway)?

paulakeen commented 5 years ago

We have it as a Class named "Electronic Means of Communication", but the link from this to the Organisation it very indirect: whe sould consider linking Organization to this class namely to cover thoses cases when the Organization is not the Buyer nor the Economic Operator.

JachymHercher commented 5 years ago

"Electronic Means of Communication" sounds quite general. Shouldn't it be mentioned explicitly, so that it can be e.g. automatically distinguished whether something is an email address or an eDelivery address?

paulakeen commented 5 years ago

The class "Electronic Means of Communication" was defined as:

"Software solutions and electronic devices for communication and exchange of information between contracting authorities and economic operators.

Additional Information: These tools can be used for, at least, these five situations:

  1. The URL where to access the procurement documents.
  2. Access point for the submission of tender documents.
  3. Download URL, to indicate where to get a tool to communicate with the CA
  4. The URI of the system used by a Technique to allow EOs to exchange information with the CA (e.g. eAuction and DPS Systems)
  5. Exchange of information between CA and EO for questions and clarifications"

This is not equivalent to the class "Contact", which is used to specify the email, telephone, fax, etc. of an Organisation.

image

JachymHercher commented 5 years ago

Ahh, this :-). We discussed it one of the face to face meetings, right.

  1. General question on having a harmonized approach to predicates (linked to https://github.com/eprocurementontology/eprocurementontology/issues/208). In which cases is meaning carried by a predicate and in which cases by an attribute? For example, why are their multiple predicates between Submissions Terms and Electronic Means of Communication (EMC); instead of having an attribute in EMC, which would be called something like EMC Type and the codelist for which would be the five situations you give? Main aim: doing things consistently in all comparable situations.

Two concrete comments on the five situations:

  1. Could their phrasing be harmonized? E.g. each one starting with "The URI (typically an URL) of..."
  2. "5" is not clear. "Exchange of information" is not a "solution/device". Should it be "The URI (typically an URL) of a system for the exchange of information"? Doesn't this situation overlap with other situations?

(can you reopen the issue please, just to not lose track?)

paulakeen commented 5 years ago

We draw links (properties with predicates) between classes instead of adding attributes to classes always when the target of the link (it's called the "range", in Ontology Design) has its own attributes, like it is the case for the class "Electronic Means of Communication", which has:

  1. Data Properties, e.g. "Additional Information" and "URI", and/or
  2. Object Properties, e.g. "Procedure Terms", "Submission Terms", "Technique", "Communication Type".

About the harmonization: what if, in the Additional Information text we wrote:

  1. The URL where to access the procurement documents;
  2. The URL of the access point for the submission of tender documents;
  3. The URL from where to download a tool to communicate with the Buyer;
  4. The URL of the system used by a Technique to allow Economic Operators to exchange information with the Buyer (e.g. eAuction and DPS Systems)
  5. The URL of the device used to exchange information between Buyer and EO for questions and clarifications;

We do not think that 5 overlaps with any of the 1 to 4 points.

JachymHercher commented 5 years ago

The harmonization looks better. I'm just not sure all are URLs? For example, aren't eDelivery addresses URI, but not URLs? (I assume eDelivery could be used in, for example, situation 1 and 2).

Also, is there a difference between a tool, a system and a device? If there isn't, we should use just one. Also, if they are the same, then 5 would be just a specific case of 3, no? (A tool for questions and clarifications.)

paulakeen commented 5 years ago
  1. URLs are on type of URI. The other type is URN.

image

eDelivery systems are not accessed via URNs, normally. URNs are mostly reserved for namespaces (like in UBL, for instance. The following is the URN for the ESPD-Request: xmlns="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2", for an example).

May be you're confusing URI with the end-point, as end-points can be URLs but also a-semantic/no-syntax-specific identifiers, e.g. FA123412. But in the case of an Electronic Communication Means what should be expected is a URL. So the semantics of the eDelivery Address URL, as we have it now, would be correct.

  1. About how to use the terms tool, system or device: Althought they mean different things, we think that if for all 5 sentences we used "system" the result would be acceptable:

  2. The URL of the system from where to access the procurement documents;

  3. The URL of the system for the submission of tender documents;

  4. The URL of the system from where to download a tool to communicate with the Buyer;

  5. The URL of the system used by a Technique to allow Economic Operators to exchange information with the Buyer (e.g. eAuction and DPS Systems)

  6. Thee URL of the system used to exchange information between Buyer and EO for questions and clarifications;

This would imply renaming the property URI:URI, in the Class Electronic Means of Communication as "URL:URI", in our ePO diagram.

We'll close this issue but if you do not agree we can reopen it.

JachymHercher commented 5 years ago

Few comments on 4:

"The URL of the system for the submission of tender documents;"

a. Based on feedback received during the adoption procedure, we are expanding the definition of BT-18 (Submission URL) from "submission of tenders" to the, more precise, "submission of tenders, requests to participate or expressions of interest".

In eForms, we are essentially interested only in the first "moment of contact" between a buyer and seller, so we don't distinguish them. However, in the ePo, you probably want to model this via multiple predicates.

b. If you say, @paulakeen, that eDelivery address is an URL (https://github.com/eprocurementontology/eprocurementontology/issues/137#issuecomment-510475129), I'm happy to take your word for it. However, for the submission information discussed in the previous bullet, URL doesn't seem to be appropriate, because the submission address could be an email, which is not an URL (unless part of a "mailto:" scheme (1) (2), which is not likely in eProcurement). Concerning the practical side of things, submitting tenders by email is, in GROW opinion, technically a very bad idea, but legally probably acceptable. When submitting expressions of interest, it's probably a technically ok idea + legally acceptable.

The way we deal with this in eForms is to broaden the acceptable format also to "electronic addresses". In the ePO, you might want to distinguish cases when only an "URL" is acceptable and when it can be a broader type of "electronic address".

c. In the ePo, do you say "tender" or "tender documents"?