Home » railML newsgroups » railml.common » roles
| 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
|
|
|
|
Current Time: Wed May 08 08:10:15 CEST 2024
|
Members
Search
Help
Login
Home
