[Nml-wg] Multiple namespaces

[Jason Zurawski]

Hi Freek;

I do not wish to contribute to another out-of-sync email storm today by 
replying to two threads at the same time.  I believe that everything you 
are discussing below is covered in a prior mail, so lets not re-hash it.

We are doing a lot of talking, but not a lot of implementing.  If we are 
to advance this conversation beyond the current state, there needs to be 
examples constructed that show why you think the current proposals on 
the table for NML are insufficient, and how you would alter them to get 
the exact functionality/look you think is required.

Thanks;

-jason

On 8/23/11 5:47 AM, thus spake Freek Dijkstra:
> Jason Zurawski wrote:
>
>>> The above leads to three scenario's in mind where it may be prudent to
>>> mix namespaces in a single message:
>>> - core topology with technology specific (Ethernet, IP, ..) namespaces.
>>> This is probably the weakest use case, as it is possible to add the core
>>> topology concepts to each technology specific namespace (e.g. using
>>> chameleon namespaces)
>>> - topology namespace with geo namespace
>>> - topology namespace with an application-specific namespaces (eg.
>>> topology + NSI for path finding, or topology + NMC for monitoring).
>>
>> You describe all of the things that I (and others in SLC) were arguing
>> for all along - the ability to extend the base ideas concepts into new
>> use cases through the use of namespace extensions.  I will make one
>> quibble on the above - I would argue its important to make the 'base'
>> set minimal, e.g. 'ethernet', 'ip', etc. are not *in* the base, these
>> are extensions *of* the base.
>
> I think we are in agreement with these points from the start.
>
> What I'm not sure we agree upon is how to implement this.
> The way this is done in NMC (using chameleon namespaces) is certainly
> not the only way to accomplish this.
>
> On top of my head, I can think of the following design patterns that
> accomplish the same thing:
> * Base + extensions
>    * Object composition
>      * Instances can be instance-of multiple classes
>    * Subclassing
>      * Pointer to base class in schema description
>        * Chameleon namespaces
>      * Pointer to base class in messages itself
>
> For example, in NDL we first played with a method where the
> technology-specific schema were INSTANCES of the base schema, thus not a
> SUBCLASS of the base schema, and network resources has-a property
> consisting of one of these technology-specific instances (we could do
> this, because in RDF, a Resource can be a Class and an Instance at the
> same time). Later, we settled on a method where network resources where
> INSTANCES of two distinct classes: both an instance of a base class (eg.
> rdf:type ndl:Interface) as well as an instance of a technology-specific
> class (e.g. rdf:type wdm:FiberNetworkElement). (In RDF, a Resource can
> be a instance of multiple classes, kind of like the Object composition
> design pattern).
>
> My gut feeling is that Subclasses is a very common method, so I'm
> inclined to use that for NML. However, since Chameleon namespaces are
> uncommon, I would rather settle for a more common design pattern.
>
>
> Now, a problem may be that we're lacking a real ontology designer. We're
> all network experts here. It seems we have know how to make ontologies
> (me and Jeroen in RDF, you and Roman in XML), and have found a few
> things that worked well for us. However, I known I'm not well versed
> with all the ins and outs of all ontology design concepts (franky, I had
> to Google the names of a few of the above design pattern, and fear I
> still have it wrong, so I resorted to use my own wording).
>
> I'm a bit at loss right now what the best way forward is -- we seem to
> argue a great deal about the syntax, not about the underlying network
> concepts. Unfortunately, it does matter, since the choices we make in
> syntax have consequences for e.g. the extensibility. Would it help to
> more clearly describe our requirements? E.g. what kind of extensibility
> we want (e.g. make a backward- or forward-compatible version 2 of the
> base later; add more technologies without touching the base schema; add
> more relation with or without touching the base schema; mix with other
> schemata, ...)
>
> Regards,
> Freek