References

older
slides from today's OpenFlow and...

Jeroen van der Ham

20 Sep 2012 20 Sep '12

3:13 p.m.

Hi, We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it. Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. Jeroen.

Show replies by date

Freek Dijkstra

20 Sep 20 Sep

6:44 p.m.

On 20-09-2012 17:13, Jeroen van der Ham wrote:

...

Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

A summary of the earlier discussion: idRef is suppossed to be a shortcut for id + isReference True. isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology'). The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined. I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful? Freek

Jerry Sobieski

21 Sep 21 Sep

7:50 a.m.

If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere. And I would salute the desire to keep multiple representations as similar as possible. (just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...

On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Roman Łapacz

9:42 a.m.

I decided to visualize the proposed change using an example: IdRef: http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port> transformed to use isDefinedBy (the way how I see it): http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port> I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism. I'm fine to use Topology inside Relation if this relation is known: http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations. http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port> http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port> Roman W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...

If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Roman Łapacz

10:06 a.m.

One more thing. Some time ago we discussed the use of id/idRef for inheritance. This also could be implemented by the relation. Example: http://schemas.ogf.org/nml/2012/10/relation/inheritedFrom"> Roman W dniu 2012-09-21 11:42, Roman Łapacz pisze:

...

I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Jeroen van der Ham

11:08 a.m.

Hi, I actually meant it more like the following: http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port> Jeroen. On 21 Sep 2012, at 11:42, Roman Łapacz wrote:

...

I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Roman Łapacz

11:25 a.m.

W dniu 2012-09-21 13:08, Jeroen van der Ham pisze:

...

Hi,

I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

Right. This is an example when the xml file with definitions and its location is known. Roman

...

Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz wrote:

...
I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Jeroen van der Ham

11:52 a.m.

On 21 Sep 2012, at 13:25, Roman Łapacz wrote:

...

Right. This is an example when the xml file with definitions and its location is known.

Ah, you meant to show a situation where it is not known? Wouldn't it make more sense to leave it empty then? Jeroen.

Roman Łapacz

12:12 p.m.

W dniu 2012-09-21 13:52, Jeroen van der Ham pisze:

...

On 21 Sep 2012, at 13:25, Roman Łapacz wrote:

...
Right. This is an example when the xml file with definitions and its location is known. Ah, you meant to show a situation where it is not known?

yes

...

Wouldn't it make more sense to leave it empty then?

Sure, I thought to do this but it looked a bit weird to me like incomplete sentence (The port is defined by.) . But I could live with that. Roman

...

Jeroen.

Aaron Brown

2:34 p.m.

On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

...

Hi,

I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

The implication of isDefinedBy here is that all topology is an HTTP GET away. I'm not sure I like encoding "how to get remote topologies" into the base schema defining how we represent topology. As an extension, it might be reasonable, but not in the base. Cheers, Aaron

...

Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz wrote:

...
I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ 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/

Roman Łapacz

2:42 p.m.

W dniu 2012-09-21 16:34, Aaron Brown pisze:

...

On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

...
Hi,

I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

The implication of isDefinedBy here is that all topology is an HTTP GET away. I'm not sure I like encoding "how to get remote topologies" into the base schema defining how we represent topology. As an extension, it might be reasonable, but not in the base.

Agree. Roman

...

Cheers, Aaron

...
Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz mailto:romradz@man.poznan.pl> wrote:

...
I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto: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/

Aaron Brown

3:13 p.m.

On Sep 21, 2012, at 10:34 AM, Aaron Brown wrote:

...

On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

...
Hi,

I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

The implication of isDefinedBy here is that all topology is an HTTP GET away. I'm not sure I like encoding "how to get remote topologies" into the base schema defining how we represent topology. As an extension, it might be reasonable, but not in the base.

Beyond my above complaint, if it was of the form: <link id="ABC"> <relation type="defined-by"> <link id="XYZ"> </relation> </link> I'd be more okay with it. We do have a strange ambiguity with the examples' uses of "id" in relations. We've stated that you can create objects inside of relationships. The whole idea of defining nodes inside of Topology elements is that they are implicitly "hasNode" for the topology. These two representations are semantically equivalent: <topology> <node id="a"> </node> </topology> <topology> <relation type="hasNode"> <node id="a"> </node> </relation> </topology> Now, if a parser is looking at representation two, is it supposed to lookup node definition 'a' elsewhere? It's implicit in the examples that we have that the "id" element really means "go look elsewhere for this" which it isn't supposed to mean. To do a relation properly using 'defined-by', it'd look like: <node> <relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation> </node> This of course has the ambiguity with 'id', but we could simply say "oh well" and define "definedBy" as a special-case. The idRef allowed a compact representation of "look for this definition elsewhere", and without the same ambiguity. Cheers, Aaron

...

Cheers, Aaron

...
Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz wrote:

...
I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

transformed to use isDefinedBy (the way how I see it):

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

...
If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-) J On 9/20/12 8:44 PM, Freek Dijkstra wrote:

