Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz <romradz@man.poznan.pl> wrote:

I decided to visualize the proposed change using an example:

IdRef:

<nml:Port id="urn:ogf:network:example.net:2012:port-X:out">

<nml:Label encoding="http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501</nml:Label>

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSource">

<nml:Link idRef="urn:ogf:network:example.net:2012:linkA:XY"/>

</nml:Relation>

</Port>

transformed to use isDefinedBy (the way how I see it):

<nml:Port id="urn:ogf:network:example.net:2012:port-X:out">

<nml:Label encoding="http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501</nml:Label>

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSource">

<nml:Link id="urn:ogf:network:example.net:2012:linkA:XY">

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

<nml:NetworkObject type="http://schemas.ogf.org/nml/2012/10/type/unknown"/>

</nml:Relation>

</nml:Link>

</nml:Relation>

</Port>

I've introduced a new abstract element nml:NetworkObject that is useful to indicate that the definition is somewhere but does not have to be specified in this xml doc. I don't think we can assume that we must know it in advance. For example, definitions may be located dynamically in some lookup repositories (perfSONAR services does not have to upload their metadata information only to one LS service all the time). Thus definition location may be found by some lookup mechanism.

I'm fine to use Topology inside Relation if this relation is known:

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

<nml:Topology id="urn:ogf:network:gn3.net:2012:org"/>

</nml:Relation>

The use of Relation for referencing may be useful also for name/id mapping (an id points another id). I'm not sure this may be useful for someone but I can imagine a use case where names of network elements are assigned with a project (see below: pionier network element used in the GN3 project). Such mapping may be helpful for flexible lookup operations.

<nml:Port id="urn:ogf:network:gn3.net:2012:port-X:out">

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

<nml:Port id="urn:ogf:network:pionier.net:2012:port-X:out"/>

</nml:Relation>

</Port>

<nml:Port id="urn:ogf:network:pionier.net:2012:port-X:out">

<nml:Label encoding="http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501</nml:Label>

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSource">

<nml:Link idRef="urn:ogf:network:pionier.net:2012:linkA:XY"/>

</nml:Relation>

</Port>

Roman

W dniu 2012-09-21 09:50, Jerry Sobieski pisze:

If I understand this correctly, and if I also understand the usage context with regard to "topologies", I vote for the isDefinedBy construct as we will be looking to acquire what is likely to be a substantial amount of topology information that is maintained in a separate document somewhere.

And I would salute the desire to keep multiple representations as similar as possible.

(just letting you know I am following these discussions:-)

J

On 9/20/12 8:44 PM, Freek Dijkstra wrote:

On 20-09-2012 17:13, Jeroen van der Ham wrote:

Hi,

We've been discussing references, meaning things that are not defined

locally, but you do want to provide additional information about

them. For XML there has been a proposal to use id / idRef to denote

something like that. Unfortunately it is not very easy to port that

construct to RDF/OWL. The only way to express something like that in

RDF/OWL is by using a relation. Fortunately a relation like that

already exists in the form of rdfs:isDefinedBy. This states that an

object is actually defined by another description, and conveniently

provides the URL of that description to reference it.

Could we perhaps use the isDefinedBy construct also in XML to make

the reference definition somewhat more explicit? This would really

help keeping the difference between the two syntaxes at a minimum

also.

A summary of the earlier discussion:

idRef is suppossed to be a shortcut for id + isReference True.

isReference is supposed to mean that the object was defined elsewhere,

like in another document/by another organisation (there was still a

discussion between Aaron and myself if 'elsewhere' may or may not

included 'elsewhere in the file --- thinking about it now, I would say

'in another Topology').

The distinction between isReference and isDefinedBy is that isReference

only tells the parser that it is defined elsewhere; isDefinedBy also

tells the parser where it is defined.

I have no preference. Based on Jeroen's proposal and the earlier

discussion, what it most useful?

Freek

_______________________________________________

nml-wg mailing list

nml-wg@ogf.org

https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________

nml-wg mailing list

nml-wg@ogf.org

https://www.ogf.org/mailman/listinfo/nml-wg

_______________________________________________

nml-wg mailing list

nml-wg@ogf.org

https://www.ogf.org/mailman/listinfo/nml-wg

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