W3C home > Mailing lists > Public > public-sdw-wg@w3.org > April 2015

[Minutes] 2015-04-29

From: Phil Archer <phila@w3.org>
Date: Wed, 29 Apr 2015 15:20:50 +0100
Message-ID: <5540E8C2.7040906@w3.org>
To: SDW WG Public List <public-sdw-wg@w3.org>
The minutes of today's call are at 

Thanks to Jeremy for scribing.

A text snapshot is included below.

           Spatial Data on the Web Working Group Teleconference

29 Apr 2015

    See also: [2]IRC log

       [2] http://www.w3.org/2015/04/29-sdw-irc


           Armin, Andreas, Ashok, Bill, Chris, Dimitar, Erich,
           Frans, Ian, Jeremy, Kerry, Linda, Payam, Jitao, Josh

           Rachel, Antoine, Alejandro_Llaves, LarsG, Andrea_Perego,
           Stefan_Lemme, Clemens_Portele, Matthew_Perry


           Jeremy Tandy


      * [3]Topics
      * [4]Summary of Action Items

    <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> [5]http://www.w3.org/2015/04/22-sdw-minutes.html

       [5] 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

    eparsons: will this be regualr?


    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:


    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

    eparsons: we can't re-write the charter - but we can add
    ... "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
    ... Frans:

    Frans: distinction between functional and non-functional
    ... 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

    <phila> [7]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

    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


    <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:

       [8] 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
    ... 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

    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


    <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

    <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

    <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

    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
    ... 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

    <kerry> jeremy: start now wit ha few principles and then use

    <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


    <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

    <trackbot> Created ACTION-23 - Create wiki page that is the
    scratch pad for the bp doc intro [on Ed Parsons - due

    <Frans> this one


    <phila> [11]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.


    <ebremer> bye

    <Linda> bye

    <billroberts> bye

Summary of Action Items

    [NEW] ACTION: ed to create wiki page that is the scratch pad
    for the BP doc intro [recorded in

    [End of minutes]
Received on Wednesday, 29 April 2015 14:20:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:16 UTC