...
On 20-09-2012 17:13, Jeroen van der Ham wrote:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere, like in another document/by another organisation (there was still a discussion between Aaron and myself if 'elsewhere' may or may not included 'elsewhere in the file --- thinking about it now, I would say 'in another Topology').

The distinction between isReference and isDefinedBy is that isReference only tells the parser that it is defined elsewhere; isDefinedBy also tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier discussion, what it most useful?

Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ 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/

Internet2 Fall Member Meeting Sep 30-Oct 4, 2012 - Philadelphia, PA http://events.internet2.edu/2012/fall-mm/

Freek Dijkstra

24 Sep 24 Sep

2:01 p.m.

Hi Aaron, Thanks for your email. I now start to understand your take on idRef.

...

...
On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

...
I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

On Sep 21, 2012, at 10:34 AM, Aaron Brown wrote:

...

...
The implication of isDefinedBy here is that all topology is an HTTP GET away. I'm not sure I like encoding "how to get remote topologies" into the base schema defining how we represent topology. As an extension, it might be reasonable, but not in the base.

I agree with Aaron that this seems a bit limited. For one thing, I also like to be able to say that something is a reference, even if I don't know the URI where it is published (think about a domain that supports NML + NSI, which is connected to a domain which does not yet have a NML description published) I'm sure we can fix it, but the bottom line is that the is really a control plane construct, and that is -with good reason- out of scope of NML. A NSI extension is perhaps more logical. I wonder if the same applies to isReference/idRef.

...

Beyond my above complaint, if it was of the form:

<link id="ABC"> <relation type="defined-by"> <link id="XYZ"> </relation> </link>

I'd be more okay with it.

I think we already have this in the form of: <link id="ABC"> <relation type="alias"> <link id="XYZ"> </relation> </link> (though I like your name 'is-defined')

...

<topology> <relation type="hasNode"> <node id="a"> </node> </relation> </topology>

Now, if a parser is looking at representation two, is it supposed to lookup node definition 'a' elsewhere? It's implicit in the examples that we have that the "id" element really means "go look elsewhere for this" which it isn't supposed to mean.

Could you detail your use case a bit more? I think you mean that a parsers which encounters the above like to distinguish between the case where it can just instantiate a Node object "A", and the case where there is not enough detail known. In the later case, the parser is supposed to either look up the details elsewhere (either elsewhere in the file, or with another query) or don't instantiate the object, but use a reference/pointer. Is that a correct interpretation of your mail? I'm trying to understand what the real use case is here. It seems that the most simple NML use case is an organisation that likes to describe its network topology using a Topology object. Since NML does not use a hierarchical namespace, it is useful to denote to others which part of the description are part of the Topology, and which descriptions are merely pointers to other Topologies. Is isReference/idRef necessary for this in the first place? Would it also be possible to e.g. that only objects with a hasNode, hasInboundePort, hasOutboundPort and hasLink (which would be a new implicit relation) are part of the Topology, and the rest -by definition- is not? Freek

Aaron Brown

27 Sep 27 Sep

5:58 p.m.

On Sep 24, 2012, at 10:01 AM, Freek Dijkstra wrote:

...

Hi Aaron,

Thanks for your email. I now start to understand your take on idRef.

...
...
On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

...
I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

On Sep 21, 2012, at 10:34 AM, Aaron Brown wrote:

...
...
The implication of isDefinedBy here is that all topology is an HTTP GET away. I'm not sure I like encoding "how to get remote topologies" into the base schema defining how we represent topology. As an extension, it might be reasonable, but not in the base.

I agree with Aaron that this seems a bit limited. For one thing, I also like to be able to say that something is a reference, even if I don't know the URI where it is published (think about a domain that supports NML + NSI, which is connected to a domain which does not yet have a NML description published)

I'm sure we can fix it, but the bottom line is that the is really a control plane construct, and that is -with good reason- out of scope of NML. A NSI extension is perhaps more logical. I wonder if the same applies to isReference/idRef.

...
Beyond my above complaint, if it was of the form:

<link id="ABC"> <relation type="defined-by"> <link id="XYZ"> </relation> </link>

I'd be more okay with it.

I think we already have this in the form of:

<link id="ABC"> <relation type="alias"> <link id="XYZ"> </relation> </link>

(though I like your name 'is-defined')

...
<topology> <relation type="hasNode"> <node id="a"> </node> </relation> </topology>

Now, if a parser is looking at representation two, is it supposed to lookup node definition 'a' elsewhere? It's implicit in the examples that we have that the "id" element really means "go look elsewhere for this" which it isn't supposed to mean.

Could you detail your use case a bit more?

I think you mean that a parsers which encounters the above like to distinguish between the case where it can just instantiate a Node object "A", and the case where there is not enough detail known. In the later case, the parser is supposed to either look up the details elsewhere (either elsewhere in the file, or with another query) or don't instantiate the object, but use a reference/pointer.

Is that a correct interpretation of your mail?

I'm trying to understand what the real use case is here. It seems that the most simple NML use case is an organisation that likes to describe its network topology using a Topology object. Since NML does not use a hierarchical namespace, it is useful to denote to others which part of the description are part of the Topology, and which descriptions are merely pointers to other Topologies.

Is isReference/idRef necessary for this in the first place? Would it also be possible to e.g. that only objects with a hasNode, hasInboundePort, hasOutboundPort and hasLink (which would be a new implicit relation) are part of the Topology, and the rest -by definition- is not?

Note: I'll be using "named" here to mean an element with an 'id' attribute. The problem is ambiguity. If I can define a new, named object inside of a relation element, how does a parser know that the named object inside the relationship is defined there, as opposed to elsewhere? e.g. In our examples: <port id="A"> ... </port> <node id="N"> <relation type="hasPort"> <port id="A"> </relation> </node> is semantically identical to: <node id="N"> <relation type="hasPort"> <port id="A"> ... </port> </relation> </node> In the latter case, however, how does someone who receives the topology supposed to know that this is the canonical definition of 'A', and they should not be looking for another definition of A elsewhere (e.g. should this be an error, or not per your discussion of in-document references vs. out-of-document references)? Using defined-by, the proper way to write the first thing above is: <port id="A"> ... </port> <node id="N"> http://events.internet2.edu/2012/fall-mm/

Freek Dijkstra

28 Sep 28 Sep

2:33 p.m.

Hi Aaron, Thanks for your mail. I think I see your point, but I want it to be clear (I struggled with some text in the document, and am not happy yet). So I'm going to be devil's advocate for the next two mails.

...

The problem is ambiguity. If I can define a new, named object inside of a relation element, how does a parser know that the named object inside the relationship is defined there, as opposed to elsewhere?

Why does a parser need to know know that the named object inside the relationship is defined there, as opposed to elsewhere? E.g. why can't it just create the object, even though the object may be incomplete, or the object may be wrong. If the rest of the definition is elsewhere in the topology description, Can't it augment the created object with that information when it encounters it later in the file? If not, why not? Just mention one or two reasons, no need for details. I'll put in my next question based on your answer. (You explicitly mentioned typo detection as one reason, and I previously mentioned that it is useful to distinguish between full object descriptions and mere object references. Are these the two reasons? Are they both valid enough to define a relation or parameter?) Freek

Jeroen van der Ham

1 Oct 1 Oct

11:15 a.m.

Hi, On 27 Sep 2012, at 19:58, Aaron Brown wrote:

...

In the latter case, however, how does someone who receives the topology supposed to know that this is the canonical definition of 'A', and they should not be looking for another definition of A elsewhere (e.g. should this be an error, or not per your discussion of in-document references vs. out-of-document references)?

What if you receive two documents and both claim to have the canonical definition of 'A'? Even if this would cause an error, how do you decide which is the right one? Jeroen.

Roman Łapacz

5 Oct 5 Oct

10:12 a.m.

Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline). Roman W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...

Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Jeroen van der Ham

