Pierre-Antoine CHAMPIN wrote: > > Jonas Liljegren wrote: > > ** isAlso > > > > I have also found the need to say that objects of a certain type must > > also be of certain other type. That is: a instance with multiple > > classes. Not a class that inherits from many classes. > > > > isAlso - A resource of this type must also be a of that other type > > type rdfs:ConstraintProperty > > domain rdfs:Class > > range rdfs:Class > > this is exactly the same : > suppose class A isAlso B > then any instance of A is an instance of B, > then A is *structurally* a subclass of B ! It seems that way, but it is not. As an example: A_Class type rdfs:Class isAlso B_Class B_Class type AbstractClass C_Class subClassOf B_Class a_object type A_Class type C_Class The object follow the constraint introduced by beeing an instance of A_Class. The constraint is that it also has to be _some_type_of_ B_Class. But it doesn't say what class. If A_Class was a subClassOf B_Class, you had no way of saying that that objecyt also should be of type C_Class or some other subClassOf B_Class. ---------------------------- Philippe Martin wrote: > > > ... to state that some classes/properties can't be instantiated: > > AbstractClass (subClassOf: Class) > > > > A_Class (type rdfs:Class, isAlso B_Class) > > B_Class (type: AbstractClass) > > C_Class (subClassOf: B_Class) > > a_object (type: A_Class, type: C_Class) > > Then, a_object is instance of a class that should have no instance? No. It's only an instance of A_Class and C_Class, a subClassOf the abstract A_Class. Maby the name is confusing? Let us rename "isAlso" to "instances of this class or a subClassOf this class must also be of the following class or a subClassOf the following class" That would give us: A_Class (type rdfs:Class, instancesOfThisClassOrASubClassOfThisClassMustAlsoBeOfTheFollowingClassOrASubClassOfTheFollowingClass B_Class) I welcome suggestions for a shorter name. :-) > Like Pierre-Antoine CHAMPIN, I am not convinced that "isAlso" permits > more than multi-inheritance. If A_Class was a subClassOf B_Class, you would have no way of saying that that objecyt also should be of type C_Class or some other subClassOf B_Class. I would like to explain the reson for my addition of this constraint. The constraints is to be used in automated forms. They are not primarly used for validating the data, but for deciding what fields to present to the user. The schema has the class "Person" and the class "Member". Persons has things like name, contact information, etc. Members has things like username, password, etc. A Member must be a Person or an Organization (an Agent). So this automated web form generator is asked to present a form to create a new member. The form should present you with the option of choosing what type of member you are, An organization, person, or a instance of a specific subClassOf Person? The isAlso constraint was to be used as a clue to include in the form, a dop down meny of the diffrent options. The next page of the form would present the specific fileds dreived from the chosed class. > The notion of class without instance is interesting but does not > distinguish between various notions: > - some things cannot exist according to certain physical laws of > certain worlds/domains (real or imaginary), or according to > certain definitions (e.g. contradictions in terms), > - some things just did not happen in a certain world (e.g. Europe) > and during a certain time frame, > - some things are imaginary and may or may not have happened in > some worlds. None of these notions cover my reason for the AbstractClass. It's just a way for the interface generator to know that you must choose a subclass of the class, if that class is spedified as the range for some property. Example: picture ( domain Person, range mime:Image ) mime:Image should be an AbstractClass. You would have to specify if the picture is an Mime:Image/JPEG, Mime:Image/PNG or something else. > Thus, classes such as "AbstractClass" or "NonexistentThing" do not > mean much since they do not specify any world/space/time frame. > It would be dangerous to add them to a top-level ontology because > some persons would use them directly (without specializing them > adequately first) and it would lead to inconsistencies. Then just make the AbstractClass an AbstractClass. ;-) But I see that we talk about diffrent applications for the RDF. This is maby more of a general extension, like the OIL. -- / Jonas - http://paranormal.se/myself/en/index.html