OrganisationType within Operator
Opened this issue · 10 comments
OrganisationType: operator on Operator seems unnecessary and redundant.
@nick-knowles This is from your (Deck Plan) bus example.
We noticed the same redundancy in the NeTEx French Profile: L'attribut OrganisationType d'un Organisation NeTEx devrait être obligatoire sous condition
This come from the inheritance of TransportOrganisation and since it is done with an XML Extension (which makes sense here) and not a Restriction skipping the OrganisationType is not possible. Furthermore, I remember some discussion about cases where an organisation has multiple roles, typically an Authority also being the Operator, and people were considering filling the Operator and setting the OrganisationType to authority ...
@Aurige TransportOrganisation is abstract. So which of its implementations actually is using OrganisationType correctly to differentitate its implementation? I think we are ending up with the same situation as JourneyPattern here. We have specific types, don't blindly follow Transmodel but only use the specific types in NeTEx (Authority, Operator, OnlineServiceOperator).
@JohanEntur have you noticed what is in the organisation type?
operator, railOperator, railFreightOperator, facilityOperator, alternativeModeOperator... from that point of view this type can also provide a speciality. But obviously it wouldn't make any sense to have an Operator being an retailConsortium. From my perspective this should be remodelled.
The full list is below, and OrganisationType is a list of enum... so that's really for the situation where a single Organisation is, at the same time, authority/operator/onlineProvider for example (for an Operator being only an operator without additional details, just skip that OrganisationType element, it's not mandatory)
Of course some combinations do not work, but limiting them is also not really possible
My opinion is that all organisations should be generic organisations. What they do and what role they assume is determined by the context in which it is referenced. If a ServiceJourney has an OperatorRef which points to it it becomes an Operator in that context. But in other contexts it can have any other role.
TypeOfOraganisation may be relevant to categorise them, but I dont think it should have anything to do with the roles it has in the data.
So in this particular case I think it should be
<organisations>
<Organisation id="ABC:Organisation:1" version="1">
<Name>That bus company</Name>
<TypeOfOrganisation>transitOperator<TypeOfOrganisation>
</Organisation>
</organisations>
And anything can reference ABC:Organisation:1
Regarding the list @Aurige posted, I think those enums should be roles, not type-ofs.
Maybe its an unpopular opinion - but its mine 😈
My opinion is that all organisations should be generic organisations. What they do and what role they assume is determined by the context in which it is referenced. If a ServiceJourney has an OperatorRef which points to it it becomes an Operator in that context. But in other contexts it can have any other role.
This a very Nordic-style of doing things. Like JourneyPattern, where the rest uses ServiceJourneyPattern. But in this case we prevented this from happening. Organisation is abstract and cannot be instantiated ;)
Maybe its an unpopular opinion - but its mine 😈
We wouldn't want any less of you ;-)
The current setup reflects the fact that ORGANISATION has evolved a lot over time and tried to keep backwards compatibility. Originally there were just two subclasses, AUthority and Operator others have been added. There is still a need to restrict certain references to organisations to specific types of organisations. Eg you have to be an OPERATOR to operate a SERVICE JOURNEY but this could be done with a role specific reference