Spatial Data on the Web Working Group Teleconference

<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