SEMICeu / CPSV-AP

Repository for the specifications falling under CPSV-AP
26 stars 9 forks source link

locn:address in the class foaf:Agent: the cardinality should be 0..* #107

Closed jimjyang closed 1 year ago

jimjyang commented 1 year ago

The cardinality for the property address (locn:address) in the class Agent (foaf:Agent) is now 0..1.

It should be 0..*, because an Agent may have several different addresses.

We are aware of that all properties in the class locn::Address have cardinality 0..*. However, when you for instance have postCode1 and postCode2, and postNameA and postNameB, how can you tell which one of the four combinations of postCode and postName is the correct one to use?

EmidioStani commented 1 year ago

Hello @jimjyang ,

enlarging a cardinality is not a big issue, I don't find a particular reason in the past. Do you have any practical example though ?

The properties of Address are optionals as they come from Core Location, so no constraint have been made within CPSV-AP.

jimjyang commented 1 year ago

@EmidioStani

Do you have any practical example though ?

The Norwegian Labour and Welfare Administration, the Norwegian Tax Administration etc., they all have their local offices in different cities, and several local offices in the same city, thus many different visiting addresses.

Even when you have one visiting address, you as a public organization usually have a poBox-address in addition, and the postCode and postName for your visiting address is usually not the same as the postCode and postName for your poBox-address.

The properties of Address are optionals as they come from Core Location, so no constraint have been made within CPSV-AP.

CPSV-AP does specify cardinalities for the properties in the class Address, which are all 0..*.

In our upcoming version of CPSV-AP-NO, we are considering to have

  1. 0..* for the property locn:address in the class Agent
  2. 0.. for all the xsd:langString-properties (free text, 0.. in order to support multilingual), and 0..1 for all the rdfs:Literal-properties ("coded value", max one value allowed/necessary).
EmidioStani commented 1 year ago

Thanks @jimjyang , it is clear, it make sense that for this issue the solution will be the enlarging the cardinality.

The cardinality 0...* are shown because we simply drag and drop the Address class from Core Location showing as consequence all possible properties.

williamverbeeck commented 1 year ago

During the webinar on the review of CPSV-AP on the 7th of November, it was agreed to relax the cardinality of relation Agent - Address (0..*).

EmidioStani commented 1 year ago

This issue can be closed, it is solved in the new release: https://semiceu.github.io/CPSV-AP/releases/3.1.0/