This is fine by me in its current state

Fine by me.

I say that it should be deprecated, meaning:

parsers MUST accept the implicit relation
parsers SHOULD NOT accept the explicit relation

clients SHOULD write using the implicit relation.

Meaning that if you really really want to, you can use the explicit relation, but you're not guaranteed to have support in all parsers.

I agree with Jason on 1b.

Just for clarification: do we need to write that a client that creates NML SHOULD use implicit relations for these two, and that a client that parses 
NML MUST be able to accept both syntaxes?

yes, I meant in XML. Sorry for the confusion.

Here is the full proposal with one open issue:


Implicit relations
==================

> * implicit hasTopology relation between Topology and (sub)topology
>   https://forge.ogf.org/sf/go/artf6537
>   https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/hasTopology.xml
>   (proposal #2 and optional #1)
> 
> * implicit hasNode relation between Topology and Node
>   (no artifact created)
>   https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/hasNode.xml
>   (proposal #1 and optional #3)

Summary: We need to relate Topology with a Node (meaning that the topology contains a Node), and related a Topology with a Topology (meaning that the 
topology contains a subtopology).

Proposal: In XML, we allow (1) implicit relations; in RDF it is required to use an explicit relation.

Example:

XML:
<nml:Topology id="urn:ofg:network:example.net:2012:mynetwork">
  <nml:Node id="urn:ofg:network:example.net:2012:mynode1">
    ...
  </nml:Node>

  <nml:Topology id="urn:ofg:network:example.net:2012:location1network">
    ...
  </nml:Topology>
</nml:Topology>

RDF:
@prefix exnet <urn:ofg:network:example.net:2012> .
exnet:mynetwork  nml:hasNode      exnet:mynode1
exnet:mynetwork  nml:hasTopology  exnet:location1network


Open question (1):
It is unclear if in RDF, the relation MUST be implicit, or MAY be implicit.

Thus: it is clear that the above is allowed. But it is unclear if the following if also allowed or explicitly forbidden:

<nml:Topology id="urn:ofg:network:example.net:2012:mynetwork">
  <nml:Relation type="hasNode">
    <nml:Node id="urn:ofg:network:example.net:2012:mynode1">
      ...
    </nml:Node>
  </nml:Relation>
  
  <nml:Relation type="hasNode">
    <nml:Topology id="urn:ofg:network:example.net:2012:location1netw">
     ...
    </nml:Topology>
  </nml:Relation>
</nml:Topology>

Choices:
1a) Explicit hasNode and hasTopology relation is forbidden in NML
1b) Explicit hasNode and hasTopology relation is allowed in NML, 
    but deprecated in favour of an implicit relation.

Since I remember arguing this already (and don't want to do it again) here are my comments from the email thread of a couple of weeks ago:

Jason:

>>    - Some things have an explicit parent/child relationship already (e.g.
>> we know a topology contains nodes, ports, links).  Using a relationship
>> to say 'hasNodes' or something similar is redundant, we know they are
>> involved with the topology due to the nature of the schema.

Freek:

> Agreed that it is not necessary. I did it for consistency. E.g. if
> Topology ->  Topology, Node ->  Port, Node ->  Service are all explicit
> (hasTopology, hasPort/hasOutboundPort, hasService), it makes sense to
> also use hasNode. Or we define some others redundant too. (e.g. a
> Service in a Node always implies hasService, a Topology in a Topology
> always implies a hasTopology, etc.)

Jason:

This really bashes the argument of needing a well defined schema though.  If everything is related to other things via relationships (and we never use
 the explicit parent/child), we end up with this:

 - Node, Port, Topology, Link, etc. etc. don't contain anything except relationships

 - Relationships allow 'any element' to be inside

 - 'Rules' are all semantic for each relationship type

 - schematic checking is useless

Wasn't it you who argued a couple of months ago that we need well defined schema so that we know what each element can/may contain :) ?

I agree with your line of reasoning that is hast to be consistent in our use of parent/child vs relationships, and this was a minor mistake on my 
examples from Sept as I read them now.

At least in my mind, I would *like* to interpretation the relationship for logical or fuzzy concepts:

 - Serial compound pushes together two links

 - two ports are pushed together into a bidirectional

 - a switching service has inbound and outbound ports associated with it

 - a link needs to describe the in vs out ports

I would claim that we don't need these in a relation, and this may force some example changes:

 - a switch won't need 'hasports' by itself sine we know the switch has the ports via parent/child.

 - A switch can have 'hasinbound' or 'hasoutbound' port relations, as this adds more value

 - A topology with 'hasnodes' doesn't seem necessary, we know it has nodes (and ports and links).

 - A node with 'providesService', the service could be a direct parent/child (unless its special maybe, I dont have a good use case)

I could be wrong of course, but this seems to make sense as I type it. We should try to use explicit things when we can. 

If topology currently allows another topology to be a direct child, I see no reason to use a relation.  If this isn't a allowed, a relation (
hasTopology) is fine by me

When one topology is contained within the other, the default implicit relation is hasTopology:

<nml:Topology id="a">
  <nml:Topology id="a:b"/>
</nml:Topology>

When one topology is contained within the other, the default implicit relation is hasTopology:

<nml:Topology id="a">
  <nml:Topology id="a:b"/>
</nml:Topology>

See: https://forge.ogf.org/integration/viewcvs/viewcvs.cgi/*checkout*/201203-subTopology/hasTopology.xml?rev=20&content-
type=text%2Fplain&system=exsy1001&root=nml-examples