Hi all, I've tried to list all relations that I've seen so far in NML that we've made a decision on and have used. I came to the list below, let's discuss it in the call. Jeroen. <Topology|Node> hasNode <Node> <Topology> hasTopology <Topology> <NE> hasService <Service> <Node> hasInboundPort <Port> <Node< hasOutboundPort <Port> <Port> isSink <Link> <Port> isSource <Link> <Link> isSerialCompound <Group> <Node> locatedAt <Location> <Node> implementedBy <Node> Grouping is done slightly differently in XML and RDF: Grouping in XML: Containment for elements. Ordering: <NE> next <NE> Grouping in RDF: <Group> contains <NE> Ordered group is done using extra ListItem objects: <ListItem> item <NE> <ListItem> next <ListItem> Jeroen.
Jeroen van der Ham wrote:
Hi all,
I've tried to list all relations that I've seen so far in NML that we've made a decision on and have used. I came to the list below, let's discuss it in the call.
Jeroen.
<Topology|Node> hasNode <Node> <Topology> hasTopology <Topology> <NE> hasService <Service> <Node> hasInboundPort <Port> <Node< hasOutboundPort <Port>
I think this should be: <Topology|Node> hasInboundPort <Port> <Topology|Node< hasOutboundPort <Port>
<Port> isSink <Link> <Port> isSource <Link> <Link> isSerialCompound <Group>
I think it's isSerialCompoundLink (see artf6545).
<Node> locatedAt <Location> <Node> implementedBy <Node>
One more (this is from Sept last year, and given the recent feedback on Adaptation service, I propose to add this to the "done" list): <Service> providesPort <Port> (for adaptation service) Two more, but given that there is a clear name conflict, and the recent proposal for Link--(providesLink)->Link was met with the "nice, but not essential for the base schema" feedback, I'd say these are still open for debate/further proposals/use case to proof their need: <Service> providesLink <Port> (for switching service) <Link> providesLink <Link> (proposed shortcut for adaptations) Regards, Freek
Jeroen van der Ham wrote:
Grouping is done slightly differently in XML and RDF:
Grouping in XML: Containment for elements.
Ordering: <NE> next <NE>
Grouping in RDF: <Group> contains <NE>
Ordered group is done using extra ListItem objects: <ListItem> item <NE> <ListItem> next <ListItem>
I presume for RDF you mean <Group> contains <ListItem> We also have the following grouping relations: <Node> implementedBy <Node> <Topology|Node> hasNode <Node> <Topology> hasTopology <Topology> <NE> hasService <Service> While updated the UML schema, I noted we are missing a few group-to-element relations: <BidirectionalPort> ????? <Port> <BidirectionalLink> ????? <Link> <Topology|Node> ????? <Link|LinkGroup> (NB: Node ---> Link is used for cross connects, in case that's not immediately obvious.) And with the recent LinkGroup and PortGroup we also need: <PortGroup> ????? <Port> <LinkGroup> ????? <Link> Can we use hasPort/hasLink for the 5 missing relations? <NE> hasPort <Port> <NE> hasLink <Port> Regards, Freek
W dniu 2012-06-21 14:57, Freek Dijkstra pisze:
Jeroen van der Ham wrote:
Grouping is done slightly differently in XML and RDF:
Grouping in XML: Containment for elements.
Ordering: <NE> next<NE>
Grouping in RDF: <Group> contains<NE>
Ordered group is done using extra ListItem objects: <ListItem> item<NE> <ListItem> next<ListItem> I presume for RDF you mean <Group> contains<ListItem>
We also have the following grouping relations: <Node> implementedBy<Node> <Topology|Node> hasNode<Node> <Topology> hasTopology<Topology> <NE> hasService<Service>
While updated the UML schema, I noted we are missing a few group-to-element relations:
<BidirectionalPort> ?????<Port> <BidirectionalLink> ?????<Link> <Topology|Node> ?????<Link|LinkGroup>
(NB: Node ---> Link is used for cross connects, in case that's not immediately obvious.)
And with the recent LinkGroup and PortGroup we also need: <PortGroup> ?????<Port> <LinkGroup> ?????<Link>
Can we use hasPort/hasLink for the 5 missing relations?
<NE> hasPort<Port> <NE> hasLink<Port>
In my opinoin we don't have to use the relation element for mentioned cases. Simple inclusion would be enough. example: <BidirectionalPort> <Port/> <Port/> </BidirectionalPort> Roman
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Roman Łapacz wrote:
While updated the UML schema, I noted we are missing a few group-to-element relations:
????? ????? ????? [...] ????? ?????
Can we use hasPort/hasLink for the 5 missing relations?
hasPort hasLink In my opinoin we don't have to use the relation element for mentioned cases. Simple inclusion would be enough.
I should have mentioned: I'm proposing this in the context of RDF, which does require explicit names. We indeed agreed on simple inclusion in in XML, and I don't think we should change that. So is the above fine in RDF or do we like something else, e.g. contains . Freek
[Sorry for this resent. I just dumped crappy Postbox mail client, and went back to Thunderbird. Let's see if that does not screw up plain text that contains HTML-like constructs...] Roman Łapacz wrote:
While updated the UML schema, I noted we are missing a few group-to-element relations:
<BidirectionalPort> ????? <Port> <BidirectionalLink> ????? <Link> <Topology|Node> ????? <Link|LinkGroup> [...] <PortGroup> ????? <Port> <LinkGroup> ????? <Link>
Can we use hasPort/hasLink for the 5 missing relations?
<NetworkObject> hasPort<Port> <NetworkObject> hasLink<Port>
In my opinoin we don't have to use the relation element for mentioned cases. Simple inclusion would be enough.
I should have mentioned: I'm proposing this in the context of RDF, which does require explicit names. We indeed agreed on simple inclusion in in XML, and I don't think we should change that. So is the above fine in RDF or do we like something else, e.g. <Group> contains <NetworkObject>. Freek
participants (3)
-
Freek Dijkstra -
Jeroen van der Ham -
Roman Łapacz