brick owl dl
1.0.0
Inilah inti cara saya melakukan sesuatu dan jenis inferensi/pemodelan apa yang diaktifkan
Hampir semua yang kami gunakan termasuk dalam OWL Lite kecuali properti owl:hasValue yang kami gunakan untuk mendefinisikan pemetaan 1-1 antara kumpulan tag dan nama kelas. Oleh karena itu, solusi saat ini termasuk dalam OWL DL.
Ini juga berarti kita membutuhkan seorang pemikir, tapi untungnya tidak ada yang mendukung OWL Full :). OWL-RL adalah pilihan bagus yang berfungsi dengan RDFlib.
# G is our RDFlib Graph
# apply reasoning to expand all of the inferred triples
import owlrl
owlrl . DeductiveClosure ( owlrl . OWLRL_Semantics ). expand ( G )
# get namespaces
print ( list ( G . namespaces ()))
G . query ( "SELECT ?x WHERE { ?x brick:hasTag tag:Equip }" )Kita dapat membuat serial bentuk grafik yang diperluas ke disk jika kita perlu menggunakan prosesor kueri SPARQL yang tidak mendukung penalaran.
https://brickschema.org/schema/1.1.0/Brick#owl:Class dan disusun menjadi hierarki dengan rdfs:subClassOfowl:equivalentClassskos:definitionbrick:AHU_Average_Exhaust_Air_Static_Pressure_Sensor hanyalah sebuah Average_Exhaust_Air_Static_Pressure_Sensor yang merupakan titik dari sebuah AHU.Kelas root yang telah kami definisikan adalah:
EquipmentLocationPointTagSubstanceQuantity(Hubungan adalah istilah Brick untuk Owl ObjectProperties antar instance kelas)
Pada tingkat permukaan, hubungan bekerja sama seperti di Brick asli. Semua hubungan yang sama masih ada (di mana saya ingat untuk mendefinisikannya), dan inversnya ditentukan menggunakan owl:inverseOf .
Domain dan rentang ditentukan dalam bentuk kelas. Menyatakan bahwa rdfs:range suatu hubungan adalah kelas brick:Equipment berarti bahwa objek hubungan harus berupa turunan dari kelas brick:Equipment .
Prototipe ini mencakup sub-hubungan selain hubungan. Sub-hubungan dapat digunakan sebagai pengganti hubungan super untuk menambahkan lebih banyak detail pada sifat hubungan tersebut. Satu-satunya contoh sejauh ini adalah feedsAir menjadi sub-properti dari feeds .
Sesuatu yang perlu diketahui adalah bagaimana kita dapat menyimpulkan hubungan feedsAir ; mungkin jika kedua peralatan titik akhir memiliki tag air dan hubungan feeds ? Ini mungkin sesuatu yang perlu dijelaskan secara eksplisit, bukan disimpulkan.
https://brickschema.org/schema/1.1.0/BrickTag#skos:definition Hal ini dicapai dengan mendeklarasikan kelas Brick (misalnya Air_Temperature_Sensor ) sebagai setara dengan kelas anonim, yang merupakan owl:Restriction yang merupakan perpotongan entitas yang memiliki tag tertentu.
# in turtle format
brick:Temperature_Sensor a owl:Class ;
rdfs:subClassOf brick:Sensor ;
owl:equivalentClass [ owl:intersectionOf (
[ a owl:Restriction ;
owl:hasValue tag:Sensor ;
owl:onProperty brick:hasTag
]
[ a owl:Restriction ;
owl:hasValue tag:Temperature ;
owl:onProperty brick:hasTag
]
) ] .
owl:Restriction pertama adalah himpunan semua kelas yang memiliki tag:Sensor sebagai nilai untuk salah satu properti brick:hasTag .
Ini berarti bahwa sensor suhu :ts1 dapat didefinisikan dalam dua cara berbeda dan pemikir akan menyimpulkan tiga kali lipat lainnya:
# using classes
:ts1 a brick:Temperature_Sensor
# using tags
:ts1 brick:hasTag tag:Temp
:ts1 brick:hasTag tag:Sensor
Brick sekarang mendefinisikan hierarki zat ( substances.py ) dan hierarki kuantitas ( quantities.py ). Zat dan kuantitas dapat dikaitkan dengan peralatan dan titik.
Tidak semuanya dilaksanakan. Dalam prototipe saat ini, sensor dihubungkan dengan zat dan kuantitas melalui hubungan brick:measures .
:ts1 a brick:Temperature_Sensor
:ts1 brick:measures :Air
# this implies the following
:ts1 a brick:Air_Temperature_Sensor
Kita dapat mensubklasifikasikan zat lebih lanjut untuk memberikan konteks tingkat sistem atau proses pada definisinya:
:ts1 a brick:Sensor
:ts1 brick:measures brick:Return_Air
:ts1 brick:measures brick:Temperature
# implies...
:ts1 a brick:Return_Air_Temperature_Sensor
Brick menggunakan batasan OWL untuk menyempurnakan kelas berdasarkan hubungan tersebut. Untuk contoh ini, karena :ts1 mengukur Air (khususnya kelas brick:Air ), OWL menyimpulkan sensor kita sebagai brick:Air_Temperature_Sensor .
Berikut definisinya dalam Turtle:
brick:Air_Temperature_Sensor a owl:Class ;
rdfs:subClassOf brick:Temperature_Sensor ;
owl:equivalentClass [ owl:intersectionOf ( [ a owl:Restriction ;
owl:hasValue brick:Temperature ;
owl:onProperty brick:measures ] [ a owl:Restriction ;
owl:hasValue brick:Air ;
owl:onProperty brick:measures ] ) ] .
Catatan : kami menggunakan kelas sebagai nilai di sini, yang berbeda dari Brick lainnya. Ini disebut "punning". Hal ini untuk menghindari keharusan membuat contoh zat untuk diukur oleh sensor kami dan sebagainya, namun tetap memiliki kemungkinan untuk menerapkannya di masa mendatang. Contoh zat dapat memodelkan wilayah/potongan "barang" dalam suatu tahapan proses, misalnya air yang memasuki pendingin atau wilayah udara campuran pada unit penanganan udara.
Daripada tersesat dalam perbincangan Sisyphean tentang cara memformat semuanya sebagai YAML, kami hanya menggunakan kamus Python sehingga kami tidak perlu khawatir tentang logika penguraian apa pun (yah, tidak terlalu banyak).
definitions = {
"Lighting_System" : {
"tagvalues" : [ # Lighting_System class is equivalent to the Lighting tag
( BRICK . hasTag , TAG . Lighting ),
# if you have more required tags add them as their own tuple in the list
],
# defining subclasses. This can be nested ad-infinitum
"subclasses" : {
"Lighting" : {
"subclasses" : {
"Luminaire" : {},
"Luminaire_Driver" : {},
},
},
"Interface" : {
"subclasses" : {
"Switch" : {
"subclasses" : {
"Dimmer" : {},
},
},
"Touchpanel" : {},
},
},
},
}
}
define_subclasses ( definitions , BRICK . Equipment ) Untuk saat ini, kodenya adalah dokumentasi. Lihat equipment.py , point.py , dll untuk contoh dan cara menambahkan ke setiap hierarki kelas.
Penulis: Gabe Fierro
