[Nml-wg] id/idref and inverse relations

[Aaron Brown]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120403/eac4dd89/attachment.html>