id/idref and inverse relations

Jeroen van der Ham

3 Apr 2012 3 Apr '12

1:59 p.m.

Hello all, During the call last week we discussed a use-case brought up by Aaron: A client domain may want to correct locally how a Link is connected by them, but this Link is originally described by the Provider. We have done some back-and-forth on the GridForge site and it has become a rather lengthy discussion, raising several different issues, which have become further reaching than we originally thought: - Allow the use of idRef as the subject[0] of a Relation - Allow the inverse definition of a relation - How does authority come into descriptions [0]: I'm using the RDF (subject --predicate-> object) interpretation of "subject" here. Allow the use of idRef as subject: ---------------------------------- I was not sure whether we ever decided on this. So far I have only seen examples of elements with "id" attributes as subjects of relations, no "idRef". As far as I understand it, the intention of the "id" attribute is to create and define an object. It can then later be used as object of Relations using idRef. If we allow idRef's also as subjects, it means that there is no longer a single place in a file or set of files where an object is defined. I have no idea whether this is required, but this should probably be noted as a caveat for implementation. Allow the inverse definition of a relation ------------------------------------------ The above "single place of description" also applies when we allow inverse definitions. The definition of an inverse for a one-to-one relation is simple. However it is not so clear how to define the inverse of a one-to-many relation, even more so when ordering is required. The simplest solution would then be to use an explicit group concept. Authority of descriptions ------------------------- We have not discussed trust and authority of topology descriptions so far. This is something that at some point we have to say something about, also whether it is in scope or not. Either way, if we allow the above constructs, we at least lose the single place of description, which may be a possible mechanism for authority and trust. Was it the intention that idRef as subject was already allowed? If not, do we want to allow it now? Are there any other implications of using idRef as subject? Do we want to allow inverse relations? If so, how do we handle the many-to-one relations? Jeroen.

Show replies by date

Aaron Brown

3 Apr 3 Apr

6:49 p.m.

On Apr 3, 2012, at 9:59 AM, Jeroen van der Ham wrote:

...

Hello all,

During the call last week we discussed a use-case brought up by Aaron:

A client domain may want to correct locally how a Link is connected by them, but this Link is originally described by the Provider.

We have done some back-and-forth on the GridForge site and it has become a rather lengthy discussion, raising several different issues, which have become further reaching than we originally thought:

- Allow the use of idRef as the subject[0] of a Relation - Allow the inverse definition of a relation - How does authority come into descriptions

[0]: I'm using the RDF (subject --predicate-> object) interpretation of "subject" here.

Allow the use of idRef as subject: ----------------------------------

I was not sure whether we ever decided on this. So far I have only seen examples of elements with "id" attributes as subjects of relations, no "idRef". As far as I understand it, the intention of the "id" attribute is to create and define an object. It can then later be used as object of Relations using idRef.

If we allow idRef's also as subjects, it means that there is no longer a single place in a file or set of files where an object is defined. I have no idea whether this is required, but this should probably be noted as a caveat for implementation.

Allowing idRef's as subjects doesn't really bother me too much because I'm guessing that people are likely to structure things in a way that isn't too outlandish given their protocols/services making use of the NML ontology/schema.

...

Allow the inverse definition of a relation ------------------------------------------

The above "single place of description" also applies when we allow inverse definitions.

The definition of an inverse for a one-to-one relation is simple. However it is not so clear how to define the inverse of a one-to-many relation, even more so when ordering is required. The simplest solution would then be to use an explicit group concept.

The inverse relationship is seen from the perspective of the element defining it. So, if there's a VLAN, with A, B and C where A is the source and B and C are sinks, from B's perspective, C doesn't exist (outside of an implicit quasi-relationship through A). So if B decided to define an "isSink" relationship to A, it wouldn't matter that A had defined "hasSink" relations for both B and C.

...

Authority of descriptions -------------------------

We have not discussed trust and authority of topology descriptions so far. This is something that at some point we have to say something about, also whether it is in scope or not. Either way, if we allow the above constructs, we at least lose the single place of description, which may be a possible mechanism for authority and trust.

I think authority and trust are out of scope. Using the 'single place of description' as a mechanism for authority and trust, if I were to define an element in our topology that's actually an ESnet network element, it's 'authoritative' in the sense that 'it only exists in one topology', but it wouldn't actually be authoritative since I don't speak for ESnet (until my nomination to Energy Secretary goes through, that is). Anyone who is going to use NML and wrangle with authority and trust is going to need to build some logic into the underlying services and protocols to define who gets to be authoritative, and as soon as they do that, anyone outside of the authoritative realm wouldn't be trusted, no matter what they claimed. Cheers, Aaron

...

Was it the intention that idRef as subject was already allowed? If not, do we want to allow it now? Are there any other implications of using idRef as subject?

Do we want to allow inverse relations? If so, how do we handle the many-to-one relations?

