Hi, (I promised this weeks ago, so here it goes. I do feel sorry if you just returned form holiday to find your NML mailbox flooded by Jeroen, John, Guy and yours truly). Imagine an Ethernet media converter. (That is a very simple device with two ports: one fiber port, one copper port. It effectively converts between Ethernet over copper to Ethernet over UTP and vice versa.) Our converter is called EMC, and coverts between 1000base-T (copper) and 1000base-X (fibre). For the sake of simplicity, I will ignore that it is not really Ethernet over fibre, but Ethernet over a given wavelength over a given encoding over a fibre. (Nitpicks will be delighted to know it's 770-860 nm for 1000base-SX, 1270-1355nm for 1000base-LX, and 1550nm for 1000base-ZX/LH, and all use a 8b/10b encoding. Rejoice.) First, I assume that the following technology definitions have already been defined: Adaptation Function id urn:ieee:802.3ab urn:ieee:802.3ab name 1000base-T urn:ieee:802.3ab client layer urn:ieee:802.3-2005 urn:ieee:802.3ab server layer urn:ansi:eia-568-a Adaptation Function id urn:ieee:802.3-clause38 urn:ieee:802.3-clause38 name 1000base-LX urn:ieee:802.3-clause38 client layer urn:ieee:802.3-2005 urn:ieee:802.3-clause38 server layer urn:itu:fiber-8micron where urn:ieee:802.3-2005, urn:ansi:eia-568-a and urn:itu:fiber-8micron are layers -- I think we should define a class for this too. client layer and server layer are attributes of the Adaptation Function class. The "EMC" converter has 2 bidirectional interface, each on two layers. A NML Port is unidirectional on a single layer, so this Node has 8 Ports: Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_utp_in :emc hasPort :emc:eth_utp_out (note: the actual identifiers will start with "urn:ogf:network:", e.g. "urn:ogf:network:example.net:emc", but that is too long, so I write ":emc") These Ports are internally interconnected as follows: Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_in adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_fiber_out sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_in adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_utp_out sink :emc:utp_out adaptation function urn:ieee:802.3ab Relation type cross connect source :emc:eth_fiber_in sink :emc:eth_utp_out Relation type cross connect source :emc:eth_utp_in sink :emc:eth_fiber_out Two remarks: - I needed to define an additional attribute for the adaptation and deadaptation relation. This is currently not possible in the schema. I propose we create two subclasses of Relation, Adaptation and Deadaptation, with attribute "adaptation function". The alternative is to stick the attribute in the Relation class. However, that would mean all relation carry this attribute, even the "implemented by" relation. - I did define a "cross connect" relation above. This is not necessary. Bellow are two alternatives. The second approach is longer and defines a Link. The third approach is shorter. ALTERNATIVE: Approach 2, with Link instance (The description of a switch will be similar to this one, only with a SwitchMatrix Service instead of a Link) Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_utp_in :emc hasPort :emc:eth_utp_out Link id :emc:eth_fiber_to_utp Link if :emc:eth_utp_to_fiber Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_in adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_fiber_out sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_in adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_utp_out sink :emc:utp_out adaptation function urn:ieee:802.3ab Relation type source source :emc:eth_fiber_in sink :emc:eth_fiber_to_utp Relation type sink source :emc:eth_fiber_to_utp sink :emc:eth_utp_out Relation type source source :emc:eth_utp_in sink :emc:eth_utp_to_fiber Relation type sink source :emc:eth_utp_to_fiber sink :emc:eth_fiber_out ALTERNATIVE: Approach 3, compact description (in here, two ethernet Ports are merged into one) Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_fiber_to_utp :emc hasPort :emc:eth_utp_to_fiber Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_to_utp adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_utp_to_fiber sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_to_fiber adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_fiber_to_utp sink :emc:utp_out adaptation function urn:ieee:802.3ab I don't think there is a "correct" alternative -- all are equivalent from a functional point of view. However, we can decide to strive for a uniform approach, like approach 2 (since that will look most like other Node descriptions). Finally, I have not explicitly defined the layer for each interface, because it was already apparent from the (de)adaptations. For a single layer Node, this information can not be derived (is not transitive). So there is may be necessary to make this explicit. If we make all the implicit properties explicit, approach 1 will look like: Node id :emc Port id :emc:fiber_in :emc hasPort :emc:fiber_in :emc:fiber_in atLayer urn:itu:fiber-8micron Port id :emc:fiber_out :emc hasPort :emc:fiber_out :emc:fiber_out atLayer urn:itu:fiber-8micron Port id :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_in :emc:eth_fiber_in atLayer urn:ieee:802.3-2005 Port id :emc:eth_fiber_out :emc hasPort :emc:eth_fiber_out :emc:eth_fiber_out atLayer urn:ieee:802.3-2005 Port id :emc:utp_in :emc hasPort :emc:utp_in :emc:utp_in atLayer urn:ansi:eia-568-a Port id :emc:utp_out :emc hasPort :emc:utp_out :emc:utp_out atLayer urn:ansi:eia-568-a Port id :emc:eth_utp_in :emc hasPort :emc:eth_utp_in :emc:eth_utp_in atLayer urn:ieee:802.3-2005 Port id :emc:eth_utp_out :emc hasPort :emc:eth_utp_out :emc:eth_utp_out atLayer urn:ieee:802.3-2005 This defines a new attribute, atLayer, which might be defined as a Relation type if the Layer class is a subclass of Network Object. Regards, Freek