[Nml-wg] id/idref and inverse relations

Wed Apr 4 06:19:16 EDT 2012

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

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

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>
>    <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
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg