Won't re-using existing properties, namespaces, and others' work also have the benefit of making linked data implementation quicker?  To my mind the priority is not to be using MARC, another bespoke standard maintained by the library community to which we are tied.




Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

[log in to unmask]

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Owen Stephens
Sent: 22 May 2013 20:45
To: [log in to unmask]
Subject: Re: [BIBFRAME] re-using existing properties (was and the "lightweight abstraction layer")

On 22 May 2013, at 18:25, "Trail, Nate" <[log in to unmask]<mailto:[log in to unmask]>> wrote:

I think when you start reusing existing properties, you're relying on them being around for the long haul,

Firstly - we need to define this a bit more closely - what is the estimated timescale for BIBFRAME to be relevant?
Secondly - by building on RDF we are surely already tying ourselves to something that is not necessarily here for 'the long haul' - what is the likelihood of widespread use of RDF outlasting Dublin Core, FOAF, SKOS, etc.? I'd say that the risk of RDF becoming obsolete isn't much different to these core vocabularies becoming obsolete (but of course this is by nature completely unknown so none of us really know how long this stuff will remain relevant and used). Even building on the web and http has some risk and likely expiry date - we just don't know what it will be.
Thirdly - even if FOAF, Dublin Core, SKOS stop being used by others, there seems nothing to stop us continuing to use it as a community - how would this be less sustainable and worse than using our own vocabularies?

and requiring systems that consume them to be aware of all the multiple namespaces

I'd argue the opposite here - there are already plenty of systems and code libraries that deal with these common namespaces - that's the point! If we go our own way as a community here we are pretty much guaranteeing that we have to build the toolsets ourselves, and that no other systems will know what to do with our namespaces.

Reminds me of

. 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.

Well I have some sympathy with this, and think there are lots of properties where we will need to use library/BIBFRAME specific properties - I don't have a problem with this. It's not re-using when possible that I have a problem with. Can we really not agree that a persons name is adequately represented by foaf:name? Surely we need to at least give this a try before we give up?

In some ways, I think here is a case  for annotations; I could see people making assertions that x Work has some y relationship to z, and Bibframe could say okay, stick that in an annotation and a system can use it or not.

Why do we need annotations to achieve this? I can easily publish an assertion that x Work has some y relationship to z without requiring an annotation to do it? Isn't this just another triple?



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]<http://LISTSERV.LOC.GOV>] On Behalf Of Laura Krier
Sent: Wednesday, May 22, 2013 10:54 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: [BIBFRAME] re-using existing properties (was and the "lightweight abstraction layer")

On May 22, 2013, at 2:22 AM, Owen Stephens <[log in to unmask]<mailto:[log in to unmask]>> wrote:

re: re-using other properties

+1 but feel this ship has already sailed - previous replies have been clear that BIBFRAME/LoC want to control the namespace.

I'm not sure we should let this one go quite so easily. Not re-using existing properties reducing a lot of the benefit and purpose of using a linked data model in the first place. I haven't seen any reasoning from LoC that I agree with about why they are making this decision. And I think they've been very open to community opinion and input to date.

Does anyone else agree that this might be worth pushing harder against?


Laura Krier
Metadata Analyst
California Digital Library