+1 to Owen et al. This is rather fundamental for making data reusable in practice. Vocabulary reuse in itself is also a very useful tool for discovering which statements/patterns in a specific domain are actually unique (by determining whether or not they can be directly expressed using commonly understood properties).

Whenever this occurs, you will have to work out why that is (well, at least you should). For instance, if dc:creator [ foaf:name "…" ] doesn't capture the essence of a 100 field (which we know is very much the case), you start by asking what else it states. Is it an event, like an involvement? Or are multiple relations implied, and/or many subjects at once (with the disambiguation problems that ensue). Once questions to these answers start to surface, you can work out whether there are other commonly known entity types and properties in existing vocabularies that can be sensibly applied.

Or else if, as Karen brought up, you can define a property using RDFS/OWL in such a way that you can infer commonly known ("dumbed down") statements as well (by using rdfs:subPropertyOf, and perhaps application of e.g. owl:propertyChainAxiom, to "fish out" simpler expressions from more complex patterns). While this might introduce idiosyncrasies, it still limits divergence in forms of expression, and paves a path out of the "jungle of specificity". (I have a hunch that there might be many bridges like this, e.g between bf:authorizedAccessPoint and foaf:focus + skos:prefLabel.)

(And at the end of the day, even if you cannot find much neat and simple in the resulting interpretations, at least you may have found that certain entities (monographs with multiple isbn:s, mixed items, serials..) in practice have such vague or varied boundaries that they need to be explicitly expressed and interpreted as such (thus not fooling a casual observer that e.g. serials are more precisely defined than say "a conglomeration of summarized publication events", or something along those lines). An example of such "precise vagueness" is

This activity should also drive dialogue with the maintainers of these other, common, vocabularies, to ensure their continued significance and evolution. (For instance, I seem to recall that name variants and/or role based name properties was once under discussion for FOAF. This activity could enliven that again, for the benefit of many and varied domains.)

I'd also like to stress that I'm not against doing "aliases" for common properties in a single vocabulary (here bibframe), as long as there are clear linkages (owl:equivalentProperty) to the basis for their definitions.


Niklas Lindström
National Library of Sweden (KB)

23 maj 2013 kl. 09:16 skrev Simeon Warner <[log in to unmask]<mailto:[log in to unmask]>>

+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]>
<mailto:[log in to unmask]>> wrote:

On 22 May 2013, at 18:25, "Trail, Nate" <[log in to unmask]<mailto:[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

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