Re: Friday's Call

It is likely that I’ll not be able to make this coming Friday’s call. Below are a few of my initial thoughts triggered by Toby’s email.

Joss

I don’t know of any papers that discuss models for data transfer of individual’s building / infrastructure preferences between or within buildings.

In the UK it is clear from my recent government interactions that BIM (Building Information Modelling/Management) systems are the likely to be the earliest introduction point for many IoT systems. I was involved in an IoT Cities bid a few years ago with one of the vertical vendors where the combination of COEL and there existing systems was part of the bid. Unfortunately it was not funded – but it did cement by belief that this is a very relevant area.

They key question we came to was one of information governance. When sensors created data within the building, we needed ask the question of whether (under a GDPR definition) the data was personal or not. If it was personal (capable of differentiating individuals even it did not identify them directly) then COEL became the obvious mechanism for the processing of the data. This is important from an identity perspective as it is the ‘assertion of sameness’ that is key to both the GDPR definition of personal data and also underpins the COEL pseudonymisation approach. In buildings we will also often have groups of users – there are the mechanisms within COEL to allocate information to groups on a basic probabilistic basis.

There are 3 types of information that we need to consider about people in this context:

- Static data These are the non-, rarely or slowly changing data that are normally used in identity systems (gender, DoB, biometrics, RFID tags etc)

- Dynamic data These are the historical, behavioural data about what a person has actually done (movements, actions etc.)

- Preference data These are the data about what the user says they have done or might do in the future or we infer they might do (social media, meta-social media etc.)

I think, in the BIM context, the Preference data would be inferred from the historical Dynamic personal data and this is where COEL can be immediately relevant.

Of the scenarios described by Toby, the most immediately applicable approach would seem to be for a BIM to be capable of creating Atoms from its own infrastructure (as a Service Provider) and parsing Atoms from other infrastructures. I would suggest that any inference about how behavioural information maps between infrastructures to understand preferences is conducted within the specific building that services will be delivered. This inferred data can be personal and will often be commercial – it need not be stored as it can be regenerated from the base data.

The dynamic behavioural data are sent by the original building to a cloud-based Data Engine – both for that Service Provider’s future use and for use by other Service Providers. When an individual interacts with the original building, they would have a local model of their Preferences built and updated from the cloud-based behavioural data. When an individual interacts with a new COEL-compliant building, the permission to access the data is negotiated and then the new building can access the cloud-based behavioural data from the original building to create its own local Preference model. This building may also be given permission to record new behavioural data against the original individual ID (or a new profile).

Important Information: The contents of this email are intended for the named addresses only and contain information which is confidential and which may also be privileged. Unless you are the named addressee (or authorised to receive for the addressee) you may not copy, use it, or disclose it to anyone else. If you received it in error, please notify us immediately at info@geneactiv.co.uk and then destroy it. Further, whilst we make efforts to keep our network free from computer viruses, etc., you do need to check this email and any attachments to it for viruses as we can take no responsibility for any viruses which might be transferred by way of this email.

Activinsights Limited, 6 Nene Road, Bicton Industrial Park, Kimbolton, Cambs, PE28 0LF, UK. A company registered in England & Wales. Registered number: 6576069

From: coel@lists.oasis-open.org <coel@lists.oasis-open.org> On Behalf Of dave.snelling@uk.fujitsu.com
Sent: 13 June 2018 16:38
To: coel@lists.oasis-open.org
Subject: [coel] FW: Friday's Call

Folks,

A bit more homework for Friday or next Friday.

Dave

From: Considine, Toby <Toby.Considine@unc.edu>
Sent: Wednesday, June 13, 2018 4:10 PM
To: Snelling, David <dave.snelling@uk.fujitsu.com>
Subject: RE: Friday's Call

Observer on the TC, so not replying to the TC…

I have a long-time interest in approaches to customized/personalized building services that preserve privacy. Much of this is based on energy usage, as described by the Fractal Microgrid model, using minimal service communications as defined by the OASI smart energy specifications. To apply policy-based directives to operate internally based on these models, I have long wondered if COEL is a path.

http://www.automatedbuildings.com/news/feb17/columns/170201110909considine.html

For such personalized systems to exist, there has to be databases of what people want, and how they want their services. These databases can either erase privacy entirely, if in the cloud, or be local to the building.

http://www.automatedbuildings.com/news/jun18/columns/180531083003considine.html

If local to the building, they must be a way to anonymize and pass to another building, by analogy, the way a Virtual Credit Card can be given to a particular vendor, and be usable only by that vendor. Such an info-BLOB would need to include some standards-based information as to what services the person wants customized, and what the experience is. It has long seemed to me the COEL is part of this picture.

With COEL moving to Committee Specification vote, are you aware of any papers discussing such models of use? As you are discussing W3C interaction, I can’t help but thinking that COEL might well travel alongside VCARD information (the updated 6350, not the original, and perhaps by reference to rfc 6715). Alternately, a system/building might advertise that it is able to support the COEL goals with these services, or a single service might indicate its importance by reference to a COEL-defined purpose.

WS-Calendar is an OASIS specification developed to support M2M schedule negotiation (not scheduling), and COEL-defined services can only be valued based on schedule. The EMIX model (which incorporates WS-Calendar) defines models for offering and pricing commodity services whose value is defined by time and location of delivery. WS-Calendar was defined with active participation of the W3C group that works on Calendar standards, and its goals required semantic mappability to iCalendar (RFC 5545, an update that was developed in parallel to WS-Calendar).

It seems that there should be an interesting ontological space in the Venn Diagram of these specifications.

From: coel@lists.oasis-open.org <coel@lists.oasis-open.org> On Behalf Of dave.snelling@uk.fujitsu.com
Sent: Wednesday, June 13, 2018 5:15 AM
To: coel@lists.oasis-open.org
Subject: [coel] Friday's Call

Folks,

After picking on Chet for being on holiday on Friday, I am on holiday on Friday. ;-)

I just got around to requesting the special ballot for approving the Committee Specification, so that won’t close until next week. If you do hold the call, perhaps keep it informal as there is nothing to do except discuss the W3C avtivity. In any case, we will talk about that on the 22^nd. Have a good weekend.

Dr. David Snelling
Fujitsu Distinguished Engineer
Program Director Artificial Intelligence
CTO Office EMEIA

Fujitsu

Mob: +44 (0) 7590-293439

Email: Dave.Snelling@UK.Fujitsu.com

Web: uk.fujitsu.com

Fujitsu is proud to partner with Action for Children

P Please consider the environment - do you really need to print this email?

Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.

coel message