[Nml-wg] References

[Jason Zurawski]

Howdy All;

Jeroen threatened me with physical harm if I didn't weigh in on this :)

I believe that the concept of "additive" relationships with IDs carries *only* within the same scope of use.  E.g.:

<id = a>
  <!-- some things -->
</id>

and 

<id = a>
  <!-- some more things -->
</id>

Works if these appear in the same physical document and defn scope.  After that, I would say it is not allowed and we must go with references.  

Thanks;

-jason

On Oct 8, 2012, at 12:06 PM, Roman Łapacz <romradz at man.poznan.pl> wrote:

> W dniu 2012-10-05 17:56, Aaron Brown pisze:
>> 
>> On Oct 5, 2012, at 10:06 AM, Jeroen van der Ham wrote:
>> 
>>> Yes indeed.
>>> Freek is now out of the running, so it is up to us to finalize things and close this issue.
>>> 
>>> Summarizing:
>>> - "isReference <URL>" solution is off the table, this is a control-plane construct, I'm proposing to move this to NSI topology constructs, so this will be an NSI issue.
>>> - id/idRef solution seems to boil down to extra parser logic, i.e. whether or not an id is defined in some place or not.
>>> 
>>> For the RDF/OWL syntax this is a non-issue, because statements about objects can be made everywhere.
>>> In my opinion this should also hold true for the XML syntax. You can not stop me from stating properties of a certain object, therefore, you can not state that a certain definition is only in one place.
>>> 
>>> Also, how do we enforce the id / idRef construct? What to do when you encounter an id statement in two different places?
>> 
>> So the logic you are proposing is that the "canonical" definition of network element A is the union of all definitions of A? e.g.
>> 
>> <topology>
>>   <relation type="hasNode">
>>     <node id=A>
>>       # canonical definition
>>     </node>
>>   </relation>
>> </topology>
>> 
>> <port X>
>>   <relation type="inNode">
>>     <node id=A>
>>       # some added properties from X's perspective about A
>>     </node>
>>   </relation>
>> </port>
>> 
>> <port Y>
>>   <relation type="inNode">
>>     <node id=A>
>>       # some added properties from Y's perspective about A
>>     </node>
>>   </relation>
>> </port>
>> 
>> Would be semantically equivalent to:
>> 
>> <topology>
>>   <relation type="hasNode">
>>     <node id=A />
>>   </relation>
>> </topology>
>> 
>> <port X>
>>   <relation type="inNode">
>>     <node id=A />
>>   </relation>
>> </port>
>> 
>> <port Y>
>>   <relation type="inNode">
>>     <node id=A />
>>   </relation>
>> </port>
>> 
>> <node id=A>
>>       # canonical definition
>>       # some added properties from X's perspective about A
>>       # some added properties from Y's perspective about A
>> </node>
>> 
>> 
>> Using that logic, are there any circumstances where there might be conflicting information in the various "definitions" of A? e.g. if X's "description" attribute for A is different than Y's "description" for A which is different from the topology's "description" attribute for A (e.g. a domain defines topology, along with some VO elements, and the VO uses their "external" description of an interface vs. the "internal" description that the domain itself uses). In that scenario, there are different "description" attributes for A.
> 
> If I remember correctly Jerry presented similar scenario for Nordunett topology (two internal topologies/domains) where the alias relation (a kind of mapping) was used. Internal ids and topology elements were not available externally.
> 
> Roman
>   
>> 
>> Before there was a "scoping" of attributes. e.g. it was X's view of A, not a canonical definition of A. For things like the list relations, the 'next' and 'prev' attributes of a network element were scoped inside the group. Now, they're global which means if an element is a member of multiple lists, those relationships are ambiguous.
>> 
>> I'm not sure any of that is needed even if we get rid of idRef. If we special-case 1 relationship type "definedBy", I think we can get rid of essentially all the ambiguity.
>> 
>> Rule 1: If there are 2 network elements with the same id attribute in a given document, the behavior is undefined
>> Rule 1a: The exception to the above is if a network element is defined in a "definedBy" relationship, in that case, the id attribute of the relationship is a pointer to a network element with that id defined elsewhere.
>> 
>> We'd make use of anonymous network elements inside of relationships:
>> 
>> <relation type="hasPort">
>>   <port>
>>     <relation type="definedBy">
>>       <port id="XYZ" />
>>     </relation>
>>   </port>
>> </relation>
>> 
>> The above syntax was shortened using the idRef to:
>> 
>> <relation type="hasPort">
>>   <port idRef="XYZ" />
>> </relation>
>> 
>> To me, these semantics are logical, and allow scoping properties about a network element.
>> 
>> Cheers,
>> Aaron
>> 
>>> 
>>> Jeroen.
>>> 
>>> 
>>> 
>>> On 5 Oct 2012, at 12:12, Roman Łapacz <romradz at man.poznan.pl> wrote:
>>> 
>>>> 
>>>> Correct me if I'm wrong but I think that the references issue could be the last major one to solve and announce the first stable official version of NML. Other issues could be discussed afterwards and belong to the next version (I remember that October has been a deadline).
>>>> 
>>>> Roman
>>>> 
>>>> 
>>>> W dniu 2012-09-20 17:13, Jeroen van der Ham pisze:
>>>>> Hi,
>>>>> 
>>>>> We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL.
>>>>> The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it.
>>>>> 
>>>>> Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also.
>>>>> 
>>>>> Jeroen.