See also: IRC log
<Frans> Kerry sounds much clearer now!
<Frans> Do I still need to let zakim know who I am?
<eparsons> No zakim does not know which audio you are..
<ebremer> me too
<kerry> it is nt me! I can still hear it!
<ahaller2> me too
<kerry> andreas -- zakim is retiring
<ahaller2> pity, i liked zakim
<Frans> Aharth - I seem to have much better audio now
<aharth> frans: i should probably switch to windows... webex does not like linux
<eparsons> http://www.w3.org/2015/04/22-sdw-minutes.html
<phila> PROPOSED: Accept last week's minutes
<phila> +1
<ChrisLittle> +1 minutes
<eparsons> +1
<Frans> +1
<ebremer> +1
<kerry> +1
<Ian_Holt> +1
<Linda> +1
<billroberts> +1
<aharth> my regrets were not recorded, but +1
<phila> RESOLVED: Accept last week's minutes
<Payam> +1
<scribe> scribe: Jeremy Tandy
<scribe> scribenick: jtandy
eparsons: no new members this week - but asks anyway
phila: dmisev?
dmisev: I am from Jacobs Univ in Bremen - representing Peter Bauman
eparsons: will this be regualr?
s/regulr/regular/
dmisev: yes
eparsons: the only issue on the agenda
<phila> I've added your regrets to last week's minutes, aharth
eparsons: other than use of webex
is
... principles - the broad over arching goals behind the best
practice doc ...
... the non-functional requirements
... regarding webex - suggest we learn as we go along
<Frans> Main agenda for this meeting: https://www.w3.org/2015/spatial/wiki/Meetings:Telecon20150429#Main_agenda
eparsons: which is best in IRC, which is best in webex etc
kerry: one advantage of webex is that we can share presentations etc.
eparsons: [agrees]
... there's also the whiteboard - but we couldn't figure out
how to make that work
phila: just to clarify from W3 pov ... happy to use webex but use of IRC is W3 policy ... this is where the minutes are
eparsons: agreed ... and we
record the actions in IRC too
... OK - to the main point of business
<Frans> So we should ignore the Raise Hand button in WebEx?
eparsons: getting to the point where we can work on the best practice doc
<ebremer> we should, redundant to IRC
eparsons: before we start the BP
doc we need to determine _what_ we want to achieve
... not how to achieve that
Frans: the principles could be
the same as the non-functional requirements -
... but non-functional req are more about how than what
eparsons: from my pov - I want to
get a common understanding of the (big) problem we want to
solve
... surfacing geospatial information on the _main_ web ... not
niche [paraphrased]
Frans: is the charter not clear enough
eparsons: I think it is ...
Frans: so we need some finer details than are specified in the charter
eparsons: we can't re-write the
charter - but we can add details
... "why are we all here?"
... is the key question
... we're aiming at broad market adoption - not a particular
user community
... this is a principle
Frans: but this could also be seen as a non-functional req
kerry: Frans' email phrased 3
questions:
... i) vision
... ii) & (iii) [missed]
... the questions we need to ask are quite broad
eparsons: can you talk through
the points you made in the email?
... Frans:
Frans: distinction between
functional and non-functional requirements
... earlier I though we could leave the non-functional reqs for
now ... but we keep coming back to them
... examples - scalability, performance, mass market appeal
<ChrisLittle> +1 to being explicit
Frans: could make sense to list these so that we can refer to them
<phila> Frans' e-mail
Frans: this explicit list could help communicate our thoughts with other WGs such as DWBP
eparsons: you're right ...
... the principles give the context within which the BP doc
exists
ChrisLittle: non-functional
requirements [...] whether they get passed to the DWBP is a
different issue
... need the list of functional and non-functional reqs
... any of these could be passed to DWBP
eparsons
<kerry> +q
eparsons: what's your point about the broader principles?
ChrisLittle: we should capture these ...
kerry: comments on the three
questions
... in Frans email
... 1. Are Principles the same as non-functional
requirements?
... 2. Should they only be applied to the Best Practices
deliverable or to all deliverables?
... 3. Does it make sense to describe them in the UCR
document?
<ChrisLittle> *me my microphone is disconnected, so echoes probably not my fault
kerry: for (1) ... principles are broader - but a subclass on non-functional reqs
<eparsons> ChrisLittle I will keep you muted - ping if you want to talk
kerry: for (2) principles should
be applied to all deliverables; non-functional requirements
_may_ be applied to all - but certainly to BP doc
... for (3) YES
eparsons: any other views?
Frans: I wonder if we could have an example of a principle is not a non-functional requirement?
eparsons: good question
... earlier I said that we were trying to make geospatial data
more discoverable
... this could be seen as a non-functional req
<kerry> +1 is a priciple or a goal
<joshlieberman> That sounds like a goal.
eparsons: but because it's so
broad you can't really deliver against it [in a particular
iteration]
... it's more like a vision or a goal
<joshlieberman> Is "non-functional requirement" really anything? It certainly sounds too close to "disfunctional"
<Frans> Here is a definition: http://en.wikipedia.org/wiki/Non-functional_requirement
<joshlieberman> webex is having trouble with bluetooth...
joshlieberman: [...]
<kerry> +q
kerry: proposes
... a non-functional requirement
... a fresh non-functional req that is not a goal:
... that the ontology work we do can be used comfortably with
PROV
... this is more technical than a vision thing
... more of a behind the scenes things
... a non-functional requirement that is not a goal
phila: if you wanted to
generalise this to a goal then
... the principle is "re-use existing vocabs"
kerry: happy with that - but I wanted to be specific about PROV
<joshlieberman> an ontology that works with PROV could be considered a functional requirement in the domain of ontology engineering...
kerry: need to show how SSN and PROV work together
eparsons: broad principle is
"don't reinvent" ...
... if there's something else out there - then re-use
<kerry> +q
eparsons: it's easy to get caught up in the semantics of [non-]functional requirements
<Linda> +1
+1
<billroberts> +1 to broad community, though somehow have to define 'how broad'
Frans: semantics is always
difficult
... it would be good to have a _single_ list of requirements -
each of which we can classify
... let's avoid having two lists
... for simplicity - can we agree a name [for the
classifications]
<ChrisLittle> +1 to one list, annotated
eparsons: am not sure I
completely agree
... principles sit at a level above the non-functional req
kerry: we can get through this by listing all the requirements now and classify _later_
<joshlieberman> would it be more expressive to say "design requirement"?
<Linda> +1 - first list, then group always a good idea
kerry: we don't need to decide if it's one list or two right now
eparsons: that's pragmatic
... but I think it's important we all share the common
vision
Frans: shall we set up a new wiki page for the principles?
eparsons: this would be good -
<kerry> lets call it "goals, principles, vision and non-functional requirements"
eparsons: it doesn't need to be a list - more a narrative description of the problem we're trying to solve
Frans: bullet list would be nice
[this allows cross-ref]
... to check against design principles
phila: I worry that this starts
to get into duplicating the use case doc
... or writing the intro to the BP doc
... is this mission creep / duplication
... a word of warning - my other group [DWBP] has spent a year
trying to determine scope!
... the principles would be useful - but [this feels more like
the intro to the BP doc]
... I want to avoid a "rat hole"
eparsons: [agrees]
kerry: [agrees] ... we can assemble things on the wiki then transfer to the introduction
<Frans> The UCR document started on the wiki too
eparsons: I understand where
Frans is coming from - but it's not necessary [or always
possible] to break down these things into
... discrete elements in a bullet list
billroberts: I was wondering if there is a way to work towards this [...] based on concrete examples rather than try to figure out a classification scheme up front
eparsons: [the introduction of the BP doc] is the place where we can get collective agreement on what's in / out of scope
<kerry> bill - i agree, but that is exectly where we are now -- we are seeing what the UCRs demand and that is driving our assessment of "purpose"/principles.
<Frans> I am all right with just starting and to see where we end up
<kerry> jeremy says....
<phila> jtandy: It's worth while doing a bottom up and top down approach simultaneously
<kerry> jeremy: do top down and bottom up at the same time
<kerry> jeremy: start doing stuff and then test against principles
<kerry> jeremy: start now wit ha few principles and then use them.
<Ian_Holt> +1 Jeremy
<ebremer> +1 to avoiding analysis paralysis
<kerry> jeremy: lets just get started
<Payam> +1 - agree withhh Jeremy
<Linda> +1 Jeremy
<ChrisLittle> +1 to jeremy
<joshlieberman> +1 to doing stuff
eparsons: I guess we create a new
wiki page that will be a scratch pad for the princples
... lets adopt both top-down and bottom-up
... the goal here is nothing more than [framing what we want in
the BP doc]
Frans: so this means we will not have another chapter in the UC doc listing non-functional requirements?
eparsons: I don't think that is
[necessarily] the case
... the principles are at a higher level
Frans: I'm not looking for more work ...
<kerry> +1
Linda: wrt a chapter on non-functionals in the UC doc does this mean they don't get recorded?
eparsons: I think we do need to record them
Frans: I don't understand the
difference between the principles and non-functionals
... I don't see the difference in levels
... if we do see the difference then I can add the chapter
in
<phila> jtandy: I see the narrative in the intro to the BP doc as setting out our overall goals
<kerry> +1 jtandy
<phila> ... our non-functional reqs are ones that can be tested
<eparsons> +1 to jeremy
<phila> ... so a principle is non-testable, a non-functional req is testable
<ChrisLittle> +1 testable requirements
Frans: this could be part of a
definition
... but are all non-functional reqs testable?
... perhaps this is part of the definition
eparsons: perhaps this is another
way to distinguish between the "what" and "how"
... interoperability is not a goal in itseslf
s/iteslf/itself/
<Zakim> phila, you wanted to talk about Erwin Folmer's use case
eparsons: I will create the wiki
page that is the "scratch pad" for the BP doc intro
... let's try - doesn't need to be bullet points
<phila> ACTION: ed to create wiki page that is the scratch pad for the BP doc intro [recorded in http://www.w3.org/2015/04/29-sdw-minutes.html#action01]
<trackbot> Created ACTION-23 - Create wiki page that is the scratch pad for the bp doc intro [on Ed Parsons - due 2015-05-06].
<Frans> this one https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#INSPIRE_compliance_using_web_standards_.28Best_Practice.29
<phila> Erwin Folmer's use case
phila: Frans- did you notice Erwin Fulmer's use case?
Frans: yes
phila: does he know you've done
it - have you let him know (e.g. explicitly responded to the
email from the public list)
... the W3 process issue is "have you responded to the comment"
- you need to tell him how you've acted on his request
Frans: should the reply be on the list?
phila: yes - keep all emails on the public list
<phila> jtandy: I reviewed the UCs that I put in. I've created a pull request on the repo that Francs and Alex can accept if they want to
<phila> ... I suggest we use that workflow. Editors remian in control of merging requests
<ChrisLittle> +1
<kerry> no!
<kerry> We use the tracker for issues!
<ChrisLittle> bye
eparsons: let's put git process on the agenda for next week ...
<aharth> vyw
<Ian_Holt> Thanks. Bye.
bye
<ebremer> bye
<Linda> bye
<billroberts> bye