Whoops! I think my point is being misunderstood, for which I take the
blame. Allow me to distinguish two independent concerns:
1. Creating categories or bunches of things, which perforce requires
naming them (i.e., how can you talk about a thing if you don't have a
name for it)
2. Putting semantics into those names for the categories or bunches.
Regarding concern 1: The point I have been advocating is that DCMI has
some responsibility for helping the outside world understand the
motivation for the new "elements" it advocates. We have gone around for
years advocating what we call "core elements" by some fuzzy principles.
My impression from Tom is that over time we will be advocating more
elements. Are they all core? What does it mean to be core? Is there
some way that we want to classify our elements? I don't know the answer
to these questions but they deserve to be asked. I, perhaps mistakenly,
saw namespace (and the URIs that identify them) as a mechanism for
promoting some classification of the elements we create. As we create
new elements and we put all of them in one namespace we will probably
need to differentiate them in some way to answer inevitable typical
questions, "so which one's are core"? Perhaps the right approach is to
throw them all in one "dictionary" (a single namespace) but that sure
sounds different from what we came up with at Warwick.
Regarding concern 2: I in no way advocate semantic overloading of
namespace URI's. I went through these wars back at CNRI with handle
semantics in 1994 and think that using names as a metadata scheme is a
bad idea. The simpler and less meaningful the better.
That all said, I go with the growing consensus for:
>
> http://purl.org/dc/elements/1.1/
> http://purl.org/dc/terms/
> http://purl.org/dc/type/
> (other domain-specific vocabularies added as necessary)
and will leave my "modularization" baton in the dust.
Carl
> -----Original Message-----
> From: Dan Brickley [mailto:[log in to unmask]]
> Sent: Wednesday, June 06, 2001 2:56 PM
> To: [log in to unmask]
> Subject: Re: DCMI namespace URIs
>
>
> On Wed, 6 Jun 2001, Aaron Swartz wrote:
>
> > [log in to unmask] <[log in to unmask]> wrote:
> >
> > > Now along come namespace URIs and we can
> > > 1) come up with an unbiguous ID for the thing called by
> many names 2)
> > > provide some conceptual unity to that category. You then
> come along and
> > > tell me that such category creation through naming is really not
> > > anything more than sugar and to really establish an identifiable
> > > category of things I have to turn to yet another
> mechanism (obscure RDF
> > > constructs).
> >
> > They're hardly obscure and they need not be RDF. Here's the
> point I'm
> > making:
> >
> > We're naming things, and their names can never be changed.
> We can choose to
> > give them long and informative names or simple and short
> ones, with the
> > information put off to the side. We can change the
> information, but we can't
> > change the name.
> >
> > Here's the question: Do you name your child:
> >
> Boy-Who-Lives-in-Kansas-City-and-Does-Well-In-Math-and-is-a-Me
> mber-of-the-Tr
> > ack-Team or Tom, and give people the other information when
> they ask for it?
> >
> > > I'm left with the feeling that we're creating an
> > > infrastructure only understandable by us geeks.
> >
> > I disagree, this is a very real-world decision we're making.
>
> I have to agree with Aaron here: there are many ways we'll
> want to talk
> about these named things, many categories they'll fall into. Shipping
> them to the world in simply named bundles (for which I still prefer
> dates) allows us room to move subsequently. While I prefer to use RDF
> to express subsequent categorisation of those named things, any
> mechanism at all for describing categories of thing (prose, HTML,
> software, XML in all flavours) can do the job.
>
> Anybody who has ever regretted creating a website with
> directories named
> after the original expectations for the site layout knows this
> problem: categories, applications and purposes change. We can
> anticipate
> this through adopting a minimalist naming policy. Those minimalist
> names may be associated with some principles of categorisation, but
> we'll they'll only be one of many ways of carving up the world.
>
> Here's an extreme example: the RSS 1.0 community last year named its
> notion of a channel with the URI 'http://purl.org/rss/channel'. Since
> then we've gotten into another silly fight about who controls the
> acronym 'RSS'. Lots of applications now embed that URI, and
> it'll cause
> them headaches to change.
>
> Dan
>
|