brick owl dl
1.0.0
Hier ist der Kern meiner Vorgehensweise und welche Arten von Inferenz/Modellierung aktiviert sind
Fast alles, was wir verwenden, fällt unter OWL Lite, mit Ausnahme der Eigenschaft owl:hasValue , mit der wir eine 1:1-Zuordnung zwischen Tag-Sets und Klassennamen definieren. Aus diesem Grund fällt die aktuelle Lösung unter OWL DL.
Das bedeutet auch, dass wir einen Reasoner brauchen, aber zum Glück keinen, der OWL Full unterstützt :). OWL-RL ist eine gute Wahl, die mit RDFlib funktioniert.
# 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 }" )Wir können die erweiterte Form des Diagramms auf die Festplatte serialisieren, wenn wir einen SPARQL-Abfrageprozessor verwenden müssen, der keine Argumentation unterstützt.
https://brickschema.org/schema/1.1.0/Brick#owl:Class und werden mit rdfs:subClassOf in einer Hierarchie angeordnetowl:equivalentClass verknüpftskos:definition angegebene Definitionenbrick:AHU_Average_Exhaust_Air_Static_Pressure_Sensor nur ein Average_Exhaust_Air_Static_Pressure_Sensor , der ein Punkt einer AHU ist.Die von uns definierten Stammklassen sind:
EquipmentLocationPointTagSubstanceQuantity(Beziehungen sind der Brick-Begriff für Owl ObjectProperties zwischen Instanzen von Klassen)
Auf der oberflächlichen Ebene funktionieren die Beziehungen genauso wie im ursprünglichen Brick. Die gleichen Beziehungen existieren immer noch (wo ich daran gedacht habe, sie zu definieren), und ihre Umkehrungen werden mit owl:inverseOf definiert.
Domänen und Bereiche werden anhand von Klassen definiert. Die Angabe, dass der rdfs:range einer Beziehung zur Klasse brick:Equipment gehört, bedeutet, dass das Objekt der Beziehung eine Instanz der Klasse brick:Equipment sein sollte.
Dieser Prototyp umfasst neben Beziehungen auch Unterbeziehungen. Anstelle der Superbeziehung können Unterbeziehungen verwendet werden, um die Art dieser Beziehung detaillierter darzustellen. Das einzige Beispiel bisher ist, dass feedsAir eine Untereigenschaft von feeds ist.
Wir müssen herausfinden, wie wir auf die feedsAir -Beziehung schließen können. Vielleicht, wenn die beiden Endpunktgeräte über das air Tag und eine feeds -Beziehung verfügen? Dies kann etwas sein, das explizit spezifiziert und nicht abgeleitet werden muss.
https://brickschema.org/schema/1.1.0/BrickTag#skos:definition angegeben werden Dies wird erreicht, indem eine Brick-Klasse (z. B. Air_Temperature_Sensor ) als Äquivalent zu einer anonymen Klasse deklariert wird, bei der es sich um eine owl:Restriction handelt, die die Schnittmenge von Entitäten darstellt, die bestimmte Tags haben.
# 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
]
) ] .
Die erste owl:Restriction ist die Menge aller Klassen, die tag:Sensor als Wert für eine ihrer brick:hasTag -Eigenschaften haben.
Das bedeutet, dass ein Temperatursensor :ts1 auf zwei verschiedene Arten definiert werden könnte und der Reasoner die anderen Tripel ableiten würde:
# using classes
:ts1 a brick:Temperature_Sensor
# using tags
:ts1 brick:hasTag tag:Temp
:ts1 brick:hasTag tag:Sensor
Brick definiert jetzt eine Hierarchie von Stoffen ( substances.py ) und eine Hierarchie von Mengen ( quantities.py ). Stoffe und Mengen können auf Geräte und Punkte bezogen werden.
Nicht alles davon wird umgesetzt. Im aktuellen Prototyp werden Sensoren über die brick:measures -Beziehung mit Stoffen und Mengen in Beziehung gesetzt.
:ts1 a brick:Temperature_Sensor
:ts1 brick:measures :Air
# this implies the following
:ts1 a brick:Air_Temperature_Sensor
Wir können Stoffe weiter in Unterklassen unterteilen, um ihren Definitionen einen Kontext auf System- oder Prozessebene bereitzustellen:
:ts1 a brick:Sensor
:ts1 brick:measures brick:Return_Air
:ts1 brick:measures brick:Temperature
# implies...
:ts1 a brick:Return_Air_Temperature_Sensor
Brick verwendet OWL-Einschränkungen, um Klassen basierend auf solchen Beziehungen zu verfeinern. Da :ts1 in diesem Beispiel Luft misst (insbesondere die Klasse brick:Air “), leitet OWL unseren Sensor als brick:Air_Temperature_Sensor ab.
So sieht die Definition in Turtle aus:
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 ] ) ] .
Hinweis : Wir verwenden hier Klassen als Werte, was sich vom Rest von Brick unterscheidet. Dies nennt man „Wortspiel“. Dadurch soll vermieden werden, dass Instanzen von Substanzen erstellt werden müssen, die unsere Sensoren messen usw., es bleibt jedoch die Möglichkeit, dies in Zukunft umzusetzen. Instanzen von Substanzen können Regionen/Stücke von „Dingen“ in einer Phase eines Prozesses modellieren, z. B. das in einen Kühler eintretende Wasser oder den Mischluftbereich einer Lüftungsanlage.
Anstatt uns in der Sisyphos-Ära zu verlieren, wie man alles als YAML formatiert, verwenden wir einfach Python-Wörterbücher, sodass wir uns nicht um irgendeine (na ja, nicht so große) Parsing-Logik kümmern müssen.
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 ) Im Moment ist der Code die Dokumentation. Schauen Sie sich equipment.py , point.py usw. an, um Beispiele zu finden und zu erfahren, wie Sie die einzelnen Klassenhierarchien ergänzen.
Autoren: Gabe Fierro
