Moved to: https://redmine.ogf.org/issues/51

I propose to let the outcome of artf6583 decide if this is allowed (I think it is) and close this artifact as accepted.

I have not objections to this proposal, but I do not understand see a use case (unless this is to allow a distinction between authoritative and non-
authoritative statements, see artf6555), however I see a problem with RDF in that case (again, see artf6555).

The only question for this proposal I have is #5 bellow:

5. Would it be able to freely combine these things, as in the following:

Relate two objects with authority:
<nml:Link id="urn:ogf:network:client.net:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port id="urn:ogf:network:client.net:2012:LinkA"/>
  </nml:Relation>
</nml:Link>

Relate two objects without authority:
<nml:Link idRef="urn:ogf:network:provider.com:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port idRef="urn:ogf:network:provider.com:2012:LinkA"/>
  </nml:Relation>
</nml:Link>

> The use case seems "How can a client signify that it is not authoritative for a given Network Object, but still make claims about it" (e.g. "I think
 
> that my Port A is the source of Link A, which belong to someone else")
> 
> The proposal (although not actually mentioned in the text) is to add the following meaning to the use of the "id" attribute: A client that describes
 a
>  Network Object with an id (as opposed to an idRef) implies that that client is authoritative for this Network Object.

Authority was not meant to be part of this example. This was not stated explicitly, and perhaps it should have been. Trust and Authority is in my eyes
 not something we can solve in NML 1.0, if at all within the scope of NML.
Adding a line with an "authorative" meaning to a description is misleading, there is no way to check the validity of such a statement. If we want to 
discuss trust and authority, we should do that in a different artifact. I would like to keep this one with the original proposal of inverse relations.


The issue here is how to deal with descriptions of objects distributed over different files, or even places within files.
The original examples show two different ways of doing this. I'm sorry to have caused confusion, I should have provided a bit more context and 
explanation for both problems. Let me try to explain it more clearly:

As far as I know we have never looked at the use-case of allowing descriptions in multiple places before, and have never discussed the use of idRef's 
as "subject"[0] of relations at all. I was not sure whether it was allowed to use an "idRef" as subject in an XML description. The first example shows
 allowing that construct.

The second example introduces the idea of defining inverse relations. This is one example, and we would indeed have to define inverse names of all 
other relations as well.
I'm not sure how this would work with Groups, we can either disallow this altogether (cleaner), or add the explicit group contruct.

There are no RDF examples here, because in RDF this is not an issue, the first "idRef" example is allowed by default.


Given the feedback so far, and the possible problems I see now of introducing the inverse relations, I proposed that we only go with the first example
.

[0]: I'm using the RDF (subject, predicate, object) interpretation of "subject" here.

Sorry, it's 4 AM here (well, 6:30 AM now), and can't sleep trying to spin my head around this problem.

Let me try to rephrase the problem and proposed solution, and than give some critics.

The use case seems "How can a client signify that it is not authoritative for a given Network Object, but still make claims about it" (e.g. "I think 
that my Port A is the source of Link A, which belong to someone else")

The proposal (although not actually mentioned in the text) is to add the following meaning to the use of the "id" attribute: A client that describes a
 Network Object with an id (as opposed to an idRef) implies that that client is authoritative for this Network Object.
 E.g.
 <nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
means that the client is authoritative for urn:ogf:network:client.net:2012:PortA.
 while e.g.
 <nml:Port id="urn:ogf:network:provider.com:2012:LinkA"/>
means that the client is not authoritative for urn:ogf:network:provider.com:2012:LinkA.


And this artifact proposes two solutions.

Solution 1 seems to take the existing id/idRef and change the meaning from a syntactic pointer construct (idRef being the pointer, and id the thing 
that is pointed to) to a semantic meaning (id means "I'm authoritative for this object"; idRef means "I'm not authoritative for this object")

So in the example, the idRef is used in the parent XML element, and the id is used in the child XML element, the opposite of what is used now.

Solution 2 seems to require that for every relation R, NML must define an inverse relation R', AND also add a meaning to a relation statement A --(R)-
-> B: "I'm authoritative for the source object A of the relation statement".


Is that a correct analysis of the problem and proposals?


My complaints are:

1. My first complaint is that the given example does not make sense. artf6550 clearly state that the isSource relation is from Port to Link. Yet this 
examples does it the other way around. I presume the example should have been:

Current:
<nml:Link id="urn:ogf:network:provider.com:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port idRef="urn:ogf:network:client.net:2012:LinkA"/>
  </nml:Relation>
</nml:Link>
(no implications on authority)

Proposal 1:
<nml:Link idRef="urn:ogf:network:provider.com:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port id="urn:ogf:network:client.net:2012:LinkA"/>
  </nml:Relation>
</nml:Link>
(Use of id implies that the client is authoritative for LinkA)

Proposal 2:
<nml:Port id="urn:ogf:network:client.net:2012:LinkA"/>
  <nml:Relation type="hasSource">
    <nml:Link idRef="urn:ogf:network:provider.com:2012:PortA">
  </nml:Relation>
</nml:Link>
(Use of id implies that the client is authoritative for LinkA)


2. The REAL proposal seems:
   Proposal 1: The use of an id implies that the client is authoritative for the given Network Object. The use of an idRef does not imply anything.
or:
   Proposal 2: The use of an id implies that the client is authoritative for the given Network Object. The use of an idRef implies that the client is 
NOT authoritative for the given Network Object.

But this is never mentioned; instead the two listed examples only focus on a consequence of the above change, which is that it is yet not possible for
 a client give a Port A --(isSource)--> Link A relation, while using an id instead of an idRef for Link A (which is a problem if the client happens to
 be authoritative for Link A, but not for Port A). The current proposal subsequently introduces two solutions for this derived problem.

I would have expected this artifact to mention the original proposal, the problem that is raised, and state that the two listed proposals are not 
really the proposal, but merely solutions to a derived problem that is raised by introducing the original proposal.


3. The proposals do not contain RDF, which I think is crucial, as the whole proposal is about adding semantics to id and idRef, but RDF does not use 
id and idRef. Hence, I'm curious if this proposal does work in RDF.

Let's give it a shot.

Current:
urn:ogf:network:provider.com:2012:PortA a nml:Port .
urn:ogf:network:provider.com:2012:PortA nml:isSource urn:ogf:network:client.net:2012:LinkA . 
(no implications on authority)

Proposal 1:
urn:ogf:network:provider.com:2012:PortA a nml:Port .
urn:ogf:network:provider.com:2012:PortA nml:isSource urn:ogf:network:client.net:2012:LinkA . 
urn:ogf:network:client.net:2012:LinkA a nml:Link .

Proposal 2:
urn:ogf:network:client.net:2012:LinkA a nml:Link .
urn:ogf:network:client.net:2012:LinkA nml:isSource urn:ogf:network:provider.com:2012:PortA .
urn:ogf:network:provider.com:2012:PortA a nml:Port .

3a. It is unclear to me how to assert authority in proposals 1.
Jeroen, you wrote that "this is how RDF works anyway". Could you please explain?

3b. I more or less presume that the intend of proposal 2 is to say that "The client is authoritative for any Network Object that is the subject of a 
RDF triplet". Jeroen, could you confirm?


4. If indeed, the intended proposal 2 for RDF boils down to "The client is authoritative for any Network Object that is the subject of a RDF triplet",
 then the following example is wrong:
 urn:ogf:network:client.net:2012:LinkA a nml:Link .
 urn:ogf:network:client.net:2012:LinkA nml:isSource urn:ogf:network:provider.com:2012:PortA .
 urn:ogf:network:provider.com:2012:PortA a nml:Port .
and the last line must be removed:
 urn:ogf:network:client.net:2012:LinkA a nml:Link .
 urn:ogf:network:client.net:2012:LinkA nml:isSource urn:ogf:network:provider.com:2012:PortA .
This is a change in RDF, and it is no longer possible to explicitly list the type of a referred Network Object.


5. Proposal 1 allows idRef in the parent XML element of a Relation, and id in the child XML element of a Relation. Would it be able to freely combine 
these things, as in the following:

Relate two objects with authority:
<nml:Link id="urn:ogf:network:client.net:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port id="urn:ogf:network:client.net:2012:LinkA"/>
  </nml:Relation>
</nml:Link>

Relate two objects without authority:
<nml:Link idRef="urn:ogf:network:provider.com:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Port idRef="urn:ogf:network:provider.com:2012:LinkA"/>
  </nml:Relation>
</nml:Link>


6. Proposal 2 allows inverse relations. Are A --(R)--> B and B --(R')--> A (with R' the inverse relation of R) exactly equivalent? If they are 
equivalent, can they be used interchangably, or are there some additional rules when they should or should not be used?

For example, the inverse relation of <nml:Relation type="next"> is <nml:Relation type="previous">. This was voted down at OGF 32, but I presume that 
this proposal reverts that decision.

For example, would the following be allowed?

<nml:Link id="urn:ogf:network:example.net:2012:linkZ">
  <nml:Relation type="isSerialCompoundLink">
    <!-- this is a list -->
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkA"/>
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
      <nml:Relation type="previous">
        <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
      </nml:Relation>
      <nml:Relation type="next">
        <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
      </nml:Relation>
    </nml:Link>
    <nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  </nml:Relation>
</nml:Link>

If this is not allowed, why not, and what are the exact rules why this is not allowed, while e.g. hasSource can be used.


7. Currently some relations are one-to-many, such as the above isSerialCompoundLink. How should the inverse relation be written in XML?

<nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
  <nml:Relation type="next">
    <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
  </nml:Relation>
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
  <nml:Relation type="next">
    <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
  </nml:Relation>
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  <nml:Relation type="partofSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:Link>

Or should there be some grouping around the list?
(which is in fact what Jeroen suggested at OGF32, but was voted down at that time)

<nml:List>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
    <nml:Relation type="next">
      <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
    </nml:Relation>
  </nml:List>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
    <nml:Relation type="next">
      <nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
    </nml:Relation>
  </nml:Link>
  <nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
  <nml:Relation type="isSerialCompoundLink">
    <nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
  </nml:Relation>
</nml:List>




Sorry to sound harsh, but this proposal almost reads like a text book example why it is bad practise to overload existing constructs to add new 
meaning. In this case, the existing construct was id/idRef as pointers and the added meaning is "id means authority". We immediately open a can of 
worms. In fact, the original proposal already contains two further proposals just to solve this problem. Proposals for which I have doubts that it 
will work in RDF.

Why don't we simply add a new construct to solve this problem? E.g. something along the lines of

XML:
 <nml:Port idRef="urn:ogf:network:client.net:2012:PortA"/>
   <nml:authoritative />
 </nml:Port>

RDF:
 urn:ogf:network:client.net:2012:PortA  nml:authoritative  True .


Beside of this solution, I am happy to discuss further proposals that introduce reverse relations, although I think that is an entirely different 
issue, and hence MUST go in a different artifact. I would encourage people to write such a proposal, but I would ask of such proposal to explain how 
to solve issues such as #6 and #7 listed above.

Unless there are objections, I propose to close this artifact as is mixes up two completely different issues: "Allowing inverse relations" and "
Authoritative description of Network Objects versus non-authoritative descriptions of Network Objects". I'm happy to open two new artifacts, with 
status "Waiting for proposal" and open for any volunteer to pick up.

I don't understand your objection, the original object can be described elsewhere and referenced.  

The bottom line is that there is a very valid use case for this, therefore we need to support both.  

Since this is the inverse if the hierarchy that was discussed in the other thread, my understanding is that both are allowed.  E.g. port -> Link is 
the natural way, and Link -> port would be the opposite.  

Am I missing something?

These should be allowed.