AW: Re: Ontological constraints

Tom,

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

No, not _all_ properties, but some. A computer will need some help to figure out what to do with the data, and without any hint if it's a description of a person or a city ("Paris"), it will be tricky to construct a proper UI for instance.

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

Yes, I think we agree that we need _something_ to find out what it is, à la "tell me what connections you have and I'll tell you what you are..."
  
> 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.

Yes!

All the best,

Lars

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de


> -----Ursprüngliche Nachricht-----
> Von: Thomas Baker [mailto:tbaker@tbaker.de]
> Gesendet: Mittwoch, 16. März 2011 14:11
> An: Svensson, Lars
> Cc: Young,Jeff (OR); Karen Coyle; public-lld
> Betreff: [Spam-Wahrscheinlichkeit=45]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 15:13:14 UTC