Re: why are properties decoupled from classes

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.

> 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.

> 
> 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.

--Frank

Received on Wednesday, 26 October 2005 16:03:56 UTC