Re: Conventions and top-level ontologies for RDF

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

Received on Tuesday, 20 June 2000 14:38:11 UTC