온톨로지 기본 사항을 이해하려고합니다. 여기 예입니다 :온톨로지의 클래스/인스턴스
내 문제는 이해입니다 "2009 VW CC"는 (자동차 모델로서) 무엇입니까? 온톨로지에서 제품 모델을 하위 클래스로 만들면 갑자기 온톨로지가 수천 개의 하위 클래스로 부 풀리게됩니다. 그것은 불필요한 것입니다. 동시에 우리는 "2009 VW CC"가 인스턴스라고 말할 수 없습니다. 적어도 클래스의 중요한 인스턴스는 아닙니다.
정규 인스턴스와 재질 (고유 한 실제 개체)을 구별하는 것이 합리적입니까?
반면에 두 인스턴스가 다른 성격의 인스턴스 인 경우 인스턴스가 비 클래스의 속성/관계를 상속 할 수 있습니까?
나는 그것이 달려 있다고 말하는 것을 싫어하지만, 그것은 달려있다.
세계의 모든 단일 차량을 모델링해야하고 (예 : "타이어 교체"와 같이 모델별로 매우 다른 프로세스) 호출 할 수있는 방법이 필요한 경우 그렇습니다. 당신의 현실 세계 상황도 너무 부풀어 오르기 때문에 많은 비 대한 수업을해야합니다.
archetypal cars의 사진 데이터베이스를 갖고 싶지만 이웃 사람의 인스턴스 사진이든 자매의 인 스턴스 사진이든 상관없이 차를 찍지 않으면 맨 아래 계층을 드롭 할 수 있습니다. "2009 VW CC"는 다른 모델의 클래스이기도 함에도 불구하고 인스턴스가 될 수 있습니다.
아니면 진정한 서브 클래스로 만들지 않아도됩니다. 간단한 참조로 충분할 수 있습니다. 예를 들어 보험 회사는 많은 자동차 모델과 연도 목록을 알고 있지만 개발자는 각각에 대해 하나의 하위 클래스를 작성하지 않습니다. 대신, 그들은 한 행이 2009 VW CC를 대표 할 수있는 자동차 모델의 데이터베이스를 가지고 있습니다. 자동차 보험에 가입하면 "2009 VW CC"인스턴스에 대한 참조로 "보험 자동차"인스턴스가 생성됩니다.
이것은 "is-a '관계에 대한 상속 사용"을 엄격하게 따르지 않지만 모든 자동차 유형에 대한 작업은 동일합니다. 변경되는 매개 변수 (예 : 연간 보험 가격) 새 자동차 모델은 코드가 아닌 데이터베이스에 기록됩니다.
여기서 차 모델의 차이점을 자동차의 동일한 메소드에 대한 매개 변수로 모델링 할 수 있다는 가정이 있습니다.
(단, iPhone 회사가 전화 회사 웹 사이트를 통해 제공되기 시작했을 때 클래스 모델이 파손되었음을 발견했습니다. 웹 사이트는 수십 개의 브랜드와 모델을 한 페이지에서 처리하는 것처럼 보였습니다. 전화 및 그 기능에 대한 데이터베이스 - 그리고 아이폰 모델을 다루기위한 특별한 페이지가 필요할 것입니다. 아마도 iPhone 판매의 일부 측면을 지원하기 위해 새로운 특수 방법이 필요했을 것입니다. 자동 판매 데스크는 "전화를 사기 위해 1을 누르십시오. .2를 눌러 iPhone을 구입하십시오. ")
당신은 거꾸로 가지고 있습니다.
2009 VW CC은 클래스 car에서 상속됩니다. 그러므로 2009 VW CC은 car을 알아야하지만 car은 2009 VW CC을 알 필요가 없습니다. 실제로 우리는 종종 "서브 클래스"라는 용어를 사용하지만, car은 서브 클래스에 대해 아무것도 모릅니다.
더 흥미로운 점은 객체가 다른 객체에서 직접 상속하는 프로토 타입 상속 (자바 스크립트에서와 같이)을 고려하는 경우입니다 (2009 VW CC이 이웃의 2009 VW CC의 특성을 상속 받았다고 상상해보십시오). 실제로 이것이 구현되는 방법은 새로운 객체가 상속받은 객체에 대한 비밀 포인터를 가지고 있다는 것입니다. 이 비밀 포인터에 대해 생각해 보면 원래 객체가 부풀어 오르게되지 않는 것을 볼 수 있습니다.
다중 상속과 긴 패밀리 트리가 혼란스러운 구조로 이어질 수 있다고 제안한다면, 나는 당신에게 동의 할 것입니다.
두 번째 단락에 동의하지만 SODA가 동의하지 않거나 거슬러 올라가는 것을 볼 수 없습니다. 나는 그가 다중 상속 또는 긴 가계도를 제안하는 곳을 보지 못한다. 그는 차 밑에있는 와이드 (WIDE) 가계도가 걱정됩니다. – Oddthinking
그는 클래스가 서브 클래스를 알아야한다고 생각하고 있습니다. 이것은 거꾸로입니다. 오직 서브 클래스 만 클래스에 대해 알아야합니다. – tzenes
감사합니다. 이들은 훌륭한 아이디어입니다. 실제 생활과 같이 보이기 때문에 우리가 구조를 관리 할 수 있다면 제품 (제품 모델의 의미에서)이 모든 인스턴스이며 훨씬 더 구체적인 속성을 가진 더 구체적인 인스턴스를 가질 수 있다고 말할 수 있습니다. –
나는 Oddthinking에 정말로 동의합니다. 게다가, 차 모델을 수업으로 필요로한다면, "갑자기 당신의 온톨로지가 수천 개의 자동차 하위 클래스로 부풀어 오른다"는 것이 실제로 문제가되지는 않습니다. 왜 그럴까요? 방금 개인 대신 클래스를 정의하면 '추상적'온톨로지, 기본 클래스 및 '구체적인'온톨로지가 있고 실제 상황의 특정 상황을 나타내는 클래스가있을 수 있습니다. 이것은 OOP가 아니며 실제로 인스턴스와 클래스 사이에 다소있는 수천 개의 클래스를 정의하는 것은 큰 개념이 아니며 개념적으로는 아무도이를 '비 대한'또는 다른 방식으로는 이상한 것으로 간주하지 않습니다. 사실, 그들은 나의 분야 (생명 과학, 우리가 일반적으로 우리 몸의 단백질 P53에 관심이 없기 때문에 P53이 클래스이기 때문에 관계형 데이터베이스에서 레코드를 모델링하는 데에도 사용됩니다) .
Virtuoso와 같은 도구가 몇 가지 클래스 및 많은 인스턴스의 상황에 맞게 최적화되어있는 것을 제외하고는 내 경험이 다릅니다. 실제로 Virtuoso의 수많은 클래스를 인스턴스로 전환하면 성능이 크게 향상되었습니다. 자, 그럼, 복잡해 ...
나는 자동차 (또는 그 문제에 대한 모든 제품)의 모든 사례를 모델링하려고하지는 않지만, 내 애플리케이션에서이를 수행 할 수있는 방법을 제공하고자한다. 예를 들어, 제품이 한정판으로 출시되거나 충분히 독특하거나 맞춤화 된 제품 인 경우. –
그런 다음 하이브리드 모델이 적절할 수도 있습니다. Standard_Car는 Car에서 상속받으며 지원하는 여러 모델의 데이터베이스에 대한 참조를가집니다. Custom_Car는 Car에서 상속되며 자체에는 각기 다른 유형의 자동차에 대한 하위 클래스가 있습니다.이 하위 클래스는 코드에서 비용이 많이 드는 모델링 단계를 수행하기에 충분하고 중요합니다. 이웃의 자동차는 그 참신함에 따라 Standard_Car의 인스턴스이거나 자동차의 사용자 지정된 하위 클래스 중 하나 일 수 있습니다. – Oddthinking