brick owl dl
1.0.0
فيما يلي جوهر كيفية قيامي بالأشياء وأنواع الاستدلال/النمذجة التي يتم تمكينها
يقع كل ما نستخدمه تقريبًا ضمن OWL Lite باستثناء خاصية owl:hasValue التي نستخدمها لتحديد التعيين 1-1 بين مجموعات العلامات وأسماء الفئات. ولهذا السبب، يقع الحل الحالي ضمن OWL DL.
وهذا يعني أيضًا أننا بحاجة إلى مُفكر، ولكن لحسن الحظ ليس شخصًا يدعم OWL Full :). يعد OWL-RL خيارًا رائعًا يعمل مع 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 }" )يمكننا إجراء تسلسل للنموذج الموسع للرسم البياني على القرص إذا كنا بحاجة إلى استخدام معالج استعلام SPARQL الذي لا يدعم المنطق.
https://brickschema.org/schema/1.1.0/Brick#owl:Class ويتم ترتيبها في تسلسل هرمي باستخدام rdfs:subClassOfowl:equivalentClassskos:definitionbrick:AHU_Average_Exhaust_Air_Static_Pressure_Sensor هو مجرد Average_Exhaust_Air_Static_Pressure_Sensor الذي يمثل نقطة من AHU.الفئات الجذرية التي حددناها هي:
EquipmentLocationPointTagSubstanceQuantity(العلاقات هي مصطلح لبنة لخصائص كائن البومة بين مثيلات الفئات)
على المستوى السطحي، تعمل العلاقة بنفس الطريقة التي كانت تعمل بها في لعبة Brick الأصلية. لا تزال جميع العلاقات نفسها موجودة (حيث تذكرت تعريفها)، وقد تم تحديد معاكساتها باستخدام owl:inverseOf .
يتم تعريف المجالات والنطاقات من حيث الفئات. الإشارة إلى أن rdfs:range هو من فئة brick:Equipment يعني أن كائن العلاقة يجب أن يكون مثيلًا للفئة من brick:Equipment .
يتضمن هذا النموذج الأولي علاقات فرعية بالإضافة إلى العلاقات. يمكن استخدام العلاقات الفرعية بدلاً من العلاقة الفائقة لإضافة المزيد من التفاصيل إلى طبيعة تلك العلاقة. المثال الوحيد حتى الآن هو كون feedsAir ملكية فرعية feeds .
الشيء الذي يجب اكتشافه هو كيف يمكننا استنتاج العلاقة feedsAir ؛ ربما إذا كان جهازا نقطة النهاية يحتويان على علامة air وعلاقة feeds ؟ قد يكون هذا شيئًا يحتاج إلى تحديد صريح بدلاً من الاستدلال عليه.
https://brickschema.org/schema/1.1.0/BrickTag#skos:definition يتم تحقيق ذلك عن طريق الإعلان عن فئة Brick (على سبيل المثال Air_Temperature_Sensor ) كمكافئ لفئة مجهولة، وهي owl:Restriction وهي تقاطع الكيانات التي لها علامات معينة.
# 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 هي مجموعة من كافة الفئات التي تحتوي على tag:Sensor كقيمة لأحد خصائصها من brick:hasTag .
هذا يعني أنه يمكن تعريف حساس درجة الحرارة :ts1 بطريقتين مختلفتين وسيستنتج المسبب الثلاثيات الأخرى:
# using classes
:ts1 a brick:Temperature_Sensor
# using tags
:ts1 brick:hasTag tag:Temp
:ts1 brick:hasTag tag:Sensor
يحدد Brick الآن تسلسلًا هرميًا للمواد ( substances.py ) وتسلسلًا هرميًا للكميات ( quantities.py ). يمكن أن ترتبط المواد والكميات بالمعدات والنقاط.
ولا يتم تنفيذ كل هذا. في النموذج الأولي الحالي، ترتبط أجهزة الاستشعار بالمواد والكميات من خلال العلاقة بين brick:measures .
:ts1 a brick:Temperature_Sensor
:ts1 brick:measures :Air
# this implies the following
:ts1 a brick:Air_Temperature_Sensor
يمكننا إضافة مواد فرعية لتوفير سياق على مستوى النظام أو العملية لتعريفاتها:
:ts1 a brick:Sensor
:ts1 brick:measures brick:Return_Air
:ts1 brick:measures brick:Temperature
# implies...
:ts1 a brick:Return_Air_Temperature_Sensor
يستخدم Brick قيود OWL لتحسين الفئات بناءً على مثل هذه العلاقات. في هذا المثال، نظرًا لأن :ts1 يقيس الهواء (على وجه التحديد brick:Air class)، يستنتج OWL المستشعر الخاص بنا على أنه brick:Air_Temperature_Sensor .
إليك ما يبدو عليه التعريف في السلحفاة:
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 ] ) ] .
ملاحظة : نحن نستخدم الفئات كقيم هنا، وهو ما يختلف عن بقية Brick. وهذا ما يسمى "العقاب". وذلك لتجنب الاضطرار إلى إنشاء نماذج من المواد لأجهزة الاستشعار لدينا لقياسها وما إلى ذلك، ولكن مع الاحتفاظ بإمكانية تنفيذ ذلك في المستقبل. يمكن لمثيلات المواد أن تمثل مناطق/أجزاء من "الأشياء" في مرحلة من العملية، على سبيل المثال، الماء الذي يدخل إلى المبرد أو منطقة الهواء المختلط لوحدة معالجة الهواء.
بدلاً من الضياع في فوضى الدراجات السيزيفية حول كيفية تنسيق كل شيء كـ YAML، نحن نستخدم قواميس بايثون فقط لذلك لا داعي للقلق بشأن أي منطق تحليل (حسنًا، ليس كثيرًا).
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 ) في الوقت الحالي، الكود هو الوثائق. انظر إلى equipment.py و point.py وما إلى ذلك للحصول على أمثلة وكيفية الإضافة إلى كل من التسلسلات الهرمية للفصل.
المؤلفون: غابي فييرو
