Home » railML newsgroups » railml.common » roles
| 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
>
|
|
|
|
Current Time: Sun Sep 15 09:07:56 CEST 2024
|
Members
Search
Help
Login
Home
