>> I guess by now you've heard about Digital Twins.
We have a service here at Microsoft called
Azure Digital Twins that allows you to manage
lots of data coming from different sources and use
graphs to query that data in a very smart way.
But who better than Rick here from
Willow to tell us all about Azure Digital Twins,
and how important are these graph queries and how they
can really help you navigate this complex datasets,
and that's today on The IoT Show.
[MUSIC]
>> Hi everyone, thanks for watching the IoT Show.
I'm Olivier your host and today we will talk about
graph queries in the context of Azure Digital Twins,
and for that we have Rick from Willow. Hey Rick, how are you?
>> Hello, I'm doing well.
>> Rick, tell us a bit about yourself before we're
getting to that very interesting topic.
Who are you? What are you doing for a living these days?
>> Yeah, so I'm the Product and Technical Lead at
Willow for our Microsoft partnership,
so I get the joy and pleasure working closely with a lot
of the Microsoft IoT Product team,
as well as our internal Willow product team and helping us build
amazing products on top of the Azure ecosystem.
>> For those who don't really know what's going on
here, what does Willow do?
What is your realm,
and what is your expertise?
>> Willow is the digital twin for the built world,
so we provide amazing products that leverage
digital twin technology pulling in data from
IoT sources and actioning the data through intelligent workflows,
and we deploy across many different industries real estate,
rail, mining smart cities and a number of others.
>> Yeah. So if I were to say,
you guys are at the edge of
that new trendy thing that is called the metaverse,
that we do called the metaverse.
I had to place it somewhere.
But in a nutshell,
you were an early adopter
of Azure Digital Twins for that very reason,
so you are in that business of merging
data from different sources and try
and make sense of that data to
offer it as a service to your customers,
so someone wants to manage a building,
they need to have information from
the various devices that are in that building,
offer in an intuitive and functional UI and
interaction 2D operators to
dependents to whoever is around this building,
and so that's a complicated space.
Well, how's it being so far using Azure Digital Twins,
the product's been out for not so long and you guys have
been on the very first private preview versions of that.
How are things going with the product?
>> It's been going well. As you mentioned,
when the product was released into public preview last summer,
we did an assessment
of Azure Digital Twins to make sure that it would be
fit for purpose for delivering value
to our product and our customers,
and it's been great.
As you mentioned, one of the key things for us is it has been
a challenge across the industry
in bringing together disparate data sources.
Everyone knows that there's value in it it's
just the journey of bringing those together both
in implementation and solutioning
is a big challenge and the promise
of digital twin technology like
Azure Digital Twins provides with that underlying graph database,
the ontology what helps you normalize data across
disparate datasets really unlocks incredible potential
and it's worth coming up with in the use cases on a daily basis
and ultimately driving value for the end customers.
>> You already alluded to a couple of these but there are
other graph databases out there that will allow you to
do similar things that you can do with
Azure Digital Twins as a service today,
that allow you to create
these twins where they have set of properties
for group of things and then the relationship in between them,
and a graph engine allows you to query that data,
but what are the specific things that stand out for you in
Azure Digital Twins that made you
pick it as your area preferred data piece here?
>> Yeah, it's a great question.
We did a pretty thorough analysis
and a couple things that jump out
were Azure Digital Twins
is a platform as a service as opposed to a database.
Some of the things that we get to take advantage of
there are built-in eventing,
being native IoT,
so things like ingesting natively IoT sources.
But really the big one that jumped out to me was
it's knowledge or having treating ontologies first.
A typical off-the-shelf graph database
can be used to model anything in the world,
or you can use it to
develop social media connections or whatever,
but for us being able to load
in ontologies regardless of the domain whether
it's real estate or rail or whatnot really
makes Azure Digital Twins easy to work with
its load in your ontology start creating twins and relationships,
and you're off and running.
>> Got it. Ontology and
things that are very interesting specific,
so when you are a software developer,
you might not be super aware of data models
and so on that are proper to a specific industry.
Then you have the graph queries themselves and
we'll talk more about these ones and how important they are.
Having the service that allows you to
access that data coming from various sources,
and that is modeled in different ways,
is super powerful but for people
like me were not super aware of the details,
what are the key challenges and why are
graph query is useful and important?
>> Azure Digital Twins as I mentioned when
we started working with it last summer
allows you to create
incredibly accurate representations of the real world,
and so you create twins that are nodes,
relationships connecting those twins together,
and you can do that very granularly.
The challenge comes then when you want to fetch that information
back out of the graph by asking a question or a query.
For us it was actually a challenge.
We realized that we're creating more nodes,
more relationships than we could actually answer questions for,
even though we knew we had questions
that our products wanted to ask.
We worked closely with the team,
with Azure Digital Twins,
and as of about a month ago,
they released a new match query statement
which is essentially based off of
the open Cypher Query Language if anyone is
familiar with with some of the graph query technologies,
and it allows us to answer some really tough questions,
like things that are variable hops away in the graph,
or based off of a model or an ontology.
>> Let's look at some examples of these specific queries,
these new types of queries a lot you do.
Let's discuss as well what are the differences,
and what would happen if you didn't have them,
if you were working with regular SQL type of queries?
>> Yeah, it's always great to look at examples.
I've got a couple here.
The first one is really geared around,
let's say you're trying to develop a query for a rule.
Let's say you want to write a rule and you need
to be able to pull some twins out of the graph.
Traditionally, what you'll need to do
is basically write out
every rule line by line and do a bit of an ID mapping,
this ID matches to this ID.
In this scenario have up here on the screen,
you might say occupancy sensor
located in this room that's connected to
a lighting control system needs to be
able to control the thermostat that's also in the room,
but it's connected to the BMS or HVAC system,
so two completely disparate systems,
but you want to develop a smart rule that allows you
to save some energy if some leaves the room.
That's very labor-intensive and what we're able to
do with a graph query is something
like a statement that looks on the right,
which is a natural language way to describe that,
and in the next slide I'll actually show
you how we actually leverage the match
a query statement in Azure Digital Twins to write that out.
Here's a little bit of under the hood.
Imagine each each box here is a node,
or a twin in our graph and
each line with an arrow is a relationship,
and so the first part of this query is,
hey this occupancy sensor has changed to vacant.
I'm up here on the upper right-hand corner.
We want that to be able to control the set point for the room.
The first part of the statement
was for that occupancy sensor I want to
find the related room that it's serving,
and so we traverse the graph and I've
written out the actual query statement in the bottom right here,
but we essentially traverse the graph to
find the room that it's a part of.
In the next part of the statement is,
for that room let's find which terminal unit conditions it.
What I love about this example is you can
see here I just match on a fan powered box,
but in my query I actually said to find a Terminal Unit.
I introduced a little snippet here in
the bottom left which is our ontology which is to say,
the query will actually understands
inheritance of your modeling anthology.
This is a super powerful example where
we have a twin of a fan power box,
but the query said find me any terminal unit and I
found the proper fan powered box.
>> Is it fair to say that you will
have to go through many hoops if you wanted to
do that with regular database and regular queries right?
>> Yeah, the power of the twin here is that you're
literally just traversing and writing
your query exactly how the data is structured,
and in a traditional kind
of SQL or relational database world you end up
finding the need to create a lot of
many-to-many join tables and
it just gets very messy very quickly,
and as you try to take that solution and make it scalable
for different implementations it becomes very challenging.
This just very beautifully allows you to express the question.
>> Yeah. Another thing to mention,
once again you a little related to that,
but the data we're seeing as we were saying
it comes from different manufacturers of
different types of devices and you still are able to access
that information from these various sources
seamlessly without having to change your queries,
or adapt the twin itself.
It's just a hey, there's that twin is there and its properties,
its relationships are defined in
my graph and I can just access that, it's pretty powerful.
Do you have other examples?
>> One more that I'd like to show,
and this is where we're
heading a lot with our product which is the ability to search
and especially getting into things like
natural language search and chat and everything is this idea
where you want to ask a question of your environment,
you don't always know ahead of time what that question might be.
Up on the screen I've got some question types,
or search classes that we might be searching for,
and these are all very challenging in a traditional non-graph or
non-graph query ability type
of scenario which is like
understand siblings searched by variable depth,
search by a distance shortest paths.
These are all very challenging problems to solve for,
but the graph query allows you to do that.
If we look at a couple examples here of a variable depth search,
we might want to say something like,
find me all air handling units that are located on the roof.
In a relational model we'd
issue that query and we might find five results,
but the actual correct answer in this case I'm showing is 83,
because we have a variable hop there
might be an air handling unit that's in a penthouse room,
that itself is on the roof and so it found
some additional air handling units which matched the query
>> I see. In the first case you're
pretty static basically in terms of what the structure of
the data is expected to be when you're using the graph query
you can actually access a more dynamic model,
or a more dynamic architecture here.
>> Yeah, and there's different scenarios like
many of our customers have
different levels of fidelity in terms
of their understanding of their environment.
This with a single query allows us to be able to access
both low fidelity and high fidelity implementations very easily.
>> That's a huge difference though,
because like to first one literally gives you a false results.
>> Yeah it does.
That's what's very powerful about that is it can be
misleading and this is
just to show a similar under the hood of what's happening,
as you find maybe three air
handling units in my little mini subgraph here.
The first thing that you're going to ask is to find out which ones
are located on the roof and in the upper left here,
you can see that it actually takes two hops to say,
yes this is in fact on the roof,
but the middle air handling unit
here is actually just one hop away.
Both of them are valid responses that you would
need that variable hop query to answer.
>> Yeah. Once again,
I'll bring it back to the traditional query,
you would have to know in advance that there are potentially units
there are in a room on the roof for that query to work.
Anyway, so that's part of the power of this graph queries too.
These hops are done automatically.
You basically have this query that is
written there once and it will figure it out, right?
>> Correct. In the match query statement,
you essentially include an asterisk.
I'll show show an example
of what that looks like on the next slide here,
but by including the asterisk that's you telling
the query engine to basically
dynamically hop a certain fixed number of amounts,
and it will keep traversing until it finds a match.
>> Nice of it.
>> Yeah, if we have time I get excited about this example,
because it introduces a new dataset.
What we have here is a question
that you might want to ask which is,
find which tenant leases
space on floors served by a particular water heater?
You may be needing to ask this question
because you need to do service on the water heater,
there's been a complaint to an issue that I'm not getting
hot water in a certain restroom,
and so I need to do service on it,
but before doing service I want to be able to
notify the tenants that are going to be affected,
which seems like an easy question,
but oftentimes a water heater unit may be installed
six floors up centrally from
the actual restaurants that it's serving.
Here in my my graph,
I'm going to start with the water heater node.
I'm going to ask the question,
find assets that it feeds?
I traverse the graph again until I
match on several sinks in a shower,
and the next part of my query which
again is written out in the bottom left here and you'll
see some asterisks involved with the dynamic hops is,
find which floors those are located on?
Again, we're doing a dynamic hop where in
some cases it takes one hop some case two,
and we find out that Level 4 and Level
5 are being served by this water heater.
Then the last part of the statement
is pulling in the leasing data.
This is where I mentioned a really cool use case of,
I know leases and whose leasing which
spaces and so I'm actually going to find which
companies are leasing space on that level which again
is traversing another three or four nodes in the graph.
>> Not only is it traversing nodes on the graph,
but once again I repeat,
the data is placed in different areas,
like the tenants who's renting the spaces is not an information
that the Building Management ruble company knows about,
and so that's something that through Digital Twins and
through that graph was put together,
put in a relationship and now is able to be accessed through
these queries for the applications
to offer an operation that is seamless.
>> Yeah. We've got a analytics team that's
constantly building these queries and producing BI charts etc.
They love this because they're able to write a single query,
again that applies to, in our product,
can apply to many different scenarios
depending on the fidelity of the graph.
>> Nice, love it. Well first of all Rick,
thanks for coming over here because that's great that you came and
shared your perspective on graph queries,
how important they are, and how
Azure Digital Twins is working for you guys.
I know you have a repo that will help
people if they don't trust you right here.
They can go and check it out on their own,
so that's the link below.
Can you just walk us through real quick through
that repos so that they know what to expect?
>> Yeah, absolutely. All of
our ontologies are open-sourced and we work
closely with the Azure team
on adopting their open source ontologies,
and so this is just an example of our real estate
ontology open Digital Twins building.
In this page, it has got read me about how to get
started working with it understanding the datasets.
You can see here to click here and find out more
about the real estate core ontology that were built upon.
This is a great resource both internally
for Willow employees as well as all of our customers,
because you can understand the types
of datasets that we work with.
We even have some really amazing examples of what
we just saw which are samples of different scenarios,
and this really helps you understand how
different twins are connected and interacting with each other,
and really allows you to shape and
form some of those queries that we looked at.
>> Nice, fantastic.
Rick, I think it says it all.
That's perfect. Go check out the GitHub repo down there.
Hope to see you soon again on the show Rick,
because I know you have way more to share about Willow,
what you're doing in Digital Twins in general.
Everyone, thanks watching the show and see you soon.
>> Thank you.
[MUSIC]