[Nml-wg] id/idref and inverse relations

[Freek Dijkstra]

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:

<nml:Link id="urn:ogf:network:es.net:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port idRef="urn:ogf:network:internet2.edu:2012:LinkA"/>
  </nml:Relation>
</nml:Link>

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.:

<nml:Link id="urn:ogf:network:internet2.edu:2012:LinkA">
  <nml:Relation type="hasSource">
    <nml:Port idRef="urn:ogf:network:es.net:2012:PortA"/>
  </nml:Relation>
</nml:Link>

2) Define all inverse relations

E.g.

<nml:Link idRef="urn:ogf:network:es.net:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port id="urn:ogf:network:internet2.edu:2012:LinkA"/>
  </nml:Relation>
</nml:Link>


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):

<nml:Link id="urn:ogf:network:example.net:2012:linkZ">
  <nml:Relation type="isSerialCompoundLink">
    <!-- this is a list -->
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
      <nml:Relation type="next">
        <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
      </nml:Relation>
    </nml:Link>
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
      <nml:Relation type="next">
        <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
      </nml:Relation>
    </nml:Link>
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  </nml:Relation>
</nml:Link>

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

<nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
  <nml:Relation type="next">
    <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
  </nml:Relation>
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
  <nml:Relation type="next">
    <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
  </nml:Relation>
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>

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>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
    <nml:Relation type="next">
      <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
    </nml:Relation>
  </nml:List>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
    <nml:Relation type="next">
      <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
    </nml:Relation>
  </nml:Link>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  <nml:Relation type="isSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</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