[Nml-wg] Serial compound relations

[Jason Zurawski]

Hi Freek/All;

On 12/13/10 3:07 PM, Freek Dijkstra wrote:
> Jason Zurawski wrote:
>
>>> A better syntax proposal is indeed (note that nml:segment is replaced by
>>> nml:link, and nm:idRef is replaces by nm:id):
>>>
>>> <nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC">
>>>     <nml:relation type="serialcompound" cl:type="partial">
>>>       <nml:link nm:id="urn:ogf:network:example.net:segmentAB"/>
>>>     </nml:relation>
>>> </nml:link>
>>
>> I still think this is a little off.  I would assume that 'segmentAB'
>> belongs to someone already?  If this is the case, it's defined already,
>> so you would use an idRef (as a pointer) in the second enclosed link
>> instead of an id.  If it is not already defined, than the use of 'id' is
>> appropriate, but brings up another issue of defining links within
>> relations/other links.  We have avoided this in the past.
>
> Actually, it is still not quite clear to me why there is a need to
> distinguish between id and idRef. If two objects have with the same
> value for the id attribute, it is clear they refer to the same thing.
>
> (Obviously I can imagine a few reasons to distinguish between id and
> idRef. For example (1) RDF has them both -with different names- for
> syntaxtic reasons; (2) id is used by authoritative sources, while idRef
> is used by non-authoratitive sources; (3) id is used when the object is
> defined the first time in a document, and idRef is used subsequently.
> Neither of these reasons is very convincing to me; perhaps you can
> elaborate a bit more what distinction you see and why this distinction
> is required.)


Typically 'id' is the definition of something, 'idRef' is used as a 
pointer to something previously defined.  Two quick examples from 
NMC/perfSONAR:

1) Every data has an id field, but also a 'metadataIdRef' which points 
to the 'parent' metadata for that data item.

2) Every 'metadata' in perfSONAR has an id field.  Chaining is performed 
by inserting a 'metadataIdRef' inside of an empty subject, this allows 
us to perform filtering operations on the metadata that is 'referenced'.

Following these examples, I would claim that if some domain defines/owns 
an object, such as a link, they get to assign the 'id' field.  If this 
is a GLIFesq definition I would assume this gives it a global scope.

For any other use that wishes to reference this original, there needs to 
be a clear semantic meaning that we are not trying to define (or 
re-define) the original.  In the case of an end to end path that is 
using several links that belong to others (e.g. the control plane 
world), I am suggesting that if you intend to reference the individual 
components of the entire path, it is necessary to use idRefs instead of 
ids.

Hope this helps.


>> I would make the example as so (again, removing the use of the attribute
>> namespaces since I also feel this is really confusing things):
>>
>> <nml:link id="urn:ogf:network:example.net:pathAC">
>>     <nml:relation type="serialcompound">
>>       <nml:link idRef="urn:ogf:network:example.net:segmentAB"/>
>>     </nml:relation>
>> </nml:link>
>>
>> Lastly the inclusion of the 'type=partial' is still rather foreign to
>> me, so I omitted it.  Can you explain why you need to do this?
>
> In the above I was trying to describe the following information:
> "urn:ogf:network:example.net:segmentAB is a segment of the end-to-end
> link urn:ogf:network:example.net:pathAC, but I don't know the names of
> other segments of this path".
>
> This seems typical information that the domain who provisioned
> urn:ogf:network:example.net:segmentAB might say.
>
> The addition of the word "partial" was trying to emphasis that, but I
> agree that it can be conveyed with other means (such as the lack of a
> "count" attribute in the above, meaning that the list may be incomplete.)


Alright.  I would vote for Aaron's proposal that I listed out in one of 
the first mails (no longer in this tread for some reason) to use pointer 
elements instead of count/type elements.  I believe that respects the 
original hop/path idea a little closer.  If the existing tooling can 
deal with a concept that 'follows' a path, that's a strong argument to 
remain with it even if the syntax changes slightly.

Thanks;

-jason