Re: Ontological constraints

On Wed, Mar 16, 2011 at 09:15:22AM +0100, Svensson, Lars wrote:
> On Sun, Mar 06, 2011 at 09:35:22AM -0800, Karen Coyle wrote:
> > I actually think that we should emphasize the "has a" rather than "is  
> > a" aspects of the resources we describe, and let the "has a" allow us  
> > to infer any number of "is a" qualities. This is the message that Jon  
> > Phipps gave at the tutorial day at DC in Pittsburgh -- that we  
> > describe things by their characteristics, and those characteristics  
> > tell us what the thing *is*. 
> 
> Yes, that sounds right to me.  Emphasize Properties
> (relationships) over Classes. Verbs over nouns.  Describe
> things less through giving them a name -- i.e., writing a
> definition for a class of things to which they belong --
> and more through enumerating their characteristics.
> ]] [1]
> 
> If this is so, then I'd say that we _definitely_ need to state domain/range for the properties, otherwise The System (TM) will not be able to find out what the thing is, even if it knows the characteristics. Does that make sense?
> 
> [1] http://lists.w3.org/Archives/Public/public-lld/2011Mar/0025.html

Are you saying that all properties should have domains
and ranges more specific than rdfs:Resource?  I think that
may go too far.  The property skos:prefLabel, for example,
has no domain or range, making it usable to label any type
of resource.  Similarly, what domain for dct:title would
tell the System with accuracy what is being described without
limiting the usefulness of the property for describing other
types of things?

Given a description of twenty statements, using twenty
properties, just one of those properties need have a stated
domain to allow the type of described resource to be inferred
(e.g., name, height, identifier... but also foaf:birthday
with domain foaf:Agent).

In other words, I suspect the answer is not either/or, but
that properties should be constrained as needed, case by case,
and that vocabulary design should balance semantic specificity
against general applicability and conciseness.

Tom

-- 
Tom Baker <tbaker@tbaker.de>

Received on Wednesday, 16 March 2011 13:12:20 UTC