Meaning of nameOfClass

It seems that NeTEx uses nameOfClass to carry explicit class metadata in XML instances. This way of supporting model-driven design and enabling loosely coupled, schema-independent processing across distributed systems. It more or less mimics RDF's ability for having data describe itself.

So in XML, we can see something like this:

<StopPlace id="SP1" nameOfClass="StopPlace"/>

With our xsd2rdf convertet, the XSD would be converted into SHACL/OWL/SKOS where the implemented data would look like this:

:SP1 a netex:StopPlace;
	netex:nameOfClass netex-skos:StopPlace .

This is obviously redundant. And probably it's also already redundant in the XSD source. Or maybe it happens to have something like this:

<Entity id="SP1" nameOfClass="StopPlace"/>

In which case the RDF would be:

:SP1 a netex:Entity;
	netex:nameOfClass netex-skos:StopPlace .

Question: Why is it needed in the latest version of NeTEx v2.0?

[skinkie]

The nameOfClass and nameOfRefClass allow finding of which type has been specified. Within NeTEx itself nothing is forcing an id to be object type unique. Hence StopPlace id="1" version="1" and ScheduledStopPoint id="1" version="1" are unique based on being different object types.

When there is some form of inhertance such as TimingPoint -> ScheduledStopPoint -> FareScheduledStopPoint, a TimingPointRef may point to a FareScheduledStopPoint my expilicitly setting nameOfRefClass="FareScheduledStopPoint".

Specifically when references have been designed as abstract like FromPointFrom and ToPointRef nameOfRefClass must be explicitly set.

So to conclude, the triplet (nameOfClass, id, version) are the actual key in references.

[gatemezing]

Dear @skinkie - thank you for the feedback. What do you think @MathiasVDA ?

[MathiasVDA]

@skinkie thank you for your explanation. Please allow me some follow up questions to better understand the structure

The nameOfClass and nameOfRefClass allow finding of which type has been specified. Within NeTEx itself nothing is forcing an id to be object type unique. Hence StopPlace id="1" version="1" and ScheduledStopPoint id="1" version="1" are unique based on being different object types.

I understand that when the id attribute is not unique (IMO a bad practice, id attributes are expected to be unique in XML documents), there's a need for further specification such as nameOfRefClass. But that doesn't explain the reason for the existence of nameOfClass, since this can be derived from the element tag? You seem to explain the reason for the nameOfRefClass to exist but not nameOfClass attribute.

So to conclude, the triplet (nameOfClass, id, version) are the actual key in references.

When I trace the inheritance from StopPlace back to where the nameOfClass is defined, it is marked as use="optional". How can a field that is part of a composite key be optional?

Plus, the convention seems to be that the id value is a value from an external register and includes the type: https://entur.atlassian.net/wiki/spaces/PUBLIC/pages/728563782/General+information+NeTEx#Conventions
or is this only Entur specific convention?

Incase the above convention is only Entur specific, how does Netex allow referencing elements that are not defined in the same xml file? If the id="1", that seems to be xsd valid but very local.

@gatemezing fyi

[skinkie]

I understand that when the id attribute is not unique (IMO a bad practice, id attributes are expected to be unique in XML documents),

Compound keys cannot be expressed by xs:id in XML Schema. Hence xs:key is used to model the compound keys, specifically on object types.

there's a need for further specification such as nameOfRefClass. But that doesn't explain the reason for the existence of nameOfClass, since this can be derived from the element tag? You seem to explain the reason for the nameOfRefClass to exist but not nameOfClass attribute.

The likely answer is that while for NeTEx 2.0 I have fixed all nameOfRefClass static attributes, the nameOfClass attributes have not been fixed per object type, likely also unwanted.

    <xsd:element name="Entity" type="EntityStructure" abstract="true">
        <xsd:annotation>
            <xsd:documentation>Any data instance to be managed in an operational Version Management System. When several DATA SOURCEs coexist (multimodality and/or interoperability), an ENTITY has to be related to a given DATA SYSTEM in which it is defined.</xsd:documentation>
        </xsd:annotation>
    </xsd:element>
    <xsd:complexType name="EntityStructure" abstract="true">
        <xsd:annotation>
            <xsd:documentation>Type for ENTITY.</xsd:documentation>
        </xsd:annotation>
        <xsd:attribute name="nameOfClass" type="NameOfClass" use="optional">
            <xsd:annotation>
                <xsd:documentation>Name of Class of the ENTITY. Allows reflection. Fixed for each ENTITY type.</xsd:documentation>
            </xsd:annotation>
        </xsd:attribute>
        <xsd:attribute name="id" type="ObjectIdType" use="optional">
            <xsd:annotation>
                <xsd:documentation>Identifier of ENTITY.</xsd:documentation>
            </xsd:annotation>
        </xsd:attribute>
    </xsd:complexType>

