4:59 p.m.
Hi Lars,
Thanks for your thoughtful analysis. There are some great points in your e-mail and the
document comments. Based on what you've brought up, it is clear that another round of
editing is justified for that document.
Your point about some remaining stories not informing the data schema is especially
well-taken:
· The infinite scroll should be relegated to the implementation document I've
started.
· There are a couple of references to "zooming", though they are
somewhat incidental, they can be removed if you like.
· I personally believe that centring could peripherally affect the data schema if
we choose to support metadata that would inform that. For example, picture a
visualisation that centres your view based on your identity, or IP address, or something
(this is an imaginary scenario!) — if the map were to automatically centre on CANARIE for
me when I visit it, I believe it should be up to CANARIE to specify where the
"centre" should be. In our case, it might be southeast of the geographic centre
to emphasize the cross-Atlantic and US links… maybe (or maybe not, but I believe we should
be able to make that decision and specify it in the map metadata if we so choose). Open
for debate of course.
To respond to a few other points you've raised in your e-mail and the document
comments:
· I actually think that the idea of showing only
inter-NREN/inter-region/inter-continental links is captured by the story "Link Type
Filter", though this exact use case has not been mentioned. (Happy to add it.)
Also, in reverse, by the "Inter-NREN Filter" story, which could be modified
slightly to describe exactly what you suggest.
· The idea of mapping virtual links to physical links is an interesting one. I
think it bears more discussion. Do any current visualisations show this kind of detail?
Do any foreseeable implementations require it? Or is it maybe a good idea for Version
Two?
· I like your suggestion (in the document's comments) about link traffic type.
I'll add a story about that, and call it, perhaps "Link Traffic Filter".
· I do think that activity metrics may have an effect on our main data schema.
I've been mulling over in my head (and with Tom at one point) the idea of
requiring/providing a guaranteed-unique ID for each link. (This would also support
disambiguation/deduplication after data updates, among other advantages. There are, of
course, disadvantages. To be discussed later.) In any case, somehow primary-key
identifying a link and its nodes would be required or at least highly beneficial for
connecting supplementary data sources like activity metric feeds. I'd like to keep
this in here, even if we don't get as far as developing a proper full schema for the
supplemental data in the first round.
· I believe that determining how the data is stored (distributed vs. centralised)
may indeed have an effect on the data schema. This is why we included the
"Access" story. If it is unclear whether the story affects data schema, I think
we should lean towards including it in this document.
Smaller notes:
· Yes, I meant "sites that support eduroam WiFi".
· The first sentence of the "Language" story is there so that it
doesn't look like we forgot about the user in this story, and to clarify what is meant
by the subsequent sentences.
I will distribute an updated document (with inline comment responses, in case this long
e-mail was too hard to follow) shortly.
Upon reflection, I wonder if, instead of having a separate document for
implementation-only user stories, we should include them in this document either in a
separate section, or simply identified as not affecting the schema development. Any
opinions, folks?
--
Ryan
From: Lars Fischer <lars(a)nordu.net>
Date: Friday, October 12, 2018 at 09:48
To: Ryan Davies <Ryan.Davies(a)canarie.ca>
Cc: GREN Mapping initiative <gren-mapping-wg(a)lists.nordu.net>
Subject: Re: [Gren-mapping-wg] User Stories Draft for Submission to GNA Tech
On 11 Oct 2018, at 8:36, Ryan Davies wrote:
Hi GREN Mapping Initiative folks,
We have had about two weeks to review the user stories document, and have made many
changes to it, some of them obvious and some subtle. Attached, find the consolidated
document, ready for submission to the GNA Tech WG for comment, along with our draft
charter. Note that we are not seeking formal approval, only feedback.
Ryan, thanks for your work on this.
Reviewing this, I see some confusion between user storied focused on the end-user mapping
application, and those focused on the data that must exist for the application to work.
We have previously agreed that our focus is on data format, representation, and exchange.
Capturing user requirements for the mapping application is of course important; we need
those to derive the attributes / meta-data to record in the data exchange format. However,
user stories that centre only on how the mapping applications works (infinite scroll,
centering, zoom) do not inform the data requirements.
I think that in this iteration, we should focus on user stories that do inform the choice
of data format and exchange, and we should make an effort to make sure the set if
reasonably complete for at least a known set of mapping applications. The way I like to
think about this, we are not trying to derive the requirements for a mapping application;
we are trying to derive the requirements for the data that will allow such an application
to be built.
To this end, I not that you have removed two user stories
* one about being able to show only inter-continental or inter-region links
* one about being able to map links to specific (physical) cables
If we remove those, and the meta-data that go along with them, then there are types of
maps that cannot be made from the data (i.e., without the first one, you can’t create the
GNA map)
I’ve attached the document with some comments.
/Lars
--
Lars Fischer - Strategy & Policy, NORDUnet
lars@nordu.net<mailto:lars@nordu.net>, +45 2288 1729, @lpfischer