On 01/31/2014 02:57 PM, Greg Bernstein wrote:
I'd like to see what the thoughts are of you (and the working group)
on whether we end up using an existing format (and how that will
actually work with respect to the copyright holders, if any, of the
existing format) or do we come up with a new one?
--> NetworkX originated with a government research project is is open
sourced under BSD
(http://networkx.github.io/documentation/latest/overview.html#free-software).
Hard to exactly say what the Tinkerpop open source license is
(https://github.com/tinkerpop/blueprints). However, neither of these is
formally defined at a sufficient level for standardization purposes,
i.e., not even close to the JSON standardized in the current ALTO spec.
As Michael pointed out the structure of a graph in JSON via node lists
and link lists with properties is a fairly generic notion. We'd need to
formalize it for interoperability sake. Note also that representing
paths as a list of links (link-path representation) is also fairly generic.
Greg: Good, what you write above appears to be a tractable and a
close-ended problem.
More inline.
Regarding the second sub-issue on the need for reductionist algebra for
graph transformations, I agree with you [1] that we leave that up to the
ALTO client. I believe that such a strategy will allow Greg to derive
"service-specific" graphs that are transformed from an original graph.
Since the specific need for such "service-specific" graphs will be a
function of what the ALTO client wants, it seems reasonable to provide
building blocks in the form of an extension for encoding graphs that
can be coupled with the extensions for TE metrics
(draft-wu-alto-te-metrics). It is up to the ALTO client to put these
together in some fashion that satisfies its constraints.
--> Either the client or the server but not part of the standard. How a
network provider wants to represent
their network to a client is their business. In the case of controlled
environments (VPN) the provider may
customize what they show to a particular client (based on pre-arranged
information that is out of our scope).
Good, this seems to be heading in the right direction as well.
This has been an illuminating conversation, thanks for your time!
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
