| |
Comment: |
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.
|
