« Return to Thread: questions on RSpecs from GEC2 meeting
Re: questions on RSpecs from GEC2 meeting
by Jeff Chase
::
Rate this Message:
Aaron Falk wrote:
> I took a few notes on the questions that came up during Ted & Rob's
> talks:
>
> Where is time expressed?
>
> How are duty-cycles expressed?
>
> How are probabilistic constraints expressed?
>
> (something about elemental actuators....?)
>
> c.f. sensorML, ontology for services, network markup languages from
> OGF, resource descriptor framework
>
> How is isolation expressed?
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>
It seems to me that there's a larger core question here that came up
about the role of rspec as a language (format?) for representing
information about resources and slivers in the GENI architecture. How
do we balance the tension between standardization and extensibility?
There are a couple of options that bracket a continuum:
1. Exactly one: Rspec is the standard specification. It can be extended
through various consensus processes defined by GENI governance.
2. At least one: Rspec is an initial standard for representing some
information, but there may be other alternatives for representing other
information. If the various actors (component manager, clearinghouse,
researcher tools) understand some other language, then they can
negotiate for resources using that language instead of or in addition to
Rspec.
Strategy #1 has several risks. It means we have to invest a lot in
trying to agree on an specification for what GENI actors say to other
actors about resources and slivers, and their topology and
capabilities. What does it mean for Rspec to be "extensible"? Can it
incorporate information represented in NDL, or DCML, or sensorML, or
various other languages that other related communities might use? Or
will we build "our" own language, borrowing from these "other"
communities as we see fit? Can the Rspec standard evolve quickly enough
to avoid being a barrier to innovation?
The risk of strategy #2 is that we later degenerate into a jello-nailing
exercise of some sort. But I hope we can keep GENI open enough to
encompass multiple ways of talking about resources, just as the Web has
multiple formats for representing content. If we can do that, then we
will have a more evolvable result and better inclusion of other groups
who have thought hard about these problems for a long time (e.g.,
http://www.science.uva.nl/research/sne/ndl). We should at least ask the
question of whether we can get where we want to go in some other way,
e.g., by extending NDL.
Jeff
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
> I took a few notes on the questions that came up during Ted & Rob's
> talks:
>
> Where is time expressed?
>
> How are duty-cycles expressed?
>
> How are probabilistic constraints expressed?
>
> (something about elemental actuators....?)
>
> c.f. sensorML, ontology for services, network markup languages from
> OGF, resource descriptor framework
>
> How is isolation expressed?
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg
>
It seems to me that there's a larger core question here that came up
about the role of rspec as a language (format?) for representing
information about resources and slivers in the GENI architecture. How
do we balance the tension between standardization and extensibility?
There are a couple of options that bracket a continuum:
1. Exactly one: Rspec is the standard specification. It can be extended
through various consensus processes defined by GENI governance.
2. At least one: Rspec is an initial standard for representing some
information, but there may be other alternatives for representing other
information. If the various actors (component manager, clearinghouse,
researcher tools) understand some other language, then they can
negotiate for resources using that language instead of or in addition to
Rspec.
Strategy #1 has several risks. It means we have to invest a lot in
trying to agree on an specification for what GENI actors say to other
actors about resources and slivers, and their topology and
capabilities. What does it mean for Rspec to be "extensible"? Can it
incorporate information represented in NDL, or DCML, or sensorML, or
various other languages that other related communities might use? Or
will we build "our" own language, borrowing from these "other"
communities as we see fit? Can the Rspec standard evolve quickly enough
to avoid being a barrier to innovation?
The risk of strategy #2 is that we later degenerate into a jello-nailing
exercise of some sort. But I hope we can keep GENI open enough to
encompass multiple ways of talking about resources, just as the Web has
multiple formats for representing content. If we can do that, then we
will have a more evolvable result and better inclusion of other groups
who have thought hard about these problems for a long time (e.g.,
http://www.science.uva.nl/research/sne/ndl). We should at least ask the
question of whether we can get where we want to go in some other way,
e.g., by extending NDL.
Jeff
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: questions on RSpecs from GEC2 meeting
| Free embeddable forum powered by Nabble | Forum Help |
