RE: Dublin Core, the Primer and the Model Theory

Graham:
> But there's another group here, too:  I'll call them "information
> designers".  This is the category I'd apply to Dublin Core.  And more
> generally, to any group that get's together to define how to describe some
> information in RDF, so I guess that would include the CC/PP and photo
> metadata software I mentioned.
>
> Of course, the really important progress is going to come from a fruitful
> cooperation of software-developers and information-designers.  In the
> scheme of things, I think it's going to be easier for the software
> developers to adapt to the needs of the information designers.
>


DanC:
> If this goes on our issues list, please call it
> "things versus their names".

I guess I see it as about RDF's attitude to (something like) metonymy.
[[[
  substituting the name of an attribute or feature for the name of the thing itself (as in `they
counted heads')
]]]

It is clear that

<eg:doc1.html> <dc:creator> "John Smith" .

is  a less precise model than

<eg:doc1.html> <dc:creator> _:x .
_:x <eg:name> "John Smith" .

What is not clear is that the more precise model is a *better* model.

It would be strange if I had written

[[[
The person who goes by a name with given name which is shortened to "Dan" and with family name which
starts with "C" wrote:
> If this goes on our issues list, please call it
> "things versus their names".
]]]

But it would have been more precise.

Modelling is about choosing what not to include as much as about choosing what to include.
Usually models should be as simple as possible given the purpose.

The two triple model makes the lack of unique naming explicit. In the one triple model it is
implicit. Since this is a general well known problem with author names it does seem to be often
*better* modelling to not keep repeating this well-known problem.

Clearly supplying a URI for the author then addresses the lack of unique names problem, so that:
<eg:doc1.html> <dc:creator> <urn:John_Smith> .
<urn:John_Smith>  <eg:name> "John Smith" .

will be a more detailed model as long as we have adequate control over the uri space.
For many purposes I think this latter two triple model is better. I am pleased that
the primer starts off with such a case.

(But even so there is a temptation to fall into metonymy by using the URL of someone's web page or
their mailbox to substitute for a URI of the person themselves).

There is also a sense in which there is some overloading going on here.

The current model theory would be fine with dc if the dc folks had chosen to have two properties
dc:creator and dc:creatorName. These could then be related by a rule

aaa <dc:creator> bbb .
bbb <rdf:value> "string" .

iff

aaa <dc:creatorName> "string" .

I see simpledatatype2 as given a formal and precise account of how the overloading in DC works
(using dc:creator with both a literal node and a resource node with related but slightly different
meanings). Overloading is a technique I use everyday when programming and it doesn't worry me.

The current MT by not making sense of overloading and discouraging metonymy makes life easier for
software developers and more difficult for information designers.
Not having a MT, (or equivalently having a MT that no one respects) is unacceptable because the
information designers will continue to use overloading and metonymy and the software developers will
not be able to make sense of it.
Having a MT that accounts for overloading and metonymy allows the software developers to build stuff
that works with the techniques that the information designers use.


<this:msg> <dc:creator> _:aPerson .
_:aPerson employed by
            (a company with home page "http://www.hp.com")
         with name
            (with given name)
                   (written in UTF-8 as)
                            "Jeremy"
            (with family name)
                   (written in UTF-8 as)
                            "Carroll"

Received on Friday, 17 May 2002 06:10:12 UTC