Thanks Jerry. When I took a look at the example Jeroen sent I thought that it would be difficult to analyse it. Too much information, especially for me who was not involved in the NSI discussion. That is why I asked for a tool to see the whole picture in a simple way. But today I analysed the PIONIER part in that file and I think I understand (other sections only repeat constructions with content relevant to other domains).

Cheers,
Roman

W dniu 2012-02-14 14:35, Jerry Sobieski pisze:
Hi Roman  and everyone-

The topology that Jeroen distributed was the topo used last fall for our NSI demos.   And we did use the UvA SNE editor to initially create that topology.   And that version of the topo should still be compatible with SNE.  

But the graphical representation created by SNE is not automatic - it is manually created by the individual building the topology...   Attached is the diagram we used for public consumption last fall.   A more useful approach (IMO) to learn NSI or to understand the AutoGOLE fabric than the SNE graphical display of this topology would be to look at any one NSI Network - say Netherlight.ets - in the diagram, and study its components in the OWL topology file to learn those relations to NSAs, STPs, location info, etc.   Once you understand the set of topological relations to one particular network, the other networks in the overall topology are simply repeated themes.   This high level top down approach to understanding the topology is much more effective than the SNE graphics IMO.  Indeed, I had to manually edit the SNE graphical layout (manually computing the coordinates of each object) in order to get a meaningful graphical display from the topology.  The SNE editor is a very basic tool.   And certain necessary topological relations cause graphical diagrams to get complex and busy very quickly.    So, the prospect of graphically editing any but the simplest topologies requires a rather inteligent editing tool that understands and uses the network semantics - not just RDF relations - to develop the graphical representation and manipulation interactions.

As the topology continues to get more complex it has become unwieldy to use the SNE editor in its current form to work on it.  So the topo releases we are moving to this spring are not built using SNE.   The rest of the OWL topology representation is the same, and I am pretty sure SNE can still be used to process it, but these other semantic/graphical issues make the SNE tool less useful than it might be for building more complex network topologies.  NOTE:  SNE is the only tool I know that understand the OWL data format and so I believe it might be more useful for representing RDF semantic relations rather than building network topologies per se...so don't take this critique of SNE as a swipe at it...we just need a tool more aimed at network service architectures than semantic web applications.   I always think of CASE/CAE tools, or an object oriented approach, as a potentially more effective GUI model.

We *do* need some sort of graphical editor for managing large scale topological information, but we need some editing features that are not currently available in SNE (or any other similar topology tool AFAIK).  These would include graphical sumarization and layering (not just hardware, but service layering, control plane layers, etc.), auto-routing/placement that "makes sense" within the semantic context of the objects and that minimizes visual clutter, color coding would be useful, groupings and graphical object editing ala Powerpoint or the like, etc.   These are largely human-interface/presentation issues, some graphical bugs resolved, etc., but nevertheless these features are why we want graphical editors for this task, and these would make graphical management of topologies much more intuitive and efficient - and thus used.

I would suggest that if you are starting out to create a basic topology from scratch, the SNE editor is very good place to begin.  It works fine for a basic not-too-complex topology and generates an OWL file with all the headers required for this data representation form.  You can learn a fair bit about NSI by building some simple topologies using SNE.   And then you can study the resulting OWL output and extend the topology using SNE or other conventional editing tools or auto-generating scripts to generate larger more complex OWL based topologies.   And I think you can still feed those auto-generated topologies into SNE for a rough validation.   (There may be other ways to validate an OWL topology file I am not aware of...Jeroen?  Any thoughts on this?)

Just some observations...
Jerry

On 2/13/12 12:21 PM, Jeroen van der Ham wrote:
Hi,

On 13 Feb 2012, at 16:32, Roman Łapacz wrote:
if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?
The Automated GOLE demo uses a similar editor available for the NML editor.
The Automated GOLE editor is available at: http://auto-gole.appspot.com

(The NML editor is available at http://nml-editor.appspot.com)

Jeroen.


_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg