roles

From: David R. Karger <karger_at_mit.edu>
Date: Mon, 6 Jun 2005 17:28:54 -0400

I don't think enough attention is being paid to the idea of _roles_.
The most obvious example of a role is "title." We want to be able to
get a title off any object. One way to do this is to require that
every object have an rdfs:label (or maybe a dc:title), but for many
data types this will be redundant. For example, a person probably has
a full-name. Should we require that all people also have a dc:title
that is equal to their full-name? It seems natural instead to specify
that a given property is the right title property for a given type.

But how far do we take this? Do we want to specify a whole list of
properties, implying that you should take the first one on the list?
Do we want to specify a (SPARQL) query that can be invoked to get the
title of the object?

I think we should identify properties other than title that are
extremely common and likely to be needed for display purposes. For
example, date, creator, and description. There will probably be
multiple ways provide these properties---eg an email has a compose
date, send date, receive data, read date, due-by date. But if we have
defined a restricted set of commonly-displayed properties, we can
leave it to the developer of each data-type to specify the right
choice for that data type.

Arguably this is simply doing ontology mapping, from arbitrary
predicates to eg dublin core. But I think it is still important.
It will let us display informationr reasonably nicely without having
to write extensive selection/styling rules for every new data type.

One might also argue that roles are equivalent to styles---that I can
accomplish roles by specifying that a certain thing should be rendered
with a canonically-named "date" style or "creator" style. But this is
backwards I think---rather, there should be a default style for
rendering things that have the "author" role (and a way to override
the default with other styles).
Received on Mon Jun 06 2005 - 21:26:59 EDT