Roman's mail reminded me on the following relation terms. hasTopology/hasNode/implementedBy related Topologies and Nodes: Topology X --hasTopology--> Topology Y Topology Y --hasNode--> Node Z Node Z --implementedBy--> Node W Question 1: implementedBy seems a bit off here, relating a subset to a larger part (while hasTopology and hasNode relate a larger part to a subset). Is that OK? (Personal opinion: I have never seem an example that used implementedBy, so I consider it somewhat experimental and thus don't really care) hasPort and hasLink relate Groups with its elements: PortGroup G --hasPort--> Port P1 PortGroup G --hasPort--> Port P2 PortGroup G --hasPort--> Port P3 LinkGroup L --hasLink--> Port L1 LinkGroup L --hasLink--> Port L2 LinkGroup L --hasLink--> Port L3 providesPort and providesLink relate Service to it's dynamic configuration: SwitchingService S --providesLink--> Link crossconnect1 SwitchingService S --providesLink--> Link crossconnect2 SwitchingService S --providesLink--> Link crossconnect3 AdaptationService A --providesPort--> Port vlan1 AdaptationService A --providesPort--> Port vlan2 AdaptationService A --providesPort--> Port vlan3 Question 2: are the names "hasPort" and "hasLink" well-chosen? (An alternative would be containsPort and containsLink). (Personal opinion: I think they're OK: they behave similar to hasToplogy and hasNode) Question 3: Are providesLink and providesPort well-chosen? Could we reduce the number of relations by just using hasLink and hasPort instead? (I have no personal opinion on this issue) Freek