Jeroen.

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

Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/

Freek Dijkstra

7:49 p.m.

Hey Aaron and Jeroen, Thanks for your input.

...

...
Allow the use of idRef as subject: ---------------------------------- I was not sure whether we ever decided on this. So far I have only seen examples of elements with "id" attributes as subjects of relations, no "idRef". As far as I understand it, the intention of the "id" attribute is to create and define an object. It can then later be used as object of Relations using idRef.

Actually, I'm interested to hear about the difference from others. Coming from a RDF background which does not distinguish between id and idRef, they are more or less the same to me. Intuitively, I see an idRef as a pointer, and an id as something that can be pointed at, but nothing else. Aaron, I kind of was under the impression during the last conf call that you liked to add the following meaning to the "id" and "idRef" attributes: A client can only use an "id" attribute for elements it defines itself, and that for all other elements it MUST use the idRef attribute. E.g. If you're Internet2, and like to refer to an element of ESnet, you need to use an idRef. This fails for a situation where a Port of ESnet is connected to a Link of Internet2: There is currently no means to use id for LinkA, and idRef for PortA, unless we allow either one of these situations: 1) Allow the use of idRef as subject E.g.: 2) Define all inverse relations E.g. Is this what you meant to propose, or did I misinterpret your intended goal?

...

Allowing idRef's as subjects doesn't really bother me too much

Me neither, but I'm curious about the use case, and the meaning.

...

...
Allow the inverse definition of a relation ------------------------------------------

The above "single place of description" also applies when we allow inverse definitions.

The definition of an inverse for a one-to-one relation is simple. However it is not so clear how to define the inverse of a one-to-many relation, even more so when ordering is required. The simplest solution would then be to use an explicit group concept.

The inverse relationship is seen from the perspective of the element defining it. So, if there's a VLAN, with A, B and C where A is the source and B and C are sinks, from B's perspective, C doesn't exist (outside of an implicit quasi-relationship through A). So if B decided to define an "isSink" relationship to A, it wouldn't matter that A had defined "hasSink" relations for both B and C.

Here is a more practical example I was thinking of. Currently some relations are one-to-many, such as isSerialCompoundLink. How should the inverse relation be written in XML? For example, how to define the inverse of the following Relation (where LinkZ has 3 segments: LinkA, LinkB and LinkC):  Here is my first attempy. Add a relation from each of LinkA, LinkB and LinkC to LinkZ. The disadvantage is that this creates ambiguity of the "next" element, as LinkA, LinkB and LinkC are no longer grouped as with the isSerialCompoundLink relation. Second attempyt. Should there be some grouping around the list? (I think this is what Jeroen suggested at OGF32, but was voted down at that time) nml:List

...

...
Authority of descriptions -------------------------

We have not discussed trust and authority of topology descriptions so far.

...

I think authority and trust are out of scope. Using the 'single place of description' as a mechanism for authority and trust,

I regret using the word "authority" in previous conversations. I most certainly did not intend to relate this to "trust" in any way, and currently don't want to start such a discussion. (Jeroen, you brought up "trust" here -- may I take it that's just because we seem to use the word "authority" in a slightly different way, or do you want to bring up that discussion?) All I meant to say is "single place of description" and allow some flag for a client to signify "hey, I'm defining something here" -- to me that is the same as saying "hey, I consider myself an authority for this element here". If you have a better suggestion to name this, please guide me. Regards, Freek

Roman Łapacz

4 Apr 4 Apr

10:19 a.m.

W dniu 2012-04-03 21:49, Freek Dijkstra pisze:

...

Hey Aaron and Jeroen,

Thanks for your input.

...
...
Allow the use of idRef as subject: ---------------------------------- I was not sure whether we ever decided on this. So far I have only seen examples of elements with "id" attributes as subjects of relations, no "idRef". As far as I understand it, the intention of the "id" attribute is to create and define an object. It can then later be used as object of Relations using idRef. Actually, I'm interested to hear about the difference from others. Coming from a RDF background which does not distinguish between id and idRef, they are more or less the same to me.

Intuitively, I see an idRef as a pointer, and an id as something that can be pointed at, but nothing else.

Aaron, I kind of was under the impression during the last conf call that you liked to add the following meaning to the "id" and "idRef" attributes:

A client can only use an "id" attribute for elements it defines itself, and that for all other elements it MUST use the idRef attribute.

E.g. If you're Internet2, and like to refer to an element of ESnet, you need to use an idRef.

This fails for a situation where a Port of ESnet is connected to a Link of Internet2:

There is currently no means to use id for LinkA, and idRef for PortA, unless we allow either one of these situations:

1) Allow the use of idRef as subject

E.g.:

2) Define all inverse relations

E.g.

My understanding of idRef is very simple. It's only a reference and should not inlcude any additional nested information/sub-elements. 1) is correct to me.

...

Is this what you meant to propose, or did I misinterpret your intended goal?

