<AxelPolleres> We start with an introduction round

<AxelPolleres> scribe: javier

Welcome & Introduction

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)

Check Actions (mostly related to use cases)

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)

<simonstey> https://www.telekom.com/en/corporate-responsibility/data-protection-data-security/data-protection/your-data-at-dt/details/location-data-492762

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

DECODE use case 3

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)

purposes of personal data handling

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