Re: [Nml-wg] References

W dniu 2012-09-21 13:08, Jeroen van der Ham pisze:

Hi,

I actually meant it more like the following:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://example.com/topology-description.xml </Port>

Right. This is an example when the xml file with definitions and its location is known. Roman

Jeroen.

On 21 Sep 2012, at 11:42, Roman Łapacz wrote:

...

I decided to visualize the proposed change using an example:

IdRef:

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </Port>

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

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> http://schemas.ogf.org/nml/2012/10/type/unknown"/> </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:

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

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.

http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy"> </Port>

http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501 http://schemas.ogf.org/nml/2012/10/relation/isSource"> </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