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)
Joel
[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)
|