2:06 p.m.

Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue. Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not. For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place. Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places? Jeroen. On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...

Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Roman Łapacz

2:31 p.m.

W dniu 2012-10-05 16:06, Jeroen van der Ham pisze:

...

Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue.

fine by me

...

- id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

I see it simple: multiple use of the same id would be for adding new information/properties of the same element (for example, if the are two elements in one or two different locations with the same id they form just one object). This requires unique ids and assumption that ids are correctly assigned to elements. IdRef would be used only for references (no definition inside). Roman

...

Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Aaron Brown

3:56 p.m.

On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:

...

Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g. <topology> <relation type="hasNode"> <node id=A> # canonical definition </node> </relation> </topology> <port X> <relation type="inNode"> <node id=A> # some added properties from X's perspective about A </node> </relation> </port> <port Y> <relation type="inNode"> <node id=A> # some added properties from Y's perspective about A </node> </relation> </port> Would be semantically equivalent to: <topology> <relation type="hasNode"> <node id=A /> </relation> </topology> <port X> <relation type="inNode"> <node id=A /> </relation> </port> <port Y> <relation type="inNode"> <node id=A /> </relation> </port> <node id=A> # canonical definition # some added properties from X's perspective about A # some added properties from Y's perspective about A </node> Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A. Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous. I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity. Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere. We'd make use of anonymous network elements inside of relationships: <relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation> The above syntax was shortened using the idRef to: <relation type="hasPort"> <port idRef="XYZ" /> </relation> To me, these semantics are logical, and allow scoping properties about a network element. Cheers, Aaron

