<AxelPolleres> We start with an introduction round
<AxelPolleres> scribe: javier
Start with a quick introductory round
Eva from ULD Germany, working in SPECIAL project
Rigo, working for W3C and ERCIM
Bud, also from ULD, just joined the group
Niklas, from WU, working in the Expedite project
Fajar, from TU Vienna, working also in the Expedite project
<simonstey> Simon, PhD @ WU Vienna & working as research scientist at Siemens
Javier, from WU, working in the SPECIAL project
Martin, from DT, working in the SPECIAL project
Amr, phD student in TU, working in WU in the SPECIAL project
Axel, working in WU, SPECIAL project
Axel: the main goal is to fill
the vocabularies with content
... I would suggest to start from the use cases
Axel going trough the agenda: https://www.w3.org/community/dpvcg/wiki/F2FVienna3Dec:Agenda
Eva: the purpose discussion is probably connected to the legal ground (tomorrow)... we can maybe start on purposes but I expect to already talk of legal ground
Axel: we keep this on mind, it
makes sense
... I agree that these concepts are all connected, so might
want to connect them in the discussion
... At 17 we have the meetup, one speaker is sick but maybe
Rigo can jump in
... as for the lunch, please send the receipt to ERCIM who will
kindly sponsor it
Eva: Maybe we can start with an overview on where we are, also to give an update to my new colleague
Axel: We started the group at the
same time of the start of the GDPR coming into effect
... Idea was to standardise certain vocabularies around
terminology used in GDPR, to describe the purposes, the
different types of personal data, consent, legitime
interest...
all starting from a personal F2F meeting here in Vienna
Since then we had several telcos (bi-weekly), also a meeting in the mydata conference (e.g. Elmar)
there is an IRC channel (this), a mailing list (with an archive as well), a wiki, an internal version accessing with W3C account, the minutes of our meetings..
we collect actions in the "Tracker"
We agreed on the scope of the group: focus on categories of personal data (we also talked of instance data, e.g dates of birth, for data portability... still to clarify), purposes for personal data hadling, processing involved, data subjects, controllers, processors and recipients, storage and security aspects (location, duration, security measures)
and last, means of legitimation for personal data processing (content, legitime interest, etc.)
See these points at: https://lists.w3.org/Archives/Public/public-dpvcg/2018Nov/0000.html
Then we started to collect use cases: https://www.w3.org/community/dpvcg/wiki/Use-Cases,_Requirements,_Vocabularies
most of them from SPECIAL and DECODE
We also collected different vocabularies including such terms, as we don't want to repeat efforts (and mistakes)
Harsh: Maybe we go to the taxonomies first
... we agreed on some taxonomies: approved means approved
during the telcos
... I tried to identify categories and terms in each of
them
... There is commonality in most of them, but the structure is
different
a very structure new ontology might not align well with this
<rigo> I opened my personal room on webex https://mit.webex.com/meet/rigo
Taxonomy: https://www.w3.org/community/dpvcg/wiki/Taxonomy
Rigo: if you want an ontology of
what personal data is, you have to look into vcard and P3P with
a full range of personal data (by microsoft), related to
profiling....
... but this is boling the ocean (thousands of terms). That's
why we use Linked Data to start some island and connect
them
<rigo> meeting number is 640 414 996
Harsh: Agree, it is very challenging to create such categories
Niklas: agree, sometimes is more the association with the id rather than the data itself
Eva: is a moving target, the decision is always context dependent and depends on the link to other information
Niklas: it depends on the processing more than the context
Eva: What is approved in the wiki?
Axel: It is "approved for discussion", or "in scope"
Bud: how can one access the wiki?
Axel: W3C credentials
harsh: there are many categories in privacy policies (online service, etc.) and there are techniques to extract terms from them (the legal documents). But I'm not familiar with it... does anyone know a bit more?
Axel: I think we need to provide the general framework such that people can plug in
Niklas: People can build upon our initial set of categories
Axel: I would suggest to go to the use cases first and see what is in scope
Rigo: I would suggest to go to the use cases and identify this island. And use vcard first
Axel: But there is an RDF version of vcard and not really new 2011
fajar: There is a version for
2014
... Interest group note: https://www.w3.org/TR/vcard-rdf/
<Fajar> vcard ontology: https://www.w3.org/TR/vcard-rdf/
Axel: Probably it doesn't contain all we might need
Rigo: but that's why we have
these island
... and Linked Data, to find terms that already exists
Javier: We did something similar already with an extension of SPECIAL categories (data, purpose...) for a smart city scenario
(project cityspin: http://cityspin.net/wp-content/uploads/2017/10/D6.1-Privacy-policy-formalization.pdf)
Rigo: And we can use the w3c
namespaces for this
... It is more a social issue rather than a technical issue
Axel: Maybe we should look more at vcard (will add to the wiki) indeed
Harsh: but vcard looks at the data of a user, not the personal data category per se
Rigo: It is easier to look at the real instance data rather than categorize the world. In a second phrase we need to look at the personal data
Axel: We should also consider the time dimension, relation to data and person in the context of the time
Rigo: There is not a standard version to add the context (quads being one of them). There are many, we just need to choose one
Axel: Note that we need to point to the version of the vocabulary being reused (e.g. see at the different foaf versions)
Rigo: our role is to help the
"judge" to look at the very fine details. The only think we
have to do is to record the version that applies at certain
point of time
... by provenance
Axel: we need to manage the vocabularies in a way that supports versioning (which is fine, we have the knowledge and experience on that)
Axel: start with Thomson Reuters' use case: https://www.w3.org/community/dpvcg/wiki/SPECIAL/TR_use_case
Axel: describe the TR use case.
Know your Costumer, maximise the info of your costumer in the
financial domain (basically for trustworthiness)
... basically for legal entities, nor physical persons
... they want to compute the risk level of a legal entity
(going through the types of data in https://www.w3.org/community/dpvcg/wiki/SPECIAL/TR_use_case)
<Fajar> ... same personal document in different regions might have different attributes (e.g., birth document)
Eva: They are having troubles allocating data to specific sources
Niklas: Note that once you have some basic information, you can derive new data... this is very relevant
Eva: There is article 14th of GDPR that applies when you collect from different sources
Rigo: we are creating an infrastructure for people that want to do the things right, it is a different scenario
Axel: But if collecting public information is subject to GPDR we have to consider it
<rigoo> WEF data categorization only makes sense for blocking tools and other defensive PETs
Eva: sometimes the info of a
company is personal information, e.g. if there is a company of
only one person
... also another point to consider in the use case is that, if
you have the copy of the passport, you have the full
information (not only the ID)
Axel: but if you don't use it, maybe it is not needed to represent
Eva: But data collection matters
Axel: but we can have some "rules", e.g if we have one item of this category, this implies that we have also more information
Rigo: it is really use case dependent
Fajar: what I got from Eva is that it is really different e.g. to fill the ID of a passport in an online form or to have the full picture of the passport as you can have all even if you only need the ID
Rigo: in our use case description (in the website), the description is not complete (with the picture you have more data items potentially)
<rigoo> we are back in categories vs instance data
<simonstey> +q
Axel: what we need then is this kind of implications to know that from an image of a passport you can get X, Y, Z
-q
Simon: agreed with Axel, if the action is collecting a picture of the passport, then this implies that X, Y, Z information is also collected
Eva: what we need to capture is the kind of information that is relevant when the GDPR applies: processing of personal information
<rigo> I tried to invite zakim, but he's recalcitrant
Eva: i.e. operations on personal
data (collection,adapting...)
... collection is also a processing
... The important aspect is to understand that GDPR does not
only apply when using the data... also collecting
Axel: Agreed, I was suggesting to have this implicit information in the categories, but maybe it is too use case specific (e.g. sometimes the religion is in the passport, sometimes not...)
Bud: For passport, some info is standard (e.g. to read it electronically)
<simonstey> https://en.wikipedia.org/wiki/Identity_document
<simonstey> https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area
Rigo: Bud, it would be good to have these standards
<simonstey> https://en.wikipedia.org/wiki/Public_Register_of_Travel_and_Identity_Documents_Online
Bud: e-ids... it depends on the country
<simonstey> https://www.consilium.europa.eu/prado/en/prado-start-page.html#
Harsh: what about birth certificates?
Axel: not standard, e.g. in
Austria you can infer the marital status of the parents
... maybe the representation is standard, but there are some
inferences that are implicit
... it is a very nice work, to collect the kind of info you can
collect from these documents
<simonstey> austrian documents https://www.consilium.europa.eu/prado/en/prado-documents/AUT/index.html
<rigoo> no zakim so far
Axel: as a CG, it is a good exercise to collect the personal information tht can be inferred from another one
Simon: I pasted links in IRC (prado coming from EU, an extensive list of possible documents, e.g. weapons cards, driving license...)
<Niklas_> we should also take a look at this: https://joinup.ec.europa.eu/sites/default/files/document/2018-11/ISA2%20Study_GDPR%20Data%20Portability%20and%20Core%20Vocabularies_November%202018_1.pdf
Bud: the inference is very difficult, normally is linked to other thinks, and the more I link, the more you can infer
<dlewis> pointer on what might inferred just from people's names from an internationalisation perspective: https://www.w3.org/International/questions/qa-personal-names
Rigo: From previous work (P3P..)
we had three points to standardize: personal data is one of
them with sticky policies (link policy with the data), then the
object data with processing and what you can do with it, and
then the policy and finally the instance data and how to
package all together
... for data we are open, here are some hints (with some core),
.... but I understand that we need to define the space of
expression that it is given by the GDPR
Niklas: is sensitive data clearly defined in GDPR
Rigo: 2 categories, (i) as
defined by article 9, very finite, (ii) and dangerous aspects
not mentioned by article 9 such as location data
... e.g. location data is extremely sensitive (e.g. gender
violence) but it is not sensitive within GDPR
Bud: In article 9, there are the conditions when there is a extremely risk.... and I think you can identify location with these conditions
Rigo: Interesting to consider
<Eva__ULD_> Bud mentions the Art.29 working Party's Opinion about Data Protection Impact Assessments, they list items and conditions where high risk can be assumed, location being part of it
Axel: So we need the concrete
terms in Art 9 + the conditions if we need to categorize
sensitive in our taxonomies
... Similarly than the documents, we can collect also some
examples of potentially sensitive inferenced data: e.g. if we
know that a person visits this place and it is a religious
place, then....
harsh: Do we need to collect some cases of integration, e.g. location+religious=....
Axel: we can maybe first collect
the sensitive attributes in our use case. And then see which
attributes co-occur and leads to well-known inferred
knowledge
... to say that there is a potential risk
Bud: It is not only that the attribute is sensitive... In risk assessment in Data protection you have the parties interested, how often you collect, etc. how sensitive something is... is not only about the attribute
<rigoo> chair: Axel Polleres
Fajar: You have to consider the context in order to describe the risk
Axel: Maybe interesting research wise, but for the standard is mostly the attributes themselves
<simonstey> present Fajar_Ekaputra Javier_Fernandez Martin_Kurze Amr_Azzam
Dave: There is also a kind of preprocessing, first you contextualise the use case, decide what is personal data and sensitive and then put it in the taxonomy
Axel: TR is mostly about the attributes collected in the use case page, let's switch to another use case to have another perspective (deutsche telekom)
<DPVCG-presenter-PC> ACTION: Eva to look into requirements of data protection assessment, and whether it would make sense to formalize that in terms of what we standardize
<trackbot> Created ACTION-42 - Look into requirements of data protection assessment, and whether it would make sense to formalize that in terms of what we standardize [on Eva Schlehahn - due 2018-12-10].
Martin: presenting the use case,
slides in the webex channel: https://mit.webex.com/meet/rigo
... Purpose is (i) to analyse the quality of the network, (ii)
to serve a third party, Motion Logic
... Motion Logic has the interpolation of the signal, the goal
is to come with some traces (e.g. 90% of the people leaving X
station go to Y, and 10% to Z)
... they can already do it, but they need to prove the quality
of their algorithms... and they do it with exact data. That's
the main purpose
<simonstey> https://www.motionlogic.de/blog/de/datenschutz/
Martin: And that's why derive is so important: you validate your approach with few individuals and you extrapolate to all your customers (millions)
Rigo: Besides derivation, it is important to consider that the subject has this control of de-activating the tracking option
Martin: collected data is mainly signal strength. But of course with the location data you can infer more things
<Eva__ULD_> Martin: the signals stream is linked to other information, such as the device identifier
Dave: Regarding this derivate data... it is a bit probabilistic... is there a threshold to know when derivate data becomes personal?
<rigoo> harsh: that's the filter, you need k-anonymity of 30 people before
Martin: We only use the data if we have at least 30 people in the group, kind of K-anonymity
<rigoo> harsh: still coarse data is personal data?
<Eva__ULD_> Martin: the minimum anonymization set is 40 people within a cell tower area, if there are less, the data set is not being used
<rigoo> Axel: location data that is not connected to other data?
<rigoo> Martin_Kurze: can easily be pseudonymized. IMEI to something
<rigoo> AxelPolleres: use case is to derive the model from the sample
Martin: For DT use case, it is more quality analysis and optimization
<rigoo> of the algorithms
<rigoo> harsh: what is the legal basis
<rigoo> Martin_Kurze: it is anonymized and aggregate
Bud: Do you use Android location service?
<rigoo> ... Monetization happens on motion logic side when its not personal anymore
Martin: yes, but it is not
implemented now
... and we only have 30 people in the test, from ML
Harh: Is the Google location service still valid from the consent point of view?
Rigo: not sure....
we will continue with more use cases after lunch
Rigo: please leave the webex now and I will open it again after lunch
will be back at 14h
(1 hour)
<Axel> we're back from lunch
<harsh> waiting for a few members to join in the room
<AxelPolleres> a proposal … as for personal Data categories, we should have a process to propose and accept personal data attributes to the taxonomy:
<AxelPolleres> attribute name: e.g. location
<AxelPolleres> description: physical location of a person
<AxelPolleres> mapping to existing ontologies:
<AxelPolleres> datatype/range: geo coordinates or other geospatial feature identified by a URI (e.g. country) wherein the person is located, that has geo-coordinates or a spatial extent defined by a line or polygon
<AxelPolleres> typical temporal extent: how often is this attribute typically changing for a person
<AxelPolleres> mapping to existing ontologies: e.g. foaf:locatedIn ?
<AxelPolleres> Attribute types:
<AxelPolleres> sensitive according to Art. 9,
<AxelPolleres> requires data protection impact assessment according to Art 29, might depend on an attrribute or combination of attributes at a certain level of (temporal) granularity being potentially sensitive in a certain context
<rigoo> simonstey: can you hear us?
<harsh> scribe: harsh
Looking at DECODE/DEC03 use-case https://www.w3.org/community/dpvcg/wiki/DECODE/DEC03_use_case
<rigoo> harsh: basically two sets of situations,
<rigoo> ... people living and home and having sensors
<Axel> https://www.w3.org/community/dpvcg/wiki/DECODE/DEC03_use_case#Alternate_Flows
<rigoo> .... categories of personal data involved, location sensor in the house
<rigoo> .... noise measurement, don't know whether this involves listening devices
harsh: Do listening devices (from use-case) regard as personal data in the context?
rigo: Listening devices does not come under the GDPR.
<Javier> (Hasrsh presents the use case https://www.w3.org/community/dpvcg/wiki/DECODE/DEC03_use_case)
rigo: They are considered specifically under telecommunication devices.
<Zakim> Axel, you wanted to ask rigo whether voice recording, video recording, images are then to be treated differently
AxelPolleres: are images of a person personal data? (according to GDPR). If yes, then video would also be. It is weird that audio is not personal data.
rigo: There are rules in addition
to the GDPR. The scope of the Telecomm regulations is so narrow
that there is nothing of the GDPR left to apply.
... Recordings are very sensitive.
Martin_Kurze: these also apply to devices such as Alexa
rigo: If it indicates noise, then it only indicates presence, and is not sensitive
Eva: it depends if the data is being stored locally or sent anywhere
rigo: This means connected vs
disconnected (local)
... If data is being sent elsewhere (remote) then this is of
relevance (for purposes of inference)
<Axel> sensors that transmit their information over electronic communication fall under telecom laws rather than GDPR
AxelPolleres: we never said in the group that we only cover privacy/GDPR
Fajar: Is it different when we share vs when it is always connected
rigo: If the device records data, then it is the same as sharing as it can be shared at a later time
AxelPolleres: is there a difference between audio and video (recording) or still images
rigo: The media type is regulated based on different laws (also case laws)
Eva: What we do for GDPR is also relevant for other contexts (legal), and what is of interest is the processing itself. Whether it is communication.
<rigoo> which is mostly telecommuncation law, penal law, and right on one's own picture
AxelPolleres: We have from the use-case the differentiation between media type (image, video, audio)
<Axel> what about noise sensors in personal offices...
rigo: If it is a home, and there are multiple people living in the home, then it becomes some form of k-anonymity
Eva: It also depends on whether it is in home or a public place or office.
<Axel> Rigo: same as k-anonymity, i.e. a moving target
<rigoo> eva, may want to need to define a threashold for those noise recognition devices
<rigoo> and lay down in the ontology
<Axel> we should scope to personal information which does not need deanonymization techniques.
<scribe> scribe: harsh
<Axel> ACTION: eva to have a look a study on AAL that might help us
<trackbot> Created ACTION-43 - Have a look a study on aal that might help us [on Eva Schlehahn - due 2018-12-10].
<rigoo> the DECODE03 case is a kind of test case for assisted living scenarios
AxelPolleres: I put something in
the IRC regarding a proposal for the Data categories - we
should start collecting attribute names such as location, dob,
a description of what that is (natural language), and whether
it already exists in some existing ontology (eg. vcard) and a
data type or range (eg. geo-co-ordinates)
... and the typical temporal extent (eg. how often this
changes)
... this could be the starting point to collect the core
attributes
Fajar: Should we only describe the abstract data or also specific data eg. bank account contains other attributes, then what should be included in the data definition?
rigo: this depnds on the use-case. You can have all kinds of data organised in a hierarchy, and if someone links only the top concepts, the structure is lost
dlewis: you start with saying it is a composite object with an anchor (e.g. phone number) and you specify whether it is a strong or a weak anchor
rigo: if we are under GDPR we are
obliged to treat the data in a certain way; then it becomes a
business decision regarding risk
... it depends on how strong the probability is it that the
information can be inferred to be a specific individual
<Axel> would it make sense to distinguish directly identifying attributes vs. describing how/under which circumstances this attribute identifies a person?
rigo: its about indentifying identifiers and how they relate via attributes
fajar: should we only add the data/instance e.g. phone number or also model/add information on what can be derived / added to the phone number?
AxelPolleres: we are making this
hard for ourselves. In principle, we are looking for data that
is one or two hops away from the person (in terms of graph)
e.g. bank A/C number
... attributes also mean chains that can be traced back to the
individual, and in the description we say what the chain is
rigo: this is an application of linked data: following the edges
fajar: but then we can run chains of any length
<simonstey> to just one, >1 would be fine?
rigo: it doesn't matter how long the chain is, what matters is that the chain links to the individual. This is the algorithm to use to identify personal attribute for the individual.
fajar: we should not depend on the number of hops / links, it is a technical matter
rigo: to summarise - for personal data, we have a simplified defintion as attributes connected to a person somehow
<Axel> values of attributes connected (directly or via a known path) to a person.
<Axel> values of attributes connected (directly or via a known or reconstructable path) to a person.
Eva: regarding pseudo-anonymous data - then someone has the knowledge or path to link it to the individual
rigo: this excludes edge cases, for the moment we only address mainstream use-cases and leave out exotic ones
<Axel> attributes appearing in a known use case.
rigo: the taxonomy has to be done for personal data first before delving in to more granularity
Eva: (reading definition of persona data from GDPR)
moving to discussion regarding Purposes
<Axel> What is a purpose?
rigo: Purpose is what is the
policy data - what are you doing with the data
... we should widen the scope to talk about retention time
etc.
<Javier> Javier: definition of personal data by GDPR is very important as it says "any data" related to PII, directly or indirectly (it does not matter if the data can directly identify you)
Eva: purpose is the question "why" so it is the goal for processing - the controller wants to do something
<rigoo> identifiable data is defined in consideration 26 of GDPR:
<rigoo> To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.
rigo: in P3P we used "current purpose" and GDPR has reference to this as to fulfil contract or obligation which is an abstract for the current activity. To have a declarative logic there, we have to define all purposes, which are infinite
Eva: we should try to derive classical purposes from the use-cases
AxelPolleres: starting point is
purposes from P3P
... (showing MyData logo) the icons categorise the personal
data (maybe in its context)
rigo: these are purposes rather than data categories
harsh: can purposes be structured into a hierarchy?
rigo: most of them yes
(discussion regarding provision of goods as a purpose in an online service, where transaction and delivery are sub-purposes)
AxelPolleres: where would advertisement fit in this (MyData)
rigo: we should add advertising as a purpose
<Axel> https://github.com/okffi/mydata... discussion is this a starting point for defining purposes? e.g. where does advertising fall into?
rigo: if we have a strict structure or hierarchy then we burden the developers for choosing
eva: we start with a small set of purposes and subsume our use-cases and it is up to others to adopt and apply these approaches for their use-cases
Bud: everyone uses a different vocabulary, and data-subjects want a consistent representation of policy
<Axel> https://www.ownyourdata.eu/en/startseite/ has a simplified classification of the mydata logo
(discussing SPECIAL categories for purposes in Deliverable 2.1)
Bud: we should express purposes from the perspective of the data subject e.g. storing credit card number for convenience
<Axel> Eva: shall the purpose reflect the business model / business process where the data is used
<rigoo> we could start with SPECIAL purposes extended by DECODE and smart cities purposes
<Axel> ACTION: bud to propose/investigate high level purpose classification structuring options
<trackbot> Error finding 'bud'. You can review and register nicknames at <https://www.w3.org/community/dpvcg/track/users>.
<rigoo> two goals: Notification and Consent
Eva: purpose should reflect the real part of the business process - what is happening, a connected requirement is that the purpose category should be intelligible to the data subject
<Axel> purposes could be classified along the beneficiary... e.g. improving of the user experience, vs. optimization of a service in order to make it more cost effective to the provider
rigo: it is a legal matter for being specific vs being abstract; we have to be able to express whatever the outcome i.e. it should be abstract as well as specific in terms of level
fajar: this is a layered taxonomy, and we can provide layers of abstraction
<Axel> rigo: we wil not be able to solve the granularity problem, that is what courts will have to decide.
fajar: And the organisation can then extend these to be more specific to their services
Eva: we can show this using our use-case (how to extend)
AxelPolleres: whether the purpose is specific or abstract depends on the context e.g. service provision
<Eva> Eva: We can take one r two of our use cases to show in an exemplary way how the top-level purpose(s) could eventually be sub-categorized to make them more intelligible and precise for data subjects
rigo: service provision already
has a legal meaning (from the user's perspective e.g. service
of facebook is to communicate socially)
... and then there are 3rd parties that provide advertising
which is a completely different purpose
AxelPolleres: so are the purposes sector-based
rigo: we should start with the SPECIAL purposes and use them in the MyData list
<simonstey> education is another purpose
AxelPolleres: how do we structure purpose as definition / taxonomy? It is difficult to express them as a definition using natural language.
rigo: what is the best way to create the taxonomy so that it ensures adoption and reuse?
<simonstey> https://www.w3.org/TR/odrl-vocab/#term-purpose
<Javier> See also some initial purposes in SPECIAL: https://www.specialprivacy.eu/images/documents/SPECIAL_D2.1_M12_V1.0.pdf
<Javier> I think we had education as well
<Javier> svpu:Education
<rigoo> Bud: who benefits from data collection and processing as part of the taxonomy
<Axel> personal data (collected or inferred) = what?
AxelPolleres: for personal data, processing = how?
<Axel> purpose = why are these collected?
<Axel> processing = how are they collected processed to fulfill the purpose
<simonstey> http://bl.ocks.org/susielu/9526340
rigo: how to visualise the purpose hierarchy
<simonstey> or like in the "visualize" tab here https://json-ld.org/playground/
<Axel> ACTION: fajar to list purposes from Taxonomy in a table and structure them by source, definition, legal basis (cf. flipchart)
<trackbot> Created ACTION-44 - List purposes from taxonomy in a table and structure them by source, definition, legal basis (cf. flipchart) [on Fajar Ekaputra - due 2018-12-10].
<rigoo> trackbot, close the meeting
<trackbot> Sorry, rigoo, I don't understand 'trackbot, close the meeting'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<rigo> trackbot, adjourn
<trackbot> Sorry, rigo, I don't understand 'trackbot, adjourn'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<rigo> trackbot, end meeting