hasPort/hasLink vs providesPort/providesLink

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

On Aug 21, 2012, at 10:30 AM, Freek Dijkstra wrote:
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)
Seems reasonable to me. "ImplementedBy" could theoretically involve multiple elements, so putting the 1:M relationship into the '1' side instead of the 'M' side seems fine to me. This is an area where it might be nice to have the reverse relationship available so if you're looking at a member of the 'M' part of the relationship, you could see that it's involved there, but i'm not sure it much matters right now.
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)
I like that they match the other 'has' relations.
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)
I guess I'd need to see what the difference would be since I'm not positive how they'd be used in practice. Cheers, Aaron
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Fall Member Meeting Sep 30-Oct 4, 2012 - Philadelphia, PA http://events.internet2.edu/2012/fall-mm/
participants (2)
-
Aaron Brown
-
Freek Dijkstra