...

Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ 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/

Roman Łapacz

8 Oct 8 Oct

5:06 p.m.

W dniu 2012-10-05 17:56, Aaron Brown pisze:

...

On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:

...
Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g.

<topology> <relation type="hasNode"> <node id=A> # canonical definition </node> </relation> </topology>

<port X> <relation type="inNode"> <node id=A> # some added properties from X's perspective about A </node> </relation> </port>

<port Y> <relation type="inNode"> <node id=A> # some added properties from Y's perspective about A </node> </relation> </port>

Would be semantically equivalent to:

<topology> <relation type="hasNode"> <node id=A /> </relation> </topology>

<port X> <relation type="inNode"> <node id=A /> </relation> </port>

<port Y> <relation type="inNode"> <node id=A /> </relation> </port>

<node id=A> # canonical definition # some added properties from X's perspective about A # some added properties from Y's perspective about A </node>

Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.

If I remember correctly Jerry presented similar scenario for Nordunett topology (two internal topologies/domains) where the alias relation (a kind of mapping) was used. Internal ids and topology elements were not available externally. Roman

...

Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.

I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.

Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.

We'd make use of anonymous network elements inside of relationships:

<relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation>

The above syntax was shortened using the idRef to:

<relation type="hasPort"> <port idRef="XYZ" /> </relation>

