[Nml-wg] References

Mon Oct 8 13:06:22 EDT 2012

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 
>> <mailto: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.
>>>>
>>>> _______________________________________________
>>>> nml-wg mailing list
>>>> nml-wg at ogf.org <mailto:nml-wg at ogf.org>
>>>> https://www.ogf.org/mailman/listinfo/nml-wg
>>>
>>> _______________________________________________
>>> nml-wg mailing list
>>> nml-wg at ogf.org <mailto:nml-wg at ogf.org>
>>> https://www.ogf.org/mailman/listinfo/nml-wg
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org <mailto:nml-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nml-wg
>
> Internet2 Fall Member Meeting
> Sep 30-Oct 4, 2012 - Philadelphia, PA
> http://events.internet2.edu/2012/fall-mm/
>

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