So to conclude, the triplet (nameOfClass, id, version) are the actual key in references.

When I trace the inheritance from StopPlace back to where the nameOfClass is defined, it is marked as use="optional". How can a field that is part of a composite key be optional?

Two parts of this answer. The obvious part: because it has never been enforced in the technical artifact.
The less obvious part: xs:key and use="optional" are never checked in relationship towards each other.
Don't know if we want to have them fixed because then they would always show up in the rendering.

Plus, the convention seems to be that the id value is a value from an external register and includes the type: https://entur.atlassian.net/wiki/spaces/PUBLIC/pages/728563782/General+information+NeTEx#Conventions or is this only Entur specific convention?

The first part of the question does not make sense, regardless of what the Nordic profile has implemented, the suggestion that it is from an external register cannot be derived from that page.

Incase the above convention is only Entur specific, how does Netex allow referencing elements that are not defined in the same xml file? If the id="1", that seems to be xsd valid but very local.

Business logic. The identity key constraint, and its checks, are only enforced when all parts are specified. The Entur implementation greatly depends on not running those checks via XML Schema per document, but in custom software, running over multiple documents.

[MathiasVDA]

there's a need for further specification such as nameOfRefClass. But that doesn't explain the reason for the existence of nameOfClass, since this can be derived from the element tag? You seem to explain the reason for the nameOfRefClass to exist but not nameOfClass attribute.

The likely answer is that while for NeTEx 2.0 I have fixed all nameOfRefClass static attributes, the nameOfClass attributes have not been fixed per object type, likely also unwanted.

Sorry but I still don't understand the existence of nameOfClass from this answer. Whether or not the attribute is fixed (I assume you mean 'required'?), doesn't answer why it is necessary.

Plus, the convention seems to be that the id value is a value from an external register and includes the type: https://entur.atlassian.net/wiki/spaces/PUBLIC/pages/728563782/General+information+NeTEx#Conventions or is this only Entur specific convention?

The first part of the question does not make sense, regardless of what the Nordic profile has implemented, the suggestion that it is from an external register cannot be derived from that page.

I derived the "value from an external register" due to the use of "codespaces" in the compound id. I agree it is not the same as an external register but very similar and the fact that it makes sense or not is not so much relevant to the question. From your answer and reference to "Nordic profile", I assume that you are answering "This is only an Entur specific convention and doesn't apply for general Netex usage". That was not clear to me.

Incase the above convention is only Entur specific, how does Netex allow referencing elements that are not defined in the same xml file? If the id="1", that seems to be xsd valid but very local.

Business logic. The identity key constraint, and its checks, are only enforced when all parts are specified. The Entur implementation greatly depends on not running those checks via XML Schema per document, but in custom software, running over multiple documents.

I understand this answer as "having a set of Netex files is insufficient to determine identity and reference, there is also a need to have the business logic by which those files have been generated or are meant to be interpreted".

@gatemezing this is becoming a big problem for TSI Telematics. At the very least, a TSI Telematics specific 'profile' will need to be defined comparable to Entur's profile.

[skinkie]

Sorry but I still don't understand the existence of nameOfClass from this answer. Whether or not the attribute is fixed (I assume you mean 'required'?), doesn't answer why it is necessary.

No, I mean fixed="TheNameOfTheClass".

Can you rephrase the question you have on this topic?

I derived the "value from an external register" due to the use of "codespaces" in the compound id. I agree it is not the same as an external register but very similar and the fact that it makes sense or not is not so much relevant to the question. From your answer and reference to "Nordic profile", I assume that you are answering "This is only an Entur specific convention and doesn't apply for general Netex usage". That was not clear to me.

