Re: why are properties decoupled from classes

Find some more comments inline :)

On Wed, 2005-10-26 at 12:08 -0400, Frank Manola wrote:
> I think Jos's comments below illustrate some important points.
> 
> Jos de Bruijn wrote:
> > On Wed, 2005-10-26 at 10:20 +0100, Jon Hanna wrote:
> > 
> >>Xavier Noria wrote:
> >>
> >>>In RDFS and friends properties do not "belong" to classes, whereas in  
> >>>OOP normally they do. For instance, if you've got an instance of  
> >>>foaf:Person you cannot assume there's any assertion about  foaf:interest 
> >>>for him.
> >>
> >>Look at it the other way around. If you could assume that there was a 
> >>foaf:interest assserted for every foaf:Person then any foaf:Person 
> >>without a foaf:interest asserted would be invalid, hence it would be 
> >>impossible to say anything about anyone without giving at least one 
> >>foaf:interest which you may neither know nor care about. An application 
> >>concerned with people's medical history will not care about the same 
> >>information as one concerned with their professional qualifications and 
> >>so on.
> > 
> > 
> > In this case you assume a database-style (closed-world) minimal
> > cardinality constraint is associated with the property foaf:interest. 
> > That you declare such an attribute does not necessarily mean that you
> > also declare such a constraint.
> > 
> > Also, in the case of SQL, when a column in a table is required to have a
> > value you need to assert an additional constraint (NOT NULL).
> > 
> > 
> >>It *is* possible to say that, for example, all people have mothers, 
> >>however knowing that there is a single value for the 
> >>_ex:biologicalMother property of every person does not mean that you 
> >>will be informed as to who that person's mother is.
> > 
> > 
> > Here you are actually coupling the property with the class; you say
> > something about the property hasMother for the class Person.
> > So, you are actually making a case for properties belonging to classes.
> > The statement you are making cannot be modeled in RDFS, where properties
> > are truly decoupled from classes, but can be made in OWL through local
> > property restrictions, which is somewhere in the middle between
> > properties belonging to classes and them being totally decoupled.
> > 
> > For me it has also always seen strange that in RDFS properties do not
> > belong to classes. A Person can have an interest and you might want to
> > say something about this interest. To me it doesn't really make sense to
> > say "there is a property 'interest' and you can do with it whatever you
> > want".
> 
> I think you have to start with RDF in order to understand why RDFS is 
> the way it is.  As I see it, RDF is primarily about letting people 
> record information about *instances* in the most flexible way possible. 
>    On the Web, different people will want to say different things about 
> the same instance, and record additional properties as new things arise. 
>   Properties separated from classes provide the easiest way to do that. 
>   In an OO class system, you can't describe instances until you first 
> describe classes, and that tends to centralize the definition of things. 
>   I wouldn't be able to record a new property without first trying to 
> find the class definition (there may be more than one) associated with 
> the instance (and possibly change it).  If you're primarily concerned 
> with instances, it's much easier to think in terms of just instances and 
> properties, not classes.  RDFS classes then become an overlay on this 
> basic approach.  I'm familiar with several attempts to deal with large 
> instance collections to which widely-varying properties apply, and using 
> ordinary OO class ideas in these applications becomes very ugly very 
> quickly.

I definitely like the capability of RDF to capture semi-structured data.
I would not want, like in a classical OO system, that every node in an
RDF graph is typed and that only those properties which appear in the
class definition may be used.

My point is that in most cases it does not make sense (at least to me)
to describe (constraints on) properties outside of the context of a
class.

> 
> > Actually, it is kind-of dangerous to let people do with properties
> > whatever they want, because it may easily lead to incorrect modeling
> > when you allow constraint (e.g., rdfs:domain and rdfs:range).
> > What happens very often is that people want to restrict the domain of a
> > property. It seems reasonable to say:
> > interest rdfs:domain Person   (1)
> > 
> > Maybe you only care about persons which have interests. However, it
> > might turn out later that organizations may also have interests. If we
> > stick with the domain restriction (1), then every organization which has
> > an interest is actually inferred to be a Person.
> 
> It's true that it can be dangerous to let people do whatever they want 
> with properties, and RDFS range and domain constraints can be misused, 
> as these examples illustrate.  However, it also can be dangerous to 
> *not* allow people to say what they want, e.g., to encourage them to 
> leave off properties that vary from one instance to the next (or from 
> one person's view to the next) because the necessary properties aren't 
> in the class definition, or to use some general "other data" property 
> that *is* in the class definition, together with some complex encoding 
> of property and value in the value of that "other data" property, to 
> record the varying data.

Again, I do not want to restrict the use of properties in RDF.

> 
> > 
> > Another example is the range constraint. One may want to use the same
> > property for different classes, but with a slightly different range.
> > It seems totally reasonable to say:
> > age rdfs:range xs:nonNegativeInteger
> > 
> > This seems to work quite well for the age (in years) of persons.
> > However, this does not work for, for example, the age of particles in a
> > particle accelerator.
> > 
> 
> I think the proper approach for some of the modeling situations that 
> aren't handled cleanly by RDFS (or OWL) is to develop new schema 
> constructs or languages (or add rules to the existing ones) that allow 
> users to define the constraints they want (including OO-like ones), 
> using the RDF approach as a base, rather than building those constraints 
> in at the lower levels of the modeling "stack", and forcing everyone to 
> be bound by them, whether those constraints are appropriate for their 
> applications or not.  It seems to me it is a much more straightforward 
> approach to add constraints as appropriate to a basically unconstrained 
> model, rather than to try somehow to unconstrain an already-constrained 
> one.  In this regard, I don't think there's any reason to assume that 
> RDFS and the various OWL variants constitute the last word in 
> definitional facilities for RDF-based data.

I completely agree with you here :)


Jos

> 
> --Frank
> 
> 
--
Jos de Bruijn, http://www.uibk.ac.at/~c703239/
+43 512 507 6475         jos.debruijn@deri.org

DERI                      http://www.deri.org/
----------------------------------------------
My definition of a free society is a society where it is safe to be
unpopular.
  - Adlai E. Stevenson Jr.