+1 also to Owen's post. It seems to me the key motivation to use RDF/LD
is interoperability with data from other domains. Reuse of existing
vocabularies where appropriate helps this and allows the effort to focus
on the additional semantics necessary for the target application.
A key goal of work to build a new discovery system for our library is
the merging of catalog records with addition records and
data/annotations from other sources. I don't think it makes sense to
think if library records existing only in a walled garden.
On 5/23/13 12:58 AM, Shlomo Sanders wrote:
> Shlomo Sanders
> On May 22, 2013, at 22:46, "Owen Stephens" <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>> 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
>>> 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 http://xkcd.com/927/
>>> . 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
>>> http://bibframe.org/documentation/bibframe-authority/ 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