No. Codespace has nothing to do with being part of this document or external.

Incase the above convention is only Entur specific, how does Netex allow referencing elements that are not defined in the same xml file? If the id="1", that seems to be xsd valid but very local.

Business logic. The identity key constraint, and its checks, are only enforced when all parts are specified. The Entur implementation greatly depends on not running those checks via XML Schema per document, but in custom software, running over multiple documents.

I understand this answer as "having a set of Netex files is insufficient to determine identity and reference, there is also a need to have the business logic by which those files have been generated or are meant to be interpreted".

No. A complete NeTEx file with all elements in it, is sufficent to pass XML Schema validation. If the delivery, such as in Norway, consists of multiple documents, or extenal references to a stop registry, such as in The Netherlands. Those references cannot be resolved, for this the standard describes the use of versionRef, instead of the version attribute.

[MathiasVDA]

Can you rephrase the question you have on this topic?

What is the purpose of the "nameOfClass" attribute when there is already the element's tag?

[skinkie]

While currently not implemented (nameOfClass does not have the default value in XML Schema that represents the class) there XML elements having the same tag name. An example is the different namespace between NeTEx and SIRI both sharing some element names.
My guess is that the purpose of this attribute is to make expilict how nameOfClass, id and version form a compound key. This is currently done via xpath that selects not the attribute the the namespace and element tag.

[MathiasVDA]

If nameOfClass is intended to identify the class independently from the XML element name, why does it only contain the local class name and not the namespace-qualified class name? In the presence of multiple XML namespaces, the element QName is more precise than nameOfClass.

I'm sorry but I have the feeling that you are guessing the answer (from the quote "My guess is ..."). I really appreciate any help that you can provide but considering that we are working on railway telematics and EU regulation, which are very complex topics in and of itself with a significant impact, we would need more clear answers.

[skinkie]

"Complex topics" haha. If you are asking questions at the level of abstract elements, without reviewing any existing railway work in NeTEx, your focus is depth first, instead of breadth first. Typical for projects without a functional design.

[MathiasVDA]

Thank you for the discussion so far. Unfortunately, I feel the conversation is moving away from my original question.

My question remains: what is the purpose of the nameOfClass attribute when the class can already be derived from the element QName (namespace + element name)?

If anyone can point to a normative source (Transmodel, NeTEx documentation, UML model, design rationale, etc.) or provide a constructive explanation of the intended purpose of nameOfClass, I would be very grateful.

[gatemezing]

"Complex topics" haha. If you are asking questions at the level of abstract elements, without reviewing any existing railway work in NeTEx, your focus is depth first, instead of breadth first. Typical for projects without a functional design.

Dear @skinkie . You understand that this question is to be able to generate a telematics ontology for ERA ontology which is part of the TEL TSI.
I will ask a meeting with your team for a more detailed understanding / cc @TuThoThai

[skinkie]

@gatemezing TEL TSI needs a NeTEx Profile defining the functional scope of what information must be exchanged. Defining an ontology (read: mapping) leads to a single outcome: conversions of existing implementation, not native implementations.

[MathiasVDA]

Sidetracking the discussion again....

Regarding the comment that "TEL TSI needs a NeTEx profile": our approach is effectively addressing that need, albeit through semantic technologies rather than through a traditional XML-first profiling exercise.

What we are currently developing is an ontology based on the NeTEx conceptual model. On top of that ontology, we will define SHACL shapes that constrain and validate the data content required for TEL TSI use cases. These SHACL shapes specify which classes, properties, cardinalities and constraints are applicable, in much the same way that a NeTEx profile specifies the subset and rules applicable to a particular implementation.

Therefore, the SHACL shapes can be regarded as the semantic equivalent of a NeTEx profile. They define the permitted message content and validation rules, but do so in RDF-based technologies rather than directly in XML.

This aligns with the stated preference from DG MOVE and ERA to work with semantic technologies (RDF, ontologies, SHACL) as the primary artefacts. XML serializations can still be derived or mapped where needed, but the governance of the information requirements is maintained at the semantic level.

For "TEL TSI needs a NeTEx profile", the process would be: first create a conventional NeTEx profile, and only afterwards develop the RDF representation. That could be a valid approach as well but is not the one that was chosen nor preferred.