To me, these semantics are logical, and allow scoping properties about a network element.

Cheers, Aaron

...
Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz mailto:romradz@man.poznan.pl> wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto:nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________ nml-wg mailing list nml-wg@ogf.org mailto: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/

Jason Zurawski

11 Oct 11 Oct

6:20 p.m.

Howdy All; Jeroen threatened me with physical harm if I didn't weigh in on this :) I believe that the concept of "additive" relationships with IDs carries *only* within the same scope of use. E.g.:  </id> and  </id> Works if these appear in the same physical document and defn scope. After that, I would say it is not allowed and we must go with references. Thanks; -jason On Oct 8, 2012, at 12:06 PM, Roman Łapacz wrote:

...

W dniu 2012-10-05 17:56, Aaron Brown pisze:

...
On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:

...
Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g.

<topology> <relation type="hasNode"> <node id=A> # canonical definition </node> </relation> </topology>

<port X> <relation type="inNode"> <node id=A> # some added properties from X's perspective about A </node> </relation> </port>

<port Y> <relation type="inNode"> <node id=A> # some added properties from Y's perspective about A </node> </relation> </port>

Would be semantically equivalent to:

<topology> <relation type="hasNode"> <node id=A /> </relation> </topology>

<port X> <relation type="inNode"> <node id=A /> </relation> </port>

<port Y> <relation type="inNode"> <node id=A /> </relation> </port>

<node id=A> # canonical definition # some added properties from X's perspective about A # some added properties from Y's perspective about A </node>

Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.

If I remember correctly Jerry presented similar scenario for Nordunett topology (two internal topologies/domains) where the alias relation (a kind of mapping) was used. Internal ids and topology elements were not available externally.

Roman

...
Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.

I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.

Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.

We'd make use of anonymous network elements inside of relationships:

<relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation>

The above syntax was shortened using the idRef to:

<relation type="hasPort"> <port idRef="XYZ" /> </relation>

To me, these semantics are logical, and allow scoping properties about a network element.

Cheers, Aaron

...
Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

Aaron Brown

12 Oct 12 Oct

6:59 p.m.

