Owen:
Some comments below ...
Stephens, Owen wrote:
> Isn't this the point of the section on Selecting or Defining Metadata
> Terms though - reuse what you can, invent only what you must? The
> aspects of FOAF that are usable should be used, as it introduces the
> potential for more flexibility - the fact that FOAF isn't rich enough
> for all aspects of Library authority files just means that librarian's
> will have to look elsewhere or define new elements where existing FOAF
> elements aren't enough.
>
>
I have no argument with this, except that there's this swirl of other
activity happening that I fervently hope will enrich our choices in this
regard, and I'd really like to see that acknowledged. It's not that
FOAF isn't rich enough--for what it is, it's fine--we use some FOAF
properties in the NSDL Registry, for example, for user management. In
the library world, there's not usually a need (or a desire, either) to
manage information like email address, which people sometimes change as
often as they change their underwear. Things like alternative forms of
name are important, because folks who write things often change the way
they express their names over time, for a variety of reasons. And in
libraries, the notion that when you search for an author you should be
able to get everything associated with that author is important. FOAF
isn't a good match for those needs, and despite Dan's flexibility about
adding stuff, I'm not sure he should.
As we all know, there's this big glob of name authority data, built by
the library community over decades, managed by LC, which we'd all (or
mostly all) like to have available for this task. It could be used with
FOAF, not necessarily instead of, since the current MARC21 expression of
the information doesn't parse names very well, for instance. We've been
told that the exposure of this data as a web service with URIs is
coming, but we don't know when. So, should we just ignore this
information, or should we acknowledge it, and suggest ways that people
can do what they need to do in their DCAP to ensure that they'll be able
to take advantage of this when it comes? I'd go for the latter, myself.
> I think there is a danger in trying to make this document digestible to
> the (more conservative?) elements of an existing metadata community, it
> becomes a 'library guide to DCAP' - there might be a place for a
> document like this, but I don't think this is it.
>
>
I'd like to make the document relevant to the broadest swath of the
community that we can, without having to build a "library guide to
DCAP." I frankly don't see the point of ignoring the needs we already
know about in probably the largest constituency that DCMI has. Trust
me, the conservative types will never even look at this, but the ones
who want to participate in these newer options will look, and I would
like them to be able to understand that they don't need to "dumb down"
their data in order to participate. This is a concern I hear regularly,
in fact, and though I understand the desire not to go too far into the
bushes, I think we ignore those concerns at our peril.
> In general I'd support the comments about examples used in this draft -
> examples are just examples - they could all be replaced with
> 'example.com/1234' etc. but I think the use of real world examples is
> better - but it shouldn't be taken as a recommendation for a particular
> set of elements.
>
>
Agreed, but in order to avoid the possibility that real-world examples
be taken for recommendations, we need to be really clear about what's
what and not assume that readers know the difference.
Diane
|