Hi, I just got a call from Guy Roberts asking about some details about my "Ethernet media converter" example. Apparently, I did not use the G.800 terminology corretly, so I updated the example. In addition, I added a PDF showing a graphical representation of all descriptions (and a picture of an actual Ethernet media converter). Changes: - use "adaptation source" instead of "adaptation" - use "adaptation sink" instead of "deadaptation" - use "from" instead of "source", as is now in the schema - use "to" instead of "sink", as is now in the schema - make it clear that the URN of technologies are just made up Regards, Freek Hi, 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 uri_for_IEEE_802.3ab uri_for_IEEE_802.3ab name 1000base-T uri_for_IEEE_802.3ab client layer uri_for_Ethernet_layer uri_for_IEEE_802.3ab server layer uri_for_TIA_EIA_568 Adaptation Function id uri_for_1000base-LX uri_for_1000base-LX name 1000base-LX uri_for_1000base-LX client layer uri_for_Ethernet_layer uri_for_1000base-LX server layer uri_for_SM_fibre where uri_for_Ethernet_layer, uri_for_TIA_EIA_568 and uri_for_SM_fibre are layers -- I think we should define a "Layer" class for this. client layer and server layer are attributes of the Adaptation Function class. The "EMC" converter has 2 physical interfaces. Each physical interfaces has Ports on two layers, and both ingress and egress Ports. So 2 x 2 = 4 Ports per physical interface, for a total of 8 Ports: Node id :emc Port id :emc:fiber_in Port id :emc:fiber_out Port id :emc:eth_fiber_in Port id :emc:eth_fiber_out Port id :emc:utp_in Port id :emc:utp_out Port id :emc:eth_utp_in Port id :emc:eth_utp_out The identifiers in this example start with ":", e.g. ":emc:utp_in". In reality, the identifiers will start with "urn:ogf:network:", e.g. "urn:ogf:network:example.net:emc:utp_in", but that is too long for lines in an e-mail. These instances have the following properties: :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 :emc:fiber_in atLayer uri_for_SM_fibre :emc:fiber_out atLayer uri_for_SM_fibre :emc:eth_fiber_in atLayer uri_for_Ethernet_layer :emc:eth_fiber_out atLayer uri_for_Ethernet_layer :emc:utp_in atLayer uri_for_TIA_EIA_568 :emc:utp_out atLayer uri_for_TIA_EIA_568 :emc:eth_utp_in atLayer uri_for_Ethernet_layer :emc:eth_utp_out atLayer uri_for_Ethernet_layer These Ports are internally interconnected as follows: Relation type adaptation-sink from :emc:fiber_in to :emc:eth_fiber_in adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_fiber_out to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_in adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_utp_out to :emc:utp_out adaptation function uri_for_IEEE_802.3ab Relation type cross connect from :emc:eth_fiber_in to :emc:eth_utp_out Relation type cross connect from :emc:eth_utp_in to :emc:eth_fiber_out Two remarks: - I needed to define an additional attribute for the adaptation and adaptation-sink relation. This is currently not possible in the schema. I propose we create two subclasses of Relation, Adaptation and adaptation-sink, 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 adaptation-sink from :emc:fiber_in to :emc:eth_fiber_in adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_fiber_out to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_in adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_utp_out to :emc:utp_out adaptation function uri_for_IEEE_802.3ab Relation type source from :emc:eth_fiber_in to :emc:eth_fiber_to_utp Relation type sink from :emc:eth_fiber_to_utp to :emc:eth_utp_out Relation type source from :emc:eth_utp_in to :emc:eth_utp_to_fiber Relation type sink from :emc:eth_utp_to_fiber to :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 adaptation-sink from :emc:fiber_in to :emc:eth_fiber_to_utp adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_utp_to_fiber to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_to_fiber adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_fiber_to_utp to :emc:utp_out adaptation function uri_for_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). Regards, Freek