Sent from my Apple-branded FBI tracking device
On 23. mai 2013, at 17.39, "Trail, Nate" <[log in to unmask]> wrote:
> If you adopt someone else's terms, you are stuck with their
> definitions, and if they decide to change them, you have to revisit
> your decision: a constant maintenance headache.
> The foaf vocab is in Testing status, version 0.98. Are they going to
> change it before it comes out? Who knows? Will they add something
> better like foaf:sortName that is more like a traditional library
> Just coming up with a list of all the possible terms out there and
> fighting over whether they are close enough to use for each term we
> have will be a major use of time.
> On DC, people you might not be for it, but if we opened the BF vocab
> up, there might be a lot of clamor for it; it's so simple and it's
> all over the place!
> PS I had a good laugh about the Unicode and ISO 639 "roll our own
> comment". I'm working right now on developing a computer that uses
> 2s and 3s instead of 1s and 0s.
> -----Original Message-----
> From: stuart yeates [mailto:[log in to unmask]]
> Sent: Wednesday, May 22, 2013 5:31 PM
> To: Bibliographic Framework Transition Initiative Forum
> Cc: Trail, Nate
> Subject: Re: [BIBFRAME] re-using existing properties (was http://bibframe.org/documentation/bibframe-authority/
> and the "lightweight abstraction layer")
> On 23/05/13 05:25, Trail, Nate wrote:
>> I think when you start reusing existing properties, you're relying on
>> them being around for the long haul, and requiring systems that
>> consume them to be aware of all the multiple namespaces.
> The "syntactic sugar" option used by
> madsrdf:hasCloseExternalAuthority does not introduce a new namespace
> from the users' point of view. The syntactic sugar can even be kept
> in a separate RDF file from the definition of the bibframe
> properties, making it second class and invisible to everyone who
> doesn't want it.
>> In all cases, I can't
>> see us (the library community) agreeing that the way foaf or dc
>> (or > whatever) uses a term really matches what we're talking about.
> Following that arguement we should also walk away from ISO 639, ISO
> 3166, RFC 3986, Unicode and so forth. None of them are perfect from
> a library point of view but all of the are better than rolling our
> [For the record I'm not suggestion using dc / Dublincore.]
> Stuart Yeates
> Library Technology Services http://www.victoria.ac.nz/library/