| Frage zu TT:category [message #738] |
Fri, 10 June 2011 15:25  |
Christoph.Jobmann
Messages: 12
Registered: October 2010
|
Junior Member |
|
|
Hallo zusammen,
ich bin vor kurzem auf ein kleines Problem beim Einsatz des Elements
TT:category gestoÃen. Im Wiki steht, dass dieses einen "Zugtyp", bzw.
eine "Zuggattung" oder auch eine "Zugkategorie" abbilden kann.
Grundsätzlich ist es also auch möglich, in einem Datensatz ein
category-Element für den Zugtyp (z.B. "ICE") und ein category-Element
für die Zuggattung (z.B. "14.2") anzugeben.
Leider sehe ich keine Möglichkeit, einem trainPart die Kombination aus
Zugtyp und Zuggattung zuzuordnen, da nur ein Attribut "categoryRef"
vorgesehen ist. In timetable v1.0 war dies durch separate Attribute "kind"
und "kindNo" noch möglich.
Natürlich könnte man sich ein category-Element vorstellen, welches beide
Informationen codiert (z.B. "ICE-14.2"), diese Herangehensweise halte ich
aber nicht für nachhaltig.
Meine Frage ist nun, ob ich vielleicht einen Ausweg übersehen habe?
Falls nein, könnte ich mir vorstellen, dass in einer zukünftigen Version
das Attribut "categoryRef" zu einem dem Element trainPart untergeordnetem
Element wird, welches beliebig oft auftreten darf.
Viele GrüÃe
Christoph Jobmann
--
----== posted via PHP Headliner ==----
|
|
|
|
| Re: Frage zu TT:category [message #740 is a reply to message #738] |
Tue, 21 June 2011 09:11  |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hallo Christoph,
Du hast vollkommen recht, "categoryRef" gibt es im Moment nur je ein Feld
bei "trainPart" und bei "trainPartSequence". Wenn man auf der gleichen
Ebene mehrere "category"-Arten zugleich angeben möchte, geht das im
Momnet nur über Kombi-Kategorien ("ICE-14.2").
Wenn man allerdings ein mehrfach möglichen Unterelement daraus macht,
könnte ein "trainPart" theoretisch gleichzeit "IC" und "ICE" sein, was
auch wieder fragwürdig und schwer vermittelbar ist. Mir wäre es daher
lieber, wenn man die verschiedenen Kategorisierungsarten fachlich klarer
voneinander trennen könnte, um ihnen jeweils eigene Felder zuweisen zu
können.
Für eine künftige Version bin ich da aber völlig offen und hoffe auf
eine rege Diskussion und konstruktive Vorschläge.
VIele Grüsse,
Joachim Rubröder
Christoph Jobmann wrote:
>
> Hallo zusammen,
>
> ich bin vor kurzem auf ein kleines Problem beim Einsatz des Elements
> TT:category gestoÃen. Im Wiki steht, dass dieses einen "Zugtyp", bzw.
> eine "Zuggattung" oder auch eine "Zugkategorie" abbilden kann.
>
> Grundsätzlich ist es also auch möglich, in einem Datensatz ein
> category-Element für den Zugtyp (z.B. "ICE") und ein category-Element
> für die Zuggattung (z.B. "14.2") anzugeben.
>
> Leider sehe ich keine Möglichkeit, einem trainPart die Kombination aus
> Zugtyp und Zuggattung zuzuordnen, da nur ein Attribut "categoryRef"
> vorgesehen ist. In timetable v1.0 war dies durch separate Attribute "kind"
> und "kindNo" noch möglich.
> Natürlich könnte man sich ein category-Element vorstellen, welches beide
> Informationen codiert (z.B. "ICE-14.2"), diese Herangehensweise halte ich
> aber nicht für nachhaltig.
>
> Meine Frage ist nun, ob ich vielleicht einen Ausweg übersehen habe?
> Falls nein, könnte ich mir vorstellen, dass in einer zukünftigen Version
> das Attribut "categoryRef" zu einem dem Element trainPart untergeordnetem
> Element wird, welches beliebig oft auftreten darf.
>
> Viele GrüÃe
> Christoph Jobmann
>
--
----== posted via PHP Headliner ==----
|
|
|
|
|
|
| Re: Frage zu TT:category [message #847 is a reply to message #741] |
Tue, 06 November 2012 13:23 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Simon, Joachim, Christoph and others,
Sorry for the late response, better now than never. I'm not an expert in
this field. ;-)
"Simon Heller" <sih(at)ivude> writes:
> meiner Meinung nach reicht das eine category-Elementn völlig
> aus. Andernfalls werden wir meistens redundante Informationen
> transportieren. Wenn "ICE" ein Zugtyp im Sinne eine Zugkategorie und
> nicht eines Fahrzeugs sein soll, dann sollte das Zielsystem wissen,
> dass sich hinter der category 14.2 ein "ICE" verbirgt.
Ja, ich plädiere auch für die einzelne 'categoryRef' im <trainPart>.
Zum anderen erinnere ich gern daran, dass wir einen generischen
Grundtypen verwenden, der mehrere Attribute automatisch bereitstellt.
Eines dieser Attribute ist der zuweilen umstrittene und als "Joker"
verwendete 'code'. Dieses Attribut ist in diesem Fall völlig angebracht.
Es stellt einen fachlichen typischen "Code" bereit, der von anderen
Softwaretools auf die gleiche Weise verstanden wird:
"for typical, specific abbreviations, used in different systems with the
same understanding"
<category id="cat01" name="ICE" description="InterCityExpress"
trainUsage="passenger" categoryPriority="1"
code="14.2"/>
Diese spezielle Verwendung könnte auf der Wiki-Dokumentationsseite
ergänzt werden. [1]
Zum anderen gibt es hier möglicherweise eine andere semantische
Unkorrektheit.
* Gehört die Abkürzung "ICE" in das 'name'-Attribut oder in das
'code'-Attribut?
* Gehört die Langbezeichnung "InterCityExpress" in das 'name'-Attribut
oder in das 'description'-Attribut?
> Wenn "ICE" doch eher ein Fahrzeugtyp ist, sollte diese Information in
> der Formation transportiert werden.
Ja, dort gibt es das ja auch. Jedoch mit teilweise gleicher Semantik.
* Eine <formation> kann mehrere <category> (aus dem Timetable-Teil)
referenzieren. Das sagt aus, für welche Zugtypen das Rollmaterial
eingesetzt werden kann.
* Ein <vehicle> kann in classification/manufacturer eine 'serialNumber'
definieren. Das kann auch eine Baureihennummer sein.
Das sollte evtl. auch in der Wiki-Dokumentations-Seite noch näher
beschrieben werden. [2]
Kind regards...
Susanne
[1] http://www.wiki.railml.org/index.php?title=TT:category
[2] http://www.wiki.railml.org/index.php?title=RS:manufacturer
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
