DataSource, Relationships and entity references

1.1.1 DataSource

An ENTITY is linked to a DATA SOURCE, which is used to identify the system that originated the version of the ENTITY in the exchanged data set. Each ENTITY may have its own DATA SOURCE: for example, STOP PLACEs coming from the consolidated UK NAPTAN National registry of stops might all be declared as sourced from ‘nptg:NaPTAN’, so that the XML tag for a STOP PLACE might read:

<StopPlace version="001" dataSourceRef="nptg:NaPTAN" id="napt:910GWIMBLDN">.

Usually all the data in a data set comes from the same source so the DataSource is specified at the VERSION FRAME level using the DefaultDataSource attribute on the VersionFrame / FrameDefaults.

DataSource is a specialisation of TypeOfValue. But has no additional attributes of its own. See 5.4.1 below.

1.2 Relationships and entity references

In order to turn any computer-based representation of a data set (as an object model or database) into an EPIP conformant NeTEx data file that can be exchanged, it shall be serialised by the producer system into an XML document – that is, a stream of characters grouped within XML tags. This requires in particular that the producer system encodes the relationships between entities (on the computer system represented by object pointers or keys in a database) in a way that can be correctly interpreted as the same relationships by any consumer system reading the XML document. This is typically done in two different ways:

(a) Containment – Related entities are grouped within the body of the referencing element. This is appropriate for implementing composition relationships where there is an inherent hierarchy, as say in the Codespace example above, or for the contents of a VersionFrame.

(b) Reference – The relationship is implemented by a ‘reference’ attribute on containing the identifier(s) of the related element. This is appropriate for association relationships which link two entities. Depending on the semantics and navigability of the relationship, a reference may be held on an entity at one or both ends of the relationship.

XML EXAMPLES

For example, to serialise a StopPlace è quays composition relationship for two platforms of Wimbledon Station, containment within a quays tag is used to embed the child Quay instances inline;

<quays>

<Name>Platform 1</Name>

</Quay>

<Name>Platform 2 </Name>

</Quay>

</quays>

</StopPlace>

For example, to serialise a many-to-one StopPlace è TopographicPlace association for Wimbledon station, a versioned reference to the TopographicPlace is held on the StopPlace:

<Name>Wimbledon Rail Station</Name>

<TopographicPlaceRef version="any" ref="nptg:E0034695">Wimbledon</TopographicPlaceRef>

</StopPlace>

For one-to-many associations, where the referencing element holds multiple references, NeTEx always uses a wrapper tag based on the relationship name to group the references. For example, a StopPlace / types association that holds references to two different instances of TypeOfZone.

<types>

<TypeOfZoneRef version="any" ref="napt:Type_of_zone@GRLS"/>

<TypeOfZoneRef version="any" ref="uicStationCat:476"/>

</types>

</StopPlace>

Note: For flexibility, in the NeTEx schema every dependent child element includes an attribute to hold a reference to its parent. If the parent is evident from the context, as say when nesting child elements within a parent, the reference to the parent does not need to be populated (and in the EPIP shall not be). For example, the ParentZoneRef shown here is not needed on the Quay instances because they are embedded inline within the parent StopPlace..

<quays>

<Name>Platform 1</Name>

<ParentZoneRef version="8.6" ref="napt:910GWIMBLDN">NOT NEEDED</ParentZoneRef>

</Quay>

<ParentZoneRef version="8.6" ref="napt:910GWIMBLDN">NOT NEEDED</ParentZoneRef>

<Name>Platform 2 </Name>

</Quay>

</quays>

</StopPlace>