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 관계를 추론할 수 있느냐는 것입니다. 두 엔드포인트 장비에 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 속성 중 하나에 대한 값으로 tag:Sensor 갖는 모든 클래스의 집합입니다.

이는 온도 센서 :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 Air(특히 brick:Air 클래스)를 측정하기 때문에 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로 형식화하는 방법에 대해 Sisyphean식으로 헤매는 대신 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 )