Home » railML newsgroups » railml.common » roles
| roles [message #1102] |
Thu, 15 March 2012 13:22  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
In RailML, we have different attributes and elements for roles:
- "owner" in InfraAttrGroups and "ownerChanges", both used for tracks
- "manufacturer" and "operator" (element) for vehicles,
- "operator" (attribute) for trainParts
I think it would be wise to introduce a dedicated type for "roles" and
provide slots for id references at the appropriate locations. Maybe a
string enumeration type would work for the names of the different roles.
Even better, we could provide container elements as used in the vehicle
classification everywhere.
Regards
Andreas Tanner.
|
|
|
|
| Re: roles [message #1103 is a reply to message #1102] |
Thu, 15 March 2012 14:46  |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Andreas Tanner <ata(at)ivude> writes:
Hi Andreas,
> In RailML, we have different attributes and elements for roles:
> - "owner" in InfraAttrGroups and "ownerChanges", both used for tracks
> - "manufacturer" and "operator" (element) for vehicles,
> - "operator" (attribute) for trainParts
Yes, it's done in different ways across the subschemas.
> I think it would be wise to introduce a dedicated type for "roles" and
> provide slots for id references at the appropriate locations. Maybe a
> string enumeration type would work for the names of the different
> roles. Even better, we could provide container elements as used in the
> vehicle classification everywhere.
I try to figure out, what you want to get. The following XML snippets
try to show your wishes. Please correct me, if I'm wrong with my
implementation.
<infrastructure>
...
<infraAttributes>
<owner id="im_12345" name="Die Bahninfrastruktur"
role="infrastructureManager"
uicNumber="foo"/>
..
<track>
...
<ownerChange id="im_54321" name="Schweizerische Bahn"
role="infrastructureManager"
uicNumber="bar"/>
...
</infrastructure>
<rollingstock>
...
<vehicle>
<classification>
<manufacturer id="m_123" name="Bombardjee"
role="manufacturer"
serial_number="123.456.78"/>
<operator id="o_123" name="EmErCeE-DispoLok"
role="rollingstockOperator"
class="baz"
startDate="2012-01-01" endDate="2012-12-31"/>
...
</rollingstock>
<timetable>
...
<trainPart>
<operator id="op_123" name="Der Bahnbetreiber"
role="railwayUntertaking"/>
...
</timetable>
My first step is some clarification, afterwards I would comment it.
Thanks for your idea and kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1104 is a reply to message #1103] |
Fri, 16 March 2012 11:48 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Hi,
what about something like this:
Fragment from schema:
<xs:simpleType name="RoleName">
<xs:restriction base="xs:string">
<xs:enumeration value="InfrastructureManager"/>
<xs:enumeration value="Operator"/>
<xs:enumeration value="Contractor"/>
<xs:enumeration value="Manufacturer"/>
</xs:restriction>
</xs:simpleType>
Usage in document:
<role id="001" roleName="InfrastructureManager" owner="BrokenTracks"
uic="foo"/>
<role id="002" roleName="Operator" owner="SpeedyRailways" uic="xxx"/>
<role id="003" roleName="Contractor" owner="AtYourServiceCorp" uic="yyy"/>
<role id="004" roleName="Manufacturer" owner="SteamCoach" />
....
<infraStructure>
....
<infraAttributes><roleref ref = "001" startdate="..." ... </infraAttributes>
....
</infraStructure>
<timetable>
....
<trainPart><roleRefs>002 003</roleRefs><trainPart>
....
</timetable>
<rollingStock>
<vehicle>
<classification>
<roleRefs>
<roleRef ref="004" startDate="..." .../>
...
</roleRefs>
</classification>
....
Regards,
Andreas Tanner.
Am 15.03.2012 14:46, schrieb Susanne Wunsch:
> Andreas Tanner<ata(at)ivude> writes:
>
> Hi Andreas,
>
>> In RailML, we have different attributes and elements for roles:
>> - "owner" in InfraAttrGroups and "ownerChanges", both used for tracks
>> - "manufacturer" and "operator" (element) for vehicles,
>> - "operator" (attribute) for trainParts
>
> Yes, it's done in different ways across the subschemas.
>
>> I think it would be wise to introduce a dedicated type for "roles" and
>> provide slots for id references at the appropriate locations. Maybe a
>> string enumeration type would work for the names of the different
>> roles. Even better, we could provide container elements as used in the
>> vehicle classification everywhere.
>
> I try to figure out, what you want to get. The following XML snippets
> try to show your wishes. Please correct me, if I'm wrong with my
> implementation.
>
> <infrastructure>
> ...
> <infraAttributes>
> <owner id="im_12345" name="Die Bahninfrastruktur"
> role="infrastructureManager"
> uicNumber="foo"/>
> ..
> <track>
> ...
> <ownerChange id="im_54321" name="Schweizerische Bahn"
> role="infrastructureManager"
> uicNumber="bar"/>
> ...
> </infrastructure>
> <rollingstock>
> ...
> <vehicle>
> <classification>
> <manufacturer id="m_123" name="Bombardjee"
> role="manufacturer"
> serial_number="123.456.78"/>
> <operator id="o_123" name="EmErCeE-DispoLok"
> role="rollingstockOperator"
> class="baz"
> startDate="2012-01-01" endDate="2012-12-31"/>
> ...
> </rollingstock>
> <timetable>
> ...
> <trainPart>
> <operator id="op_123" name="Der Bahnbetreiber"
> role="railwayUntertaking"/>
> ...
> </timetable>
>
> My first step is some clarification, afterwards I would comment it.
>
> Thanks for your idea and kind regards...
> Susanne
>
|
|
|
|
| Re: roles [message #1105 is a reply to message #1104] |
Fri, 16 March 2012 15:47 |
Joerg von Lingen
Messages: 149
Registered: May 2011
|
Senior Member |
|
|
Hi,
basically I don't see a problem to have one type <role> for this. However, we
have to bear in mind that this type must have all the particular attributes
required for each role, e.g. startDate+endDate for "Operator" but not
necessarily for "Manufacturer".
--
Best regards,
Joerg v. Lingen
Rollingstock Coordinator
On 16.03.2012 11:48, Andreas Tanner wrote:
> Hi,
>
> what about something like this:
>
> Fragment from schema:
>
> <xs:simpleType name="RoleName">
> <xs:restriction base="xs:string">
> <xs:enumeration value="InfrastructureManager"/>
> <xs:enumeration value="Operator"/>
> <xs:enumeration value="Contractor"/>
> <xs:enumeration value="Manufacturer"/>
> </xs:restriction>
> </xs:simpleType>
>
> Usage in document:
>
> <role id="001" roleName="InfrastructureManager" owner="BrokenTracks" uic="foo"/>
> <role id="002" roleName="Operator" owner="SpeedyRailways" uic="xxx"/>
> <role id="003" roleName="Contractor" owner="AtYourServiceCorp" uic="yyy"/>
> <role id="004" roleName="Manufacturer" owner="SteamCoach" />
> ...
>
> <infraStructure>
> ...
> <infraAttributes><roleref ref = "001" startdate="..." ... </infraAttributes>
> ...
> </infraStructure>
>
> <timetable>
> ...
> <trainPart><roleRefs>002 003</roleRefs><trainPart>
> ...
> </timetable>
>
> <rollingStock>
> <vehicle>
> <classification>
> <roleRefs>
> <roleRef ref="004" startDate="..." .../>
> ..
> </roleRefs>
> </classification>
> ...
>
>
> Regards,
> Andreas Tanner.
>
>
>
> Am 15.03.2012 14:46, schrieb Susanne Wunsch:
>> Andreas Tanner<ata(at)ivude> writes:
>>
>> Hi Andreas,
>>
>>> In RailML, we have different attributes and elements for roles:
>>> - "owner" in InfraAttrGroups and "ownerChanges", both used for tracks
>>> - "manufacturer" and "operator" (element) for vehicles,
>>> - "operator" (attribute) for trainParts
>>
>> Yes, it's done in different ways across the subschemas.
>>
>>> I think it would be wise to introduce a dedicated type for "roles" and
>>> provide slots for id references at the appropriate locations. Maybe a
>>> string enumeration type would work for the names of the different
>>> roles. Even better, we could provide container elements as used in the
>>> vehicle classification everywhere.
>>
>> I try to figure out, what you want to get. The following XML snippets
>> try to show your wishes. Please correct me, if I'm wrong with my
>> implementation.
>>
>> <infrastructure>
>> ...
>> <infraAttributes>
>> <owner id="im_12345" name="Die Bahninfrastruktur"
>> role="infrastructureManager"
>> uicNumber="foo"/>
>> ..
>> <track>
>> ...
>> <ownerChange id="im_54321" name="Schweizerische Bahn"
>> role="infrastructureManager"
>> uicNumber="bar"/>
>> ...
>> </infrastructure>
>> <rollingstock>
>> ...
>> <vehicle>
>> <classification>
>> <manufacturer id="m_123" name="Bombardjee"
>> role="manufacturer"
>> serial_number="123.456.78"/>
>> <operator id="o_123" name="EmErCeE-DispoLok"
>> role="rollingstockOperator"
>> class="baz"
>> startDate="2012-01-01" endDate="2012-12-31"/>
>> ...
>> </rollingstock>
>> <timetable>
>> ...
>> <trainPart>
>> <operator id="op_123" name="Der Bahnbetreiber"
>> role="railwayUntertaking"/>
>> ...
>> </timetable>
>>
>> My first step is some clarification, afterwards I would comment it.
>>
>> Thanks for your idea and kind regards...
>> Susanne
>>
>
|
|
|
|
| Re: roles [message #1106 is a reply to message #1105] |
Fri, 16 March 2012 23:37 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Joerg von Lingen <coord(at)rollingstockrailmlorg> writes:
> basically I don't see a problem to have one type <role> for this.
> However, we have to bear in mind that this type must have all the
> particular attributes required for each role, e.g. startDate+endDate for
> "Operator" but not necessarily for "Manufacturer".
Thank you Jörg, for pointing this out.
This more general approach (a new 'role' element) leads us to loose the
control of the context-specific content (specific attributes).
We would have to ensure that the 'infrastructureManager' is only used
inside the IS-sub-schema and so on. That's not possible with XML Schema
1.0 syntax. We would need additional constraints, e.g. Schematron rules.
My first thought was to enrich the roles by contact data. But maybe it's
too much detail, that's actually already captured otherwise.
Andreas, you would like to have some "role catalogue" outside the
sub-schema for collecting all roles, wouldn't you? How about using XSL
or XQuery for such a task with the knowledge of each possible occurence
in the sub-schemas?
Aahh ... I saw, you bound two roles to the 'trainPart' element. That's
really a good point. Let's look, if there are more than one possible
role across the schemas. If there are problems (like the attribute in
<trainPart>) let's file a ticket about it and change it in the near
future.
Hope it helps.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1118 is a reply to message #1106] |
Mon, 15 October 2012 17:46 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Andreas and others,
How about this topic? I want to resume the discussion.
I currently don't see a generic "role-list" for railML 2.2 as there are
already different positions in the railML-tree for this purpose (not in
a separate list).
Susanne Wunsch <coord(at)commonrailmlorg> writes:
> Andreas, you would like to have some "role catalogue" outside the
> sub-schema for collecting all roles, wouldn't you? How about using XSL
> or XQuery for such a task with the knowledge of each possible occurence
> in the sub-schemas?
>
> Aahh ... I saw, you bound two roles to the 'trainPart' element. That's
> really a good point. Let's look, if there are more than one possible
> role across the schemas. If there are problems (like the attribute in
> <trainPart>) let's file a ticket about it and change it in the near
> future.
Do you need some additional "contractor" at the 'trainPart' level?
Other opinions, comments, remarks...?
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1119 is a reply to message #1118] |
Tue, 16 October 2012 08:58 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
We currently use the following roles on the trainPart level:
- contractor (Auftraggeber)
- subcontractor (Fremdunternehmer)
- concessionaire (Konzessionsinhaber)
- operator (Betreiber)
All of these come with attributes like address, phone number, licence
number, etc.
That's why, and because the possible roles vary for different users, I
would prefer to model these as separate and referable entities. This
wouldn't be a breaking change, so why not do it for the next minor release?
Best, --Andreas.
Am 15.10.2012 17:46, schrieb Susanne Wunsch:
> Hi Andreas and others,
>
> How about this topic? I want to resume the discussion.
>
> I currently don't see a generic "role-list" for railML 2.2 as there are
> already different positions in the railML-tree for this purpose (not in
> a separate list).
>
> Susanne Wunsch<coord(at)commonrailmlorg> writes:
>> Andreas, you would like to have some "role catalogue" outside the
>> sub-schema for collecting all roles, wouldn't you? How about using XSL
>> or XQuery for such a task with the knowledge of each possible occurence
>> in the sub-schemas?
>>
>> Aahh ... I saw, you bound two roles to the 'trainPart' element. That's
>> really a good point. Let's look, if there are more than one possible
>> role across the schemas. If there are problems (like the attribute in
>> <trainPart>) let's file a ticket about it and change it in the near
>> future.
>
> Do you need some additional "contractor" at the 'trainPart' level?
>
> Other opinions, comments, remarks...?
>
> Kind regards...
> Susanne
>
|
|
|
|
| Re: roles [message #1120 is a reply to message #1118] |
Thu, 18 October 2012 11:44 |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Susanne and Andreas,
> Other opinions, comments, remarks...?
If it is deemed necessary to keep the addresses, phone numbers a.s.o. of
such companies in RailML, I would also (like Andreas) not repeat them at
each <trainPart> nor <vehicle>. So, I agree that we should create a
central "address" list and make cross-references (ref's) to that list _if_
we want to handle them in RailML.
Since there are more possible kinds of companies as
> - contractor (Auftraggeber)
> - subcontractor (Fremdunternehmer)
> - concessionaire (Konzessionsinhaber)
> - operator (Betreiber)
(possibly "Aufgabenträger" but also "catering contractor...") I would
prefer not to have pre-defined elements for them at <trainPart>. Rather, I
could imagine a general enumerable list of "<contractor>" or "<partner>"
with an attribute for "kind of contractual relationship" =
Aufgabenträger/Auftraggeber/Subauftragnehmer/Caterer...
Probably we will first introduce this principle at <trainPart> but later
extend it for <vehicles>, IMs, TOCs. So the "central address list" (list
of "roles") should probably not be situated at <timetable>.
Best regards,
Dirk.
|
|
|
|
| Re: roles [message #1121 is a reply to message #1120] |
Mon, 05 November 2012 17:36 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk, Andreas and others,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> If it is deemed necessary to keep the addresses, phone numbers
> a.s.o. of such companies in RailML, I would also (like Andreas) not
> repeat them at each <trainPart> nor <vehicle>. So, I agree that we
> should create a central "address" list and make cross-references
> (ref's) to that list _if_ we want to handle them in RailML.
If there is a need for such data I would use an already existing XML
Schema integrated into the current railML structure, like done with
MathML in the rollingstock sub-schema. I don't want to re-invent the
wheel of contact data. ;-)
For all kinds of address data the XML Schema of HR-XML [1] would be a
good starting point, e.g.
<PersonName>
<FormattedName>Andrea Johnson</FormattedName>
<oa:GivenName>Andrea</oa:GivenName>
<FamilyName>Johnson</FamilyName>
</PersonName>
<Communication>
<Address>
<oa:AddressLine sequence="1">2341 Oaks Court</oa:AddressLine>
<oa:CityName>Clear Springs</oa:CityName>
<oa:CountrySubDivisionCode>GA</oa:CountrySubDivisionCode>
<CountryCode>US</CountryCode>
<oa:PostalCode>30127</oa:PostalCode>
</Address>
</Communication>
<Communication>
<ChannelCode>Telephone</ChannelCode>
<UseCode>Personal</UseCode>
<oa:CountryDialing>1</oa:CountryDialing>
<oa:AreaDialing>404</oa:AreaDialing>
<oa:DialNumber>2234421</oa:DialNumber>
</Communication>
<Communication>
<ChannelCode>MobileTelephone</ChannelCode>
<UseCode>Personal</UseCode>
<oa:CountryDialing>1</oa:CountryDialing>
<oa:AreaDialing>404</oa:AreaDialing>
<oa:DialNumber>2211041</oa:DialNumber>
</Communication>
<Communication>
<ChannelCode>Email</ChannelCode>
<UseCode>Personal</UseCode>
<oa:Text>aj2341(at)aolcom</oa:Text>
</Communication>
Otherwise we could re-use the ISO 19139 (Geographic Metadata) [2]
<gmd:pointOfContact>
<gmd:CI_ResponsibleParty>
<gmd:individualName>
<gco:CharacterString>Dagobert Rechtbild</gco:CharacterString>
</gmd:individualName>
<gmd:organisationName>
<gco:CharacterString>Erhebungsfirma "Wir können das am besten", Standort Puntigam,
Abteilung ALS</gco:CharacterString>
</gmd:organisationName>
<gmd:positionName>
<gco:CharacterString>Experte für Luftbilder</gco:CharacterString>
</gmd:positionName>
<gmd:contactInfo>
<gmd:CI_Contact>
<gmd:phone>
<gmd:CI_Telephone>
<gmd:voice>
<gco:CharacterString>+43-316-2345-876</gco:CharacterString >
</gmd:voice>
</gmd:CI_Telephone>
</gmd:phone>
<gmd:address>
<gmd:CI_Address>
<gmd:electronicMailAddress>
<gco:CharacterString>dagobertrechtbild(at)erhebungat</gco:CharacterString>
</gmd:electronicMailAddress>
</gmd:CI_Address>
</gmd:address>
<gmd:contactInstructions>
<gco:CharacterString>Dienstag bis Donnerstag in Graz. Restliche Zeit im Außendienst.</gco:CharacterString>
</gmd:contactInstructions>
</gmd:CI_Contact>
</gmd:contactInfo>
<gmd:role>
<gmd:CI_RoleCode
codeList=" http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO _19139_Schemas/resources/CodeList/gmxCodelists.xml#CI_RoleCo de"
codeListValue="originator">originator</gmd:CI_RoleCode>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gmd:pointOfContact>
Anyway there would be some separate container element for contact
information. Their single entries will be referred from some elements
like already proposed by Andreas.
If there are less information the above examples shrink to less lines of
code.
>
> Since there are more possible kinds of companies as
>> - contractor (Auftraggeber)
>> - subcontractor (Fremdunternehmer)
>> - concessionaire (Konzessionsinhaber)
>> - operator (Betreiber)
> (possibly "Aufgabenträger" but also "catering contractor...")
That would be a railML-extension to the above proposed more general
contact data sets.
> I would prefer not to have pre-defined elements for them at
> <trainPart>. Rather, I could imagine a general enumerable list of
> "<contractor>" or "<partner>" with an attribute for "kind of
> contractual relationship" =
> Aufgabenträger/Auftraggeber/Subauftragnehmer/Caterer...
These detailed contact information with their roles should not be given
and repeated at the trainPart's or vehicle's level. I agree.
I currently don't understand the need for the distinction between
"contractor" and "partner". I mean a "caterer" is always a
"contractor". Maybe I misunderstand something here.
> Probably we will first introduce this principle at <trainPart> but
> later extend it for <vehicles>, IMs, TOCs. So the "central address
> list" (list of "roles") should probably not be situated at
> <timetable>.
+1
I would introduce this separated list in the "common railML area" after
the <metadata> element with the next major release and revise all
current XML tree positions for contact data in that change.
How strong is your need for this extension, Andreas? Do you need a
quick&dirty solution that will be discarded with the next major release?
I filed a Trac ticket for this issue in order to not forget it. [3]
Currently I can't implement anything because of the multiple
proposals. Let's find a common agreement. :-)
Kind regards...
Susanne
[1] http://www.hr-xml.org/
[2] http://www.isotc211.org/2005/gmd/
[3] https://trac.assembla.com/railML/ticket/178
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1127 is a reply to message #1121] |
Fri, 09 November 2012 11:05 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Dear all,
this issue has moderate urgency. Currently, we use a set of proprietary
attributes and in fact, these are even customer-specific since the roles
and their understanding vary between different railway companies.
The contact data is not the main concern, rather the possibility to
define the legal values that a role can take (the "existing" caterers
etc.), without additional schemas. But once we have a container, we
could as well provide full features, and the idea of using an external
existing scheme for contact data looks great.
I would not object postponing this issue for the next major release.
Best, Andreas.
Am 05.11.2012 17:36, schrieb Susanne Wunsch:
> Dear Dirk, Andreas and others,
>
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>
>> If it is deemed necessary to keep the addresses, phone numbers
>> a.s.o. of such companies in RailML, I would also (like Andreas) not
>> repeat them at each <trainPart> nor <vehicle>. So, I agree that we
>> should create a central "address" list and make cross-references
>> (ref's) to that list _if_ we want to handle them in RailML.
>
> If there is a need for such data I would use an already existing XML
> Schema integrated into the current railML structure, like done with
> MathML in the rollingstock sub-schema. I don't want to re-invent the
> wheel of contact data. ;-)
>
> For all kinds of address data the XML Schema of HR-XML [1] would be a
> good starting point, e.g.
>
> <PersonName>
> <FormattedName>Andrea Johnson</FormattedName>
> <oa:GivenName>Andrea</oa:GivenName>
> <FamilyName>Johnson</FamilyName>
> </PersonName>
> <Communication>
> <Address>
> <oa:AddressLine sequence="1">2341 Oaks Court</oa:AddressLine>
> <oa:CityName>Clear Springs</oa:CityName>
> <oa:CountrySubDivisionCode>GA</oa:CountrySubDivisionCode>
> <CountryCode>US</CountryCode>
> <oa:PostalCode>30127</oa:PostalCode>
> </Address>
> </Communication>
> <Communication>
> <ChannelCode>Telephone</ChannelCode>
> <UseCode>Personal</UseCode>
> <oa:CountryDialing>1</oa:CountryDialing>
> <oa:AreaDialing>404</oa:AreaDialing>
> <oa:DialNumber>2234421</oa:DialNumber>
> </Communication>
> <Communication>
> <ChannelCode>MobileTelephone</ChannelCode>
> <UseCode>Personal</UseCode>
> <oa:CountryDialing>1</oa:CountryDialing>
> <oa:AreaDialing>404</oa:AreaDialing>
> <oa:DialNumber>2211041</oa:DialNumber>
> </Communication>
> <Communication>
> <ChannelCode>Email</ChannelCode>
> <UseCode>Personal</UseCode>
> <oa:Text>aj2341(at)aolcom</oa:Text>
> </Communication>
>
> Otherwise we could re-use the ISO 19139 (Geographic Metadata) [2]
>
> <gmd:pointOfContact>
> <gmd:CI_ResponsibleParty>
> <gmd:individualName>
> <gco:CharacterString>Dagobert Rechtbild</gco:CharacterString>
> </gmd:individualName>
> <gmd:organisationName>
> <gco:CharacterString>Erhebungsfirma "Wir können das am besten", Standort Puntigam,
> Abteilung ALS</gco:CharacterString>
> </gmd:organisationName>
> <gmd:positionName>
> <gco:CharacterString>Experte für Luftbilder</gco:CharacterString>
> </gmd:positionName>
> <gmd:contactInfo>
> <gmd:CI_Contact>
> <gmd:phone>
> <gmd:CI_Telephone>
> <gmd:voice>
> <gco:CharacterString>+43-316-2345-876</gco:CharacterString >
> </gmd:voice>
> </gmd:CI_Telephone>
> </gmd:phone>
> <gmd:address>
> <gmd:CI_Address>
> <gmd:electronicMailAddress>
> <gco:CharacterString>dagobertrechtbild(at)erhebungat</gco:CharacterString>
> </gmd:electronicMailAddress>
> </gmd:CI_Address>
> </gmd:address>
> <gmd:contactInstructions>
> <gco:CharacterString>Dienstag bis Donnerstag in Graz. Restliche Zeit im Außendienst.</gco:CharacterString>
> </gmd:contactInstructions>
> </gmd:CI_Contact>
> </gmd:contactInfo>
> <gmd:role>
> <gmd:CI_RoleCode
> codeList=" http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO _19139_Schemas/resources/CodeList/gmxCodelists.xml#CI_RoleCo de"
> codeListValue="originator">originator</gmd:CI_RoleCode>
> </gmd:role>
> </gmd:CI_ResponsibleParty>
> </gmd:pointOfContact>
>
> Anyway there would be some separate container element for contact
> information. Their single entries will be referred from some elements
> like already proposed by Andreas.
>
> If there are less information the above examples shrink to less lines of
> code.
>>
>> Since there are more possible kinds of companies as
>>> - contractor (Auftraggeber)
>>> - subcontractor (Fremdunternehmer)
>>> - concessionaire (Konzessionsinhaber)
>>> - operator (Betreiber)
>> (possibly "Aufgabenträger" but also "catering contractor...")
>
> That would be a railML-extension to the above proposed more general
> contact data sets.
>
>> I would prefer not to have pre-defined elements for them at
>> <trainPart>. Rather, I could imagine a general enumerable list of
>> "<contractor>" or "<partner>" with an attribute for "kind of
>> contractual relationship" =
>> Aufgabenträger/Auftraggeber/Subauftragnehmer/Caterer...
>
> These detailed contact information with their roles should not be given
> and repeated at the trainPart's or vehicle's level. I agree.
>
> I currently don't understand the need for the distinction between
> "contractor" and "partner". I mean a "caterer" is always a
> "contractor". Maybe I misunderstand something here.
>
>> Probably we will first introduce this principle at <trainPart> but
>> later extend it for <vehicles>, IMs, TOCs. So the "central address
>> list" (list of "roles") should probably not be situated at
>> <timetable>.
>
> +1
>
> I would introduce this separated list in the "common railML area" after
> the <metadata> element with the next major release and revise all
> current XML tree positions for contact data in that change.
>
> How strong is your need for this extension, Andreas? Do you need a
> quick&dirty solution that will be discarded with the next major release?
>
> I filed a Trac ticket for this issue in order to not forget it. [3]
> Currently I can't implement anything because of the multiple
> proposals. Let's find a common agreement. :-)
>
> Kind regards...
> Susanne
>
> [1] http://www.hr-xml.org/
> [2] http://www.isotc211.org/2005/gmd/
> [3] https://trac.assembla.com/railML/ticket/178
>
|
|
|
|
| Re: roles [message #1129 is a reply to message #1127] |
Mon, 12 November 2012 10:14 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Andreas Tanner <ata(at)ivude> writes:
> this issue has moderate urgency. Currently, we use a set of
> proprietary attributes and in fact, these are even customer-specific
> since the roles and their understanding vary between different railway
> companies.
Anyway I try to figure out an XML solution that may fit with your
requirements, following the current way to define railML structures
(with most possible explicit constraints to validate with an XML
validator).
> The contact data is not the main concern, rather the possibility to
> define the legal values that a role can take (the "existing" caterers
> etc.), without additional schemas. But once we have a container, we
> could as well provide full features, and the idea of using an external
> existing scheme for contact data looks great.
My proposal:
New container element in the "Common part" <companies> with specified
child elements that may be referred from within the <trainPart>.
<railml>
<metadata> ...
<companies>
<vehicleOperator id="vo1" name="" startDate="" endDate=""/>
<vehicleManufacturer id="vm1" name=""/>
<infrastructureManager id="im1" name=""/>
<railwayUndertaking id="ru1" name=""/>
<concessionaire id="cc1" name=""/>
<contractor id="cr1" name="" role="catering" subLevel="1"/>
<otherCompany id="" name=""/>
</companies>
...
<timetable...>
...
<trainPart...>
...
<companyBinding>
<railwayUndertaking ref="ru1"/>
<contractor ref="cr1"/>
</companyBinding>
</trainPart>
...
</timetable>
</railml>
Any comments appreciated.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1130 is a reply to message #1129] |
Mon, 12 November 2012 11:20 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
> My proposal:
>
> New container element in the "Common part" <companies> with specified
> child elements that may be referred from within the <trainPart>.
>
> <railml>
> <metadata> ...
> <companies>
> <vehicleOperator id="vo1" name="" startDate="" endDate=""/>
> <vehicleManufacturer id="vm1" name=""/>
> <infrastructureManager id="im1" name=""/>
> <railwayUndertaking id="ru1" name=""/>
> <concessionaire id="cc1" name=""/>
> <contractor id="cr1" name="" role="catering" subLevel="1"/>
> <otherCompany id="" name=""/>
> </companies>
> ...
> <timetable...>
> ...
> <trainPart...>
> ...
> <companyBinding>
> <railwayUndertaking ref="ru1"/>
> <contractor ref="cr1"/>
> </companyBinding>
> </trainPart>
> ...
> </timetable>
> </railml>
>
> Any comments appreciated.
>
Thanks for this proposal, it looks good. I would not use the term
"company", though, as often, organizational units (within some company,
or public authority) are meant. So I would prefer <organizationalUnit>,
<otherOrganizationalUnit>, etc.
I'm not sure whether we really need a hierarchical model of roles. I
would be happy if only the <otherCompany> gets a role - attribute and
leave the contractor without.
I'm also not sure about the dates. If these dates are anchored in the
common part, I would understand that the /licence/ or similar of those
units is restricted. But probably, what one wants to restrict is the
/binding/. So I would move the restriction to that location.
Best, Andreas.
> Kind regards...
> Susanne
>
|
|
|
|
|
|
| Re: roles [message #1132 is a reply to message #1130] |
Mon, 12 November 2012 15:52 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Andreas,
Thanks for the quick answer.
Andreas Tanner <ata(at)ivude> writes:
>> My proposal:
>>
>> New container element in the "Common part" <companies> with specified
>> child elements that may be referred from within the <trainPart>.
>>
>> <railml>
>> <metadata> ...
>> <companies>
>> <vehicleOperator id="vo1" name="" startDate="" endDate=""/>
>> <vehicleManufacturer id="vm1" name=""/>
>> <infrastructureManager id="im1" name=""/>
>> <railwayUndertaking id="ru1" name=""/>
>> <concessionaire id="cc1" name=""/>
>> <contractor id="cr1" name="" role="catering" subLevel="1"/>
>> <otherCompany id="" name=""/>
>> </companies>
>> ...
>> <timetable...>
>> ...
>> <trainPart...>
>> ...
>> <companyBinding>
>> <railwayUndertaking ref="ru1"/>
>> <contractor ref="cr1"/>
>> </companyBinding>
>> </trainPart>
>> ...
>> </timetable>
>> </railml>
>>
>> Any comments appreciated.
>>
> Thanks for this proposal, it looks good. I would not use the term
> "company", though, as often, organizational units (within some
> company, or public authority) are meant. So I would prefer
> <organizationalUnit>, <otherOrganizationalUnit>, etc.
I go with your renaming advice.
Additionally would rename 'companyBinding' to 'contractBinding'.
> I'm not sure whether we really need a hierarchical model of roles. I
> would be happy if only the <otherCompany> gets a role - attribute and
> leave the contractor without.
I had two aspects in mind, one would be a sub-contractor like already
proposed by Dirk, the other is that a 'contractor' is a really general
term suitable for all kinds of contract bindings.
So I would drop the "otherCompany" or "otherOrganizationalUnit".
> I'm also not sure about the dates. If these dates are anchored in the
> common part, I would understand that the /licence/ or similar of those
> units is restricted. But probably, what one wants to restrict is the
> /binding/. So I would move the restriction to that location.
Yes, thanks for pointing this out. Let's drop the dates, too.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1133 is a reply to message #1131] |
Mon, 12 November 2012 16:15 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Dirk,
I'm sorry, I don't understand the focus of this posting.
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Am 12.11.2012, 10:14 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
>> <vehicleOperator .../>
>> <vehicleManufacturer .../>
>> <infrastructureManager .../>
>
> Am 18.10.2012, 11:44 Uhr, schrieb Dirk Bräuer <dirkbraeuer(at)irfpde>:
>> I would prefer not to have pre-defined elements for them at
>> <trainPart>.
I really prefer the pre-defined element list with the background of
systematic XML validation options.
>> Rather, I could imagine a general enumerable list of "<contractor>"
>> or "<partner>" with an attribute for "kind of contractual
>> relationship" =
I already asked for the difference between 'contractor' and 'partner'
but got no satisfactory answer.
>> Aufgabenträger/Auftraggeber/Subauftragnehmer/Caterer...
If you need the appropriate element names which you already offered in
German, I give it a try:
Aufgabenträger: Transport organisation authority (AOT)
Auftraggeber: Customer
Subauftragnehmer: Subcontractor
Caterer: Caterer :-)
I would, of course, extend the element's list with these names if they
really match the needed semantics.
Please ask further for any open points.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: roles [message #1135 is a reply to message #1132] |
Tue, 13 November 2012 08:48 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
ese dates are anchored in the
>> common part, I would understand that the /licence/ or similar of those
>> units is restricted. But probably, what one wants to restrict is the
>> /binding/. So I would move the restriction to that location.
>
> Yes, thanks for pointing this out. Let's drop the dates, too.
>
> Kind regards...
> Susanne
>
The requirement of a date was brought in by Joerg von Lingen. I would
not drop it but anchor it with the binding. Otherwise, to me the
proposal looks fine. We should agree on a list of "predefined" roles
(the subelements of <organizationalUnits>) that are sufficiently
general, including their German pendants and a description for the wiki.
Here is a suggestion:
contractor (Auftraggeber) : The authority or enterprise that ordered the
transportation service, i.e., an integrated transit system
railwayUndertaking (Verkehrsunternehmen) : The undertaking that is
commercially responsible for the service
vehicleOperator, in IVU language this would be subcontractor
(Fremdunternehmer) : The railway undertaking that operates the vehicle,
if different from the one that is responsible for the commercial service
- concessionaire (Konzessionsinhaber) ?? Not sure, we use it for bus
transport.
- operator (Betreiber) - the unit that is responsible for the
operational planning of this service
infrastructureManager (Infrastrukturbetreiber) ...
vehicleManufacturer (Fahrzeughersteller) ...
Best, Andreas.
|
|
|
|
| Re: roles [message #1143 is a reply to message #1129] |
Fri, 08 February 2013 13:52 |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hi,
let me summarize the current discussion. You are suggesting a subelement
below <trainPart>:
<timetable...>
...
<trainPart...>
...
<organizationalUnitBinding>
<railwayUndertaking ref="ru1"/>
<contractor ref="cr1"/>
<concessionaire ref="cc1"/>
<vehicleOperator ref="vo1"/>
<operator ref="op1"/>
<infrastructureManager ref="im1"/>
<other:somethingElse ref="se1"/>
</organizationalUnitBinding>
</trainPart>
...
</timetable>
</railml>
The other possibility suggested by Dirk would look like:
<organizationalUnitBinding>
<organizationalUnitBinding type="railwayUndertaking" ref="ru1"/>
<organizationalUnitBinding type="other:somethingElse" ref="se1"/>
</organizationalUnitBinding>
I would prefer the first way of describing, because the types of
organizationalUnitBindings are quite fixed and both methods are
expandable. Its also better to have separated lists for the
railwayUndertakers and operators etc. instead of one giant list of
organizations with an additional type to distiguish between catering
companies and raiway undertakers.
If there is a consense I could implement the timetable part within 2.2 (or
within 2.x).
Kind regards,
Joachim
-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable
--
----== posted via PHP Headliner ==----
|
|
|
|
| Re: roles [message #1144 is a reply to message #1135] |
Mon, 11 February 2013 15:03 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Andreas, Joachim and others,
Andreas Tanner <ata(at)ivude> writes:
> The requirement of a date was brought in by Joerg von Lingen. I would
> not drop it but anchor it with the binding. Otherwise, to me the
> proposal looks fine.
I just implemented this proposal. [1]
The dates for the vehicle operator binding should better stay at the
"vehicle", not at the "vehicle operator".
> We should agree on a list of "predefined" roles
> (the subelements of <organizationalUnits>) that are sufficiently
> general, including their German pendants and a description for the
> wiki.
>
> Here is a suggestion:
>
> contractor (Auftraggeber) : The authority or enterprise that ordered
> the transportation service, i.e., an integrated transit system
Contractor is a very general term for both sides: costumer and supplier.
-> renamed to "customer", keeping the above explanation
> railwayUndertaking (Verkehrsunternehmen) : The undertaking that is
> commercially responsible for the service
+1
> vehicleOperator, in IVU language this would be subcontractor
> (Fremdunternehmer) : The railway undertaking that operates the
> vehicle, if different from the one that is responsible for the
> commercial service
+1
> - concessionaire (Konzessionsinhaber) ?? Not sure, we use it for bus
> transport.
+1
> - operator (Betreiber) - the unit that is responsible for the
> operational planning of this service
Operator is a very general term for each kind of operation and hard to
distinguish from the "railwayUndertaking". -> renamed to
"operationalUndertaking", keeping the above mentioned explanation
> infrastructureManager (Infrastrukturbetreiber) ...
+1
> vehicleManufacturer (Fahrzeughersteller) ...
+1
Added "contractor" as generic enhancement with additional "role" and
"subLevel" attributes for "catering, cleaning... bindings".
References to this elements will be implemented in a specialized way in the
sub-schemas. [2]
Any comments appreciated.
Kind regards...
Susanne
[1] http://trac.assembla.com/railML/changeset/542
[2] http://trac.assembla.com/railML/ticket/178#comment:4
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1145 is a reply to message #1143] |
Tue, 12 February 2013 10:16 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Joachim, Andreas and others,
coord(at)timetablerailmlorg (Joachim Rubroeder) writes:
> let me summarize the current discussion.
Thanks for summarizing the already long thread. :-)
> You are suggesting a subelement below <trainPart>:
>
> <timetable...>
> ..
> <trainPart...>
> ..
> <organizationalUnitBinding>
> <railwayUndertaking ref="ru1"/>
> <contractor ref="cr1"/>
> <concessionaire ref="cc1"/>
> <vehicleOperator ref="vo1"/>
> <operator ref="op1"/>
> <infrastructureManager ref="im1"/>
> <other:somethingElse ref="se1"/>
> </organizationalUnitBinding>
> </trainPart>
> ..
> </timetable>
> </railml>
One question, that came to my mind regarding this list is:
Do we really need an "infrastructureManager", a "vehicleManufacturer"
and a "vehicleOperator" binding in a "trainPart" as just implemented
[1] and partly proposed by myself [2]?
I mean - no.
* The "infrastructureManager" binding should be defined in the
Infrastructure sub-schema for each "track" and/or "line".
It anyway may differ for one "trainPart".
* The "vehicleManufacturer" and "vehicleOperator" binding should be
defined in the Rollingstock sub-schema for each "vehicle".
It anyway may differ for one "trainPart".
That would leave the following contract bindings for the "trainPart":
* customer
* railwayUndertaking
* operationalUndertaking
* concessionaire
* contractor (general usage)
* any (extensions)
Any comments appreciated.
[1] http://trac.assembla.com/railML/changeset/543
[2] http://trac.assembla.com/railML/ticket/178#comment:4
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: roles [message #1147 is a reply to message #1146] |
Tue, 12 February 2013 12:04 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Andreas,
Thanks for the quick reply.
It is the last issue, that is planned to be implemented for the "railML
2.2 Release Candidate 1".
Andreas Tanner <ata(at)ivude> writes:
>> One question, that came to my mind regarding this list is:
>>
>> Do we really need an "infrastructureManager", a "vehicleManufacturer"
>> and a "vehicleOperator" binding in a "trainPart" as just implemented
>> [1] and partly proposed by myself [2]?
>>
>> I mean - no.
>>
>> * The "infrastructureManager" binding should be defined in the
>> Infrastructure sub-schema for each "track" and/or "line".
>>
>> It anyway may differ for one "trainPart".
>>
>> * The "vehicleManufacturer" and "vehicleOperator" binding should be
>> defined in the Rollingstock sub-schema for each "vehicle".
>>
>> It anyway may differ for one "trainPart".
>>
>
> +1 for infrastructureManager and vehicleManufacturer.
> Regarding the vehicleOperator, I would think that binding to trainPart
> should be possible for the case that at a certain planning stage,
> formations are abstract but the assignment to the operator is already
> known.
I see, we talk about different "vehicle operators". I try to clarify my
point of view. Please, correct me, if I mix other contract bindings
here.
* The "vehicle operator" in the Rollingstock sub-schema should be the
company that is the "owner" of the vehicle.
* The "vehicle operator" in the Timetable sub-schema may be the company
that provides the transport service with the vehicle.
Such a use case with different wagons and locos did happen at the
beginning of this timetable period in December 2012:
RE4 of the ODEG: [1]
The wagons and loco of this "fixed formation" had different "vehicle
owners", but are operated by one "vehicle operator" for this service.
[1] http://odeg.de/unternehmen-karriere/presse/pressemitteilunge n/201223/
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: roles [message #1148 is a reply to message #1146] |
Tue, 12 February 2013 13:10 |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hi,
> +1 for infrastructureManager and vehicleManufacturer. Regarding the
> vehicleOperator, I would think that binding to trainPart should be
> possible for the case that at a certain planning stage, formations are
> abstract but the assignment to the operator is already known.
We are getting closer. The proper binding list for a trainPart now looks
like that:
* vehicleOperater
* customer
* railwayUndertaking
* operationalUndertaking
* concessionaire
* contractor (general usage)
* any (extensions)
Kind regards,
Joachim
-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable
--
----== posted via PHP Headliner ==----
|
|
|
|
| Re: roles [message #1149 is a reply to message #1147] |
Tue, 12 February 2013 13:01 |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Am 12.02.2013 12:04, schrieb Susanne Wunsch:
> Hi Andreas,
>
>> Regarding the vehicleOperator, I would think that binding to trainPart
>> should be possible for the case that at a certain planning stage,
>> formations are abstract but the assignment to the operator is already
>> known.
>
> I see, we talk about different "vehicle operators". I try to clarify my
> point of view. Please, correct me, if I mix other contract bindings
> here.
>
> * The "vehicle operator" in the Rollingstock sub-schema should be the
> company that is the "owner" of the vehicle.
>
> * The "vehicle operator" in the Timetable sub-schema may be the company
> that provides the transport service with the vehicle.
>
> Such a use case with different wagons and locos did happen at the
> beginning of this timetable period in December 2012:
>
> RE4 of the ODEG: [1]
>
> The wagons and loco of this "fixed formation" had different "vehicle
> owners", but are operated by one "vehicle operator" for this service.
>
Indeed the real world provides a nice example. I suggested [2] the
vehicleOperator as an equivalent to the IVU subcontractor
(Fremdunternehmer), so the binding would be to the timetable subschema.
[2] news://news.railml.org:119/k7t9ju$cbe$1(at)sifaivifhgde
The usage in the rolling stock schema also makes sense to me.
Best, Andreas.
|
|
|
|
| Re: roles [message #1150 is a reply to message #1149] |
Tue, 12 February 2013 14:07 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Andreas and all others,
Andreas Tanner <ata(at)ivude> writes:
> Am 12.02.2013 12:04, schrieb Susanne Wunsch:
>>> Regarding the vehicleOperator, I would think that binding to trainPart
>>> should be possible for the case that at a certain planning stage,
>>> formations are abstract but the assignment to the operator is already
>>> known.
>>
>> I see, we talk about different "vehicle operators". I try to clarify my
>> point of view. Please, correct me, if I mix other contract bindings
>> here.
>>
>> * The "vehicle operator" in the Rollingstock sub-schema should be the
>> company that is the "owner" of the vehicle.
>>
>> * The "vehicle operator" in the Timetable sub-schema may be the company
>> that provides the transport service with the vehicle.
>>
>> Such a use case with different wagons and locos did happen at the
>> beginning of this timetable period in December 2012:
>>
>> RE4 of the ODEG: [1]
>>
>> The wagons and loco of this "fixed formation" had different "vehicle
>> owners", but are operated by one "vehicle operator" for this service.
>>
>
> Indeed the real world provides a nice example. I suggested [2] the
> vehicleOperator as an equivalent to the IVU subcontractor
> (Fremdunternehmer), so the binding would be to the timetable
> subschema.
>
> [2] news://news.railml.org:119/k7t9ju$cbe$1(at)sifaivifhgde
>
> The usage in the rolling stock schema also makes sense to me.
Thanks for the clarification.
So I would introduce a "vehicleOwner" element in the metadata block for
the Rollingstock binding in order to minimize confusion. That may be
used the following way:
<rollingstock...>
<vehicle...>
<classification>
<operator vehicleOwnerRef="" operatorClass="" startDate="" endDate=""/>
</classification>
</vehicle>
</rollingstock>
The "vehicleOperator" for the Timetable sub-schema stays unchanged.
Any comments appreciated.
Kind regards...
Susanne
CC: railML.rollingstock
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Goto Forum:
Current Time: Sun Nov 03 20:40:02 CET 2024
|
Members
Search
Help
Login
Home
