[Data Model] Relationship between Company and Branch should be OneToMany

[grichka]

Hello, I noticed that according to the Ontology and logical data model, a Company can have only one Branch.

Of course, what is needed at the end is a specific Branch of a company that is involved in the freight transportation. However the data model should define that a Company has several Branches. A Company should have a set of Branch.

So I think that anywhere we have Company used in the model, this company should be changed to a companyBranch.
Or if we want to stick with this version of the model, we have to create (and duplicate) one company for each branch.

Thanks for your feedback.

[DrPhilippBillion]

Hello Grichka,

your point is correct, there must be an 1:n relationship between company and branch.

From the Excel I use, Cardinality for Branch in company is n, so I´d see it as 1:n. Can you explain why you think it´s currently 1:1?

It´s good to get feedback from you here ;-)

[emtscho]

Hello,
we are struggling with the same issue.
I agree that it needs to be changed at least to "CompanyBranch" and should be 1:N.
I even would suggest that carriers are a specific type of company. What do you think about the following approach:

Cheers

[grichka]

Hi @LHDrBillion , thanks for your reply :)

I am referring to the logical datamodel published in the version of November.
And if I refer to the Ontology I use (the latest version), we can see that a Company only has one Branch as it is specified below:

Ontology line 497:

###  https://onerecord.iata.org/Company
:Company rdf:type owl:Class ;
         rdfs:subClassOf [ rdf:type owl:Restriction ;
                           owl:onProperty company:airlineCode ;
                           owl:allValuesFrom xsd:string ;
                           ] ,
                           [ rdf:type owl:Restriction ;
                             owl:onProperty company:airlineCode  ;
                             owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
                           ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:airlinePrefix ;
                           owl:allValuesFrom xsd:integer ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:airlinePrefix  ;
                           owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:iataCargoAgentCode ;
                           owl:allValuesFrom xsd:integer ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:iataCargoAgentCode  ;
                           owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:companyName ;
                           owl:allValuesFrom xsd:string ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:companyName  ;
                           owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:branch ;
                           owl:allValuesFrom <https://onerecord.iata.org/Branch> ;
                         ] ,
                         [ rdf:type owl:Restriction ;
                           owl:onProperty company:branch ;
                           owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
                         ] ;

Max cardinality of Branch is "1"

[lambertciata]

Hi all,

@grichka
We did not have the time to properly update the ontology but it seems the maxCardinality 1 is a mistake in the ontology, that shall be fixed in the next version (hopefully soon!), thanks for finding this one out :)

Renaming to companyBranch makes sense, will bring the point in the data model taskforce.

@emtscho
I think we could have multiple subtypes of Company if some specific data properties make sense, such as carrier code. This topic can be discussed as well in the data model taskforce.

Cheers
Christophe

[lambertciata]

Hi,

Following are the changes that the data model taskforce agreed on:

• Branch will be renamed to ComanyBranch
• Relationship between Company and CompanyBranch will be changed to 1-to-many
• Carrier subtype of Company will be added

[mskopp]

Relationship between Company and CompanyBranch will be changed to 1-to-many

Currently, field BookingOption:shipper (and :consignee, :notifyParty and :freightForwarder and possibly some others) refers to a Company.
The address details (street, city etc) are stored on CompanyBranch (formerly called Branch).
With a 1:n relationship of Company:CompanyBranch, it is no longer determined which address is the relevant one.

So all links to Company needs to be checked and probably also changed to CompanyBranch. Others, e.g. maybe bookingOption:carrier, might remain with linking to a Company - but even with Airlines having multiple offices they have this one and only official main address - where to put that?

[lambertciata]

This issue shall be rediscussed with the data model taskforce for next release

[DrPhilippBillion]

• but even with Airlines having multiple offices they have this one and only official main address - where to put that?

Hey Martin, just to keep this discussion up-to-date: We were discussing a "headquater"-flag for one of the branches, which would solve the "bookingOption"-Problem, but still enable a 1:n relation with the company and companyBranch. "This is the way" ;-)

[mskopp]

We were discussing a "headquater"-flag for one of the branches
"This is the way"

I am sure there are multiple ways, e.g. one could also add an address in Branch similar and additional to the one on Company in the above diagram - this might solve some of the problems created by a 1:n Company:Branch relationship. A headquarter-flag which then must only be set on one of all the branches of a company produces new problems - e.g. rules about the uniqueness.

This is a non-trivial problem especially with a strong relationship to manage login/credentials/tokens for data access/visibility which from my point of view need to be grantable on Company level for sure and might be additionally grantable on Branch level.