brick owl dlダウンロード - brick owl dlソースコードのダウンロード

brick owl dl

その他のソースコード

1.0.0

ダウンロード

レンガ

ここでは、私がどのように作業を行っているか、およびどのような種類の推論/モデリングが有効になっているかの要点を示します。

オントロジーの実装

複雑

私たちが使用しているほぼすべてのものは、タグのセットとクラスの名前の間の1対1のマッピングを定義するために使用するowl:hasValueプロパティを除いて、OWL Liteに分類されます。このため、現在のソリューションは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 クエリプロセッサを使用する必要がある場合は、グラフの展開された形式をディスクにシリアル化できます。

クラス

Brick クラスの名前空間はhttps://brickschema.org/schema/1.1.0/Brick#
クラスはowl:Classに属し、 rdfs:subClassOfで階層に配置されます。
同等のクラス (クラスのメンバーは同じ) はowl:equivalentClassプロパティに関連付けられます。
skos:definitionで与えられる定義
必要に応じて、機器に合わせたクラスを削除しています。
- たとえばbrick:AHU_Average_Exhaust_Air_Static_Pressure_Sensorは、AHU のポイントであるAverage_Exhaust_Air_Static_Pressure_Sensorにすぎません。
クラスはタグのセットに相当します (以下を参照)

定義したルートクラスは次のとおりです。

Equipment
Location
Point
Tag
Substance
Quantity

人間関係

(関係とは、クラスのインスタンス間のフクロウの ObjectProperties を表すブリック用語です)

表面レベルでは、関係は元のブリックと同じように機能します。すべて同じ関係がまだ存在しており (定義を覚えていたところ)、それらの逆関係はowl:inverseOf使用して定義されています。

ドメインと範囲はクラスに関して定義されます。リレーションシップのrdfs:rangeがクラスbrick:Equipmentであるということは、リレーションシップのオブジェクトがbrick:Equipmentクラスのインスタンスである必要があることを意味します。

このプロトタイプには、関係に加えてサブ関係が含まれています。サブ関係をスーパー関係の代わりに使用して、その関係の性質をさらに詳細に追加できます。これまでの唯一の例は、 feedsAir feedsのサブプロパティであることです。

理解すべきことは、 feedsAir関係をどのように推測できるかということです。おそらく 2 つのエンドポイント機器にairとfeeds関係がある場合でしょうか?これは、推測するのではなく、明示的に指定する必要があるものかもしれません。

タグオントロジーの名前空間はhttps://brickschema.org/schema/1.1.0/BrickTag#
Haystack タグを使用し、それらを含む独自のセットを定義します
タグには定義が必要ですが、これはまだ含まれていません
タグのセットにはクラス名と 1 対 1 のマッピングがあります
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 brick:hasTagプロパティの 1 つの値としてtag:Sensor持つすべてのクラスのセットです。

これは、温度センサー:ts1 2 つの異なる方法で定義でき、推論器が他のトリプルを推論することを意味します。

 # 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クラス)を測定するため、OWLはセンサーをbrick:Air_Temperature_Sensorとして推論します。

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 ] ) ] .

注: ここでは値としてクラスを使用していますが、これは Brick の他の部分とは異なります。これを「パニング」といいます。これは、センサーが測定する物質のインスタンスなどを作成する必要を避けるためですが、将来これを実装する可能性は留保されています。物質のインスタンスは、プロセスの段階における「物質」の領域/塊、たとえば冷却装置に入る水や空気処理ユニットの混合空気領域をモデル化できます。

Python フレームワーク

すべてを YAML としてフォーマットする方法というシシュフェの自転車小屋に迷うのではなく、Python 辞書を使用するだけなので、(まあ、それほど多くはありませんが) 解析ロジックについて心配する必要はありません。

 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 )