...
Allowing idRef's as subjects doesn't really bother me too much Me neither, but I'm curious about the use case, and the meaning.

...
...
Allow the inverse definition of a relation ------------------------------------------

The above "single place of description" also applies when we allow inverse definitions.

The definition of an inverse for a one-to-one relation is simple. However it is not so clear how to define the inverse of a one-to-many relation, even more so when ordering is required. The simplest solution would then be to use an explicit group concept. The inverse relationship is seen from the perspective of the element defining it. So, if there's a VLAN, with A, B and C where A is the source and B and C are sinks, from B's perspective, C doesn't exist (outside of an implicit quasi-relationship through A). So if B decided to define an "isSink" relationship to A, it wouldn't matter that A had defined "hasSink" relations for both B and C. Here is a more practical example I was thinking of.

Currently some relations are one-to-many, such as isSerialCompoundLink. How should the inverse relation be written in XML?

For example, how to define the inverse of the following Relation (where LinkZ has 3 segments: LinkA, LinkB and LinkC):



Here is my first attempy. Add a relation from each of LinkA, LinkB and LinkC to LinkZ.

I'm not sure that we really need to have the inverse relation in all cases. I'm not against but maybe the types like "partofSerialCompoundLink" should be treated as extensions (different namespace of attribute, eg. nml-ext:type). This way the core set of types would be minimal (its values would be the most useful and popular). Roman

...

The disadvantage is that this creates ambiguity of the "next" element, as LinkA, LinkB and LinkC are no longer grouped as with the isSerialCompoundLink relation.

Second attempyt. Should there be some grouping around the list? (I think this is what Jeroen suggested at OGF32, but was voted down at that time)

nml:List

...
...
Authority of descriptions -------------------------

We have not discussed trust and authority of topology descriptions so far. I think authority and trust are out of scope. Using the 'single place of description' as a mechanism for authority and trust, I regret using the word "authority" in previous conversations. I most certainly did not intend to relate this to "trust" in any way, and currently don't want to start such a discussion. (Jeroen, you brought up "trust" here -- may I take it that's just because we seem to use the word "authority" in a slightly different way, or do you want to bring up that discussion?)

All I meant to say is "single place of description" and allow some flag for a client to signify "hey, I'm defining something here" -- to me that is the same as saying "hey, I consider myself an authority for this element here". If you have a better suggestion to name this, please guide me.

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

Freek Dijkstra

11:14 a.m.

Roman Łapacz wrote:

...

I'm not sure that we really need to have the inverse relation in all cases. I'm not against but maybe the types like "partofSerialCompoundLink" should be treated as extensions (different namespace of attribute, eg. nml-ext:type). This way the core set of types would be minimal (its values would be the most useful and popular).

Roman, you're a proponent of allowing inverse relations. Could you give a use case why we need it in the first place? Thanks, Freek

Roman Łapacz

11:45 a.m.

W dniu 2012-04-04 13:14, Freek Dijkstra pisze:

...

Roman Łapacz wrote:

...
I'm not sure that we really need to have the inverse relation in all cases. I'm not against but maybe the types like "partofSerialCompoundLink" should be treated as extensions (different namespace of attribute, eg. nml-ext:type). This way the core set of types would be minimal (its values would be the most useful and popular). Roman, you're a proponent of allowing inverse relations.

Could you give a use case why we need it in the first place?

If I remember correctly our topology examples we usually used links containing ports/port references (shortly speaking). But our discussion with NSI showed that their aproach is different. The NSI topology is based on STPs/ports (using connectedTo). Switching from OWL into NML does not has to force NSI to change that approach. Use of Ports with isSink/isSource could be more intuitive for NSI. Roman

...

Thanks, Freek

Freek Dijkstra

2:14 p.m.

Roman Łapacz wrote:

...

...
Could you give a use case why we need it in the first place?

Use of Ports with isSink/isSource could be more intuitive for NSI.

Thanks, good enough for me :) I was just wondering if it had more profound implications, like disallowing certain statements (e.g. "if B is defined by someone else, you MUST NOT say A --(R)--> B, but MUST say B --(R')--> A."). If it is just syntactic sugar, I don't see a problem with it. MY only (minor) remark is that too much (syntactic) sugar is not good for us, as it makes NML more complex than it need to be. (In this case, we might want to check with the NSI folks if the current limitation is a problem or not). Regards, Freek

Freek Dijkstra

11:12 a.m.

...

There is currently no means to use id for LinkA, and idRef for PortA, unless we allow either one of these situations:

It seems I copied and paste incorrectly at the following two examples. Here is the correction.

...

1) Allow the use of idRef as subject

E.g.:

2) Define all inverse relations

E.g.

Sorry about the confusion.

4567

Age (days ago)

4568

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Aaron Brown
Freek Dijkstra
Jeroen van der Ham
Roman Łapacz