[Top] [All Lists]

Re: [ontology-summit] Clinic proposal: Verification and quality measurem

To: Ontology Summit 2013 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Joel Bender <jjb5@xxxxxxxxxxx>
Date: Fri, 8 Mar 2013 22:11:24 +0000
Message-id: <A44EF996-182C-425C-BBB6-C5DAB56ED37F@xxxxxxxxxxx>
Victor,    (01)

> That can be interesting collaboration. It happens that we know people in 
>Moscow who are leading developers for BACnet, as far as we know.    (02)

They probably have heard of me, and I of them.  The world of BACnet software 
developers is not huge, my boss is Mike Newman who started the standards 
development effort with ASHRAE after becoming frustrated with writing yet 
another protocol driver for our Energy Management and Control System (EMCS).  
After 13 years of committee meetings it was finally published as BACnet.  We've 
been in this from the beginning.    (03)

> If we plan to bring ISO 15926 into this picture, we've to ask the first 
>question - what are the data we are going to integrate. For a
> new domain it is always better to choose some particular dataset which is 
>prepared in one system and then used in another one.    (04)

Exactly correct.  My proposal is specifically limited to BACnet, but doing it 
in a way that seamlessly integrates with the others.  There is at least a 
conceptual matching between BACnet "analog input objects" and MODBUS "input 
registers" and whatever ISO 15926 describes, they are all connected to very 
similar hardware like 4-20mA temperature transmitters.    (05)

> It can be some architectural or equipment data which is required by BACnet 
>control loop developers, for example.    (06)

It could be, but that's more than what I want to take on right now (see the 
BAFL reference in the other thread).  The lowest hanging fruit is an 
alternative encoding of the BACnet Electronic Protocol Implementation 
Conformance Statement (EPICS) which describes what objects and services a 
device supports.  A specific EPICS file for a device could be validated against 
the ontology, and then it can be imported into all kinds of RDF and LOD 
repositories.    (07)

Note that the EPICS file is for a family of controllers from a vendor, but is 
insufficient for knowing how the one on my wall is wired to my air conditioning 
unit (and the one in my office is pneumatic, but that's beside the point).  
Specifying how "analog input 1" of my controller is used in the measurement 
process of my "air conditioner discharge temperature" is the next bridge 
between the BACnet world and the sensing world.  I'll need all kinds of help 
with that, what I've called the "extrinsic challenges" in my proposal.    (08)

> Or in other direction - some system data developed in BACnet environment and 
>required by other speciality.    (09)

There is some kind of "what you call a register is what I call an object" 
mapping at some layer, data exchange problems are usually solved by protocol 
gateways that typically don't know anything about what kind of data they are 
helping to exchange.    (010)

> Don't know enough to think a realistic example.    (011)

Oh, that's easy!  A BACnet electric meter that wants to send load information 
to an automated demand response system [1].  That is also outside the scope of 
what I'm trying to do in the first pass, but I do not want to make any OWL 
modeling mistakes that make it hard to build on.  I have the advantage of 
having a very specific set of requirements of what the OWL model has to 
describe, because that is already in the BACnet standard.    (012)

[1] <http://openadr.lbl.gov/>    (013)

Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013  
Community Portal: http://ontolog.cim3.net/wiki/     (014)
<Prev in Thread] Current Thread [Next in Thread>