The problem is defining the scope, because every relation is going to create a new element. By separating out "referencing A" from "defining A", we remove a substantial amount of the ambiguity. e.g. Topo X Node id=A Service Y Node id=B Relation Node id=A Node id=C Relation Node id=A There are 3 distinct nodes defined in the above, A, B and C. Let's say we are looking at Node B, and we see a relationship with Node A. There are 3 different definitions of Node A in 3 different scopes: X -> A Y -> B -> A Y -> C -> A when trying to resolve the definition of A in scope Y -> B -> A, which "A" contains the definition? If we merge all the definitions of A into a giant A definition, there's ample opportunity for ambiguous statements (e.g. if A's description from Y -> B -> A is "the node I can test against", and A's description from Y -> C -> A is "the node that I'm not allowed to test against", and A's description in X->A is "Internet2's Seattle OWAMP host". Logically, the scoping of those attributes makes sense, but there has to be *some* definition for an element that's unscoped. e.g. if I say, I want element A and I haven't defined a scoping because all I have is an id, I need some way to find "A". The idRef thing allowed us to have relations that said "I'm defining attributes about A from my perspective" whereas going with id for everything means that every relation says "I'm defining A". Cheers, Aaron On Oct 11, 2012, at 2:20 PM, Jason Zurawski wrote:

...

Howdy All;

Jeroen threatened me with physical harm if I didn't weigh in on this :)

I believe that the concept of "additive" relationships with IDs carries *only* within the same scope of use. E.g.:

 </id>

and

 </id>

Works if these appear in the same physical document and defn scope. After that, I would say it is not allowed and we must go with references.

Thanks;

-jason

On Oct 8, 2012, at 12:06 PM, Roman Łapacz wrote:

...
W dniu 2012-10-05 17:56, Aaron Brown pisze:

...
On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:

...
Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g.

<topology> <relation type="hasNode"> <node id=A> # canonical definition </node> </relation> </topology>

<port X> <relation type="inNode"> <node id=A> # some added properties from X's perspective about A </node> </relation> </port>

<port Y> <relation type="inNode"> <node id=A> # some added properties from Y's perspective about A </node> </relation> </port>

Would be semantically equivalent to:

<topology> <relation type="hasNode"> <node id=A /> </relation> </topology>

<port X> <relation type="inNode"> <node id=A /> </relation> </port>

<port Y> <relation type="inNode"> <node id=A /> </relation> </port>

<node id=A> # canonical definition # some added properties from X's perspective about A # some added properties from Y's perspective about A </node>

Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.

If I remember correctly Jerry presented similar scenario for Nordunett topology (two internal topologies/domains) where the alias relation (a kind of mapping) was used. Internal ids and topology elements were not available externally.

Roman

...
Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.

I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.

Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.

We'd make use of anonymous network elements inside of relationships:

<relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation>

The above syntax was shortened using the idRef to:

<relation type="hasPort"> <port idRef="XYZ" /> </relation>

To me, these semantics are logical, and allow scoping properties about a network element.

Cheers, Aaron

...
Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:

...
Hi,

We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.

Jeroen.

TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/

Jason Zurawski

7:05 p.m.

I think Aaron's explanation is precise, and does offer a very clear reason to just not go down this rat hole. I will change my vote to say that to avoid scope issues, we should just require a single defn and use references whenever possible. Thanks; -jason On Oct 12, 2012, at 1:59 PM, Aaron Brown wrote:

...

The problem is defining the scope, because every relation is going to create a new element. By separating out "referencing A" from "defining A", we remove a substantial amount of the ambiguity.

e.g.

Topo X Node id=A

Service Y Node id=B Relation Node id=A Node id=C Relation Node id=A

There are 3 distinct nodes defined in the above, A, B and C. Let's say we are looking at Node B, and we see a relationship with Node A. There are 3 different definitions of Node A in 3 different scopes:

X -> A Y -> B -> A Y -> C -> A

when trying to resolve the definition of A in scope Y -> B -> A, which "A" contains the definition?

If we merge all the definitions of A into a giant A definition, there's ample opportunity for ambiguous statements (e.g. if A's description from Y -> B -> A is "the node I can test against", and A's description from Y -> C -> A is "the node that I'm not allowed to test against", and A's description in X->A is "Internet2's Seattle OWAMP host". Logically, the scoping of those attributes makes sense, but there has to be *some* definition for an element that's unscoped. e.g. if I say, I want element A and I haven't defined a scoping because all I have is an id, I need some way to find "A".

The idRef thing allowed us to have relations that said "I'm defining attributes about A from my perspective" whereas going with id for everything means that every relation says "I'm defining A".

Cheers, Aaron

On Oct 11, 2012, at 2:20 PM, Jason Zurawski wrote:

...
Howdy All;

Jeroen threatened me with physical harm if I didn't weigh in on this :)

I believe that the concept of "additive" relationships with IDs carries *only* within the same scope of use. E.g.:

 </id>

and

 </id>

Works if these appear in the same physical document and defn scope. After that, I would say it is not allowed and we must go with references.

Thanks;

-jason

On Oct 8, 2012, at 12:06 PM, Roman Łapacz wrote:

...
W dniu 2012-10-05 17:56, Aaron Brown pisze:

...
On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:

...
Yes indeed. Freek is now out of the running, so it is up to us to finalize things and close this issue.

Summarizing: - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue. - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.

For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere. In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.

Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?

So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g.

<topology> <relation type="hasNode"> <node id=A> # canonical definition </node> </relation> </topology>

<port X> <relation type="inNode"> <node id=A> # some added properties from X's perspective about A </node> </relation> </port>

<port Y> <relation type="inNode"> <node id=A> # some added properties from Y's perspective about A </node> </relation> </port>

Would be semantically equivalent to:

<topology> <relation type="hasNode"> <node id=A /> </relation> </topology>

<port X> <relation type="inNode"> <node id=A /> </relation> </port>

<port Y> <relation type="inNode"> <node id=A /> </relation> </port>

<node id=A> # canonical definition # some added properties from X's perspective about A # some added properties from Y's perspective about A </node>

Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.

If I remember correctly Jerry presented similar scenario for Nordunett topology (two internal topologies/domains) where the alias relation (a kind of mapping) was used. Internal ids and topology elements were not available externally.

Roman

...
Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.

I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.

Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.

We'd make use of anonymous network elements inside of relationships:

<relation type="hasPort"> <port> <relation type="definedBy"> <port id="XYZ" /> </relation> </port> </relation>

The above syntax was shortened using the idRef to:

<relation type="hasPort"> <port idRef="XYZ" /> </relation>

To me, these semantics are logical, and allow scoping properties about a network element.

Cheers, Aaron

...
Jeroen.

On 5 Oct 2012, at 12:12, Roman Łapacz wrote:

...
Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Roman

W dniu 2012-09-20 17:13, Jeroen van der Ham pisze: > Hi, > > We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. > The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it. > > Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. > > Jeroen.

TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/

----- Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318] TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/

