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
58 stars 18 forks source link

Predicates #208

Closed muricna closed 5 years ago

muricna commented 5 years ago

There needs to be a harmonization of the naming of the predicates, using bidirectional relations WG discussion 06/06/2019

JachymHercher commented 5 years ago

What is the benefit of bidirectional relations? Is it higher than the cost (more text, more complexity)?

(I didn't find an answer in the minutes of WG 06/06, which say that "It was indicated that the ontology as a rule did not have bidirectional relations so as not to complicate the model and it was agreed that there needed to be a harmonization of the naming of the predicates using bidirectional relations could be updated during harmonization. " Reading this summary, it seems to suggest that bidirectional could be updated, not that they should be updated.)

For a related discussion please see https://github.com/eprocurementontology/eprocurementontology/issues/4#issuecomment-302897342. This may be relevant also for any harmonization, e.g. the "we try to assign the property to the entity where it is more easily managed in instance data" approach proposed in https://github.com/eprocurementontology/eprocurementontology/issues/4#issuecomment-306454661.

(FYI @paulakeen, @jseguraf)

paulakeen commented 5 years ago

The rules in respect of this subjects should, in our opinion, the following (very simple rules):

  1. Depict the inverse property in the diagram only when really necessary to clarify the two directions of the relations between 2 classes. Otherwise avoid the inverse properties. One way of deciding wheter or not to depict the inverse is asking oneself if a "competency question" for both directions will be needed or not in the real world; e.g. How many contracts have been signed by one particular Buyer or CPB? and Which organisations have signed a Contract (plus the type, Buyer, Winner, Service Provider)? This is what we represent in the current ePO Diagram:

image

  1. About how to harmonize the terms in both arrows, the decision (not fully done yet, it's a low-priority work, but ongoing) was that when possible the predicates should somehow "mirror" one another; examples: if one side of the property reads "purchases" the other side should read "isPurchased", "Lot is specified in Procedure, Procedure specifies Lot(s)", etc. But this is not always possible, as in "Central Purchasing Body (or Service Provider) acts on behalf of"....the inverse is not straightforward. The normalization of the predicates referred to in this issue is about this phenomenon. When dealing with it, very soon we'll apply these two rules (and will take into account comments by @makxdekkers to simplify the predicates.

The response to @JachymHercher 's comment is the following:

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".

WG Approval 09/07/2019

muricna commented 5 years ago

Until fully implemented please leave open