Freek Dijkstra

5 Oct 5 Oct

7:48 p.m.

On 05-10-2012 12:12, Roman Łapacz wrote:

...

Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).

Yes, isReference is the only major issue. Unnamed NML objects also needs text, but the issues are clear there. If there is no clear use case and proposal after this OGF, I will be forced to move this 'isReference' and 'idRef' to experimental status, where it will be published in a separate document. At a first read, I very much value Aaron's proposal, so I have good hopes this still can be part of the base document. Am I correct that there are now two proposals? Jeroen's proposal: "If there are 2 network elements with the same id attribute in a given document, the union of the two elements should be considered the canonical definition of the element" Aaron's Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined. Regards, Freek

Jeroen van der Ham

8 Oct 8 Oct

12:58 p.m.

Hi, On 5 Oct 2012, at 14:48, Freek Dijkstra wrote:

...

Jeroen's proposal: "If there are 2 network elements with the same id attribute in a given document, the union of the two elements should be considered the canonical definition of the element"

Aaron's Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined.

I think so. Some questions for Aaron's approach: - If you have a big database with measurements and topology information, would that mean you can only ever describe a network element once? - How would you cope with updates and changes? Jeroen.

Aaron Brown

12 Oct 12 Oct

7:10 p.m.

On Oct 8, 2012, at 8:58 AM, Jeroen van der Ham wrote:

...

Hi,

On 5 Oct 2012, at 14:48, Freek Dijkstra wrote:

...
Jeroen's proposal: "If there are 2 network elements with the same id attribute in a given document, the union of the two elements should be considered the canonical definition of the element"

Aaron's Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined.

I think so.

Some questions for Aaron's approach: - If you have a big database with measurements and topology information, would that mean you can only ever describe a network element once?

It depends on what you mean by describe. You can always annotate the network element: <Node> <Relation type="inherits-from"> <Node A /> </Relation> ... some measurement data about A ... </Node> You're not "defining" A, you're simply saying "I have information about A", and it's scoped by your context.

...

- How would you cope with updates and changes?

My recollection is that there is a version number attribute or a timeframe attribute during which they are valid (can't recall which). I'd be fine with having multiple definitions as long as each has a different version number, or non-overlapping timeframe. Then, if you ask for A, you know which attributes were valid when, and can use that to "scope" down the A you care about. (most recent, or the A or As that were valid during a given timeframe). Cheers, Aaron

...

Jeroen.

_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/

4376

Age (days ago)

4398

Last active (days ago)

List overview

Download

26 comments

6 participants

participants (6)

Aaron Brown
Freek Dijkstra
Jason Zurawski
Jeroen van der Ham
Jerry Sobieski
Roman Łapacz

References

Freek Dijkstra

Freek Dijkstra

Freek Dijkstra

Freek Dijkstra

tags

participants (6)