We got an answer from LC - and if you look at the relators, they do now
indeed have OWL ObjectProperty in their definition. Plus we got some
history, which is always good for documentation.
Thanks, all, especially Kevin,
kc
-------- Forwarded Message --------
Subject: Re: [BIBFRAME] LoC Relators as Properties
Date: Fri, 2 Dec 2022 21:00:39 +0000
From: Ford, Kevin <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum
<[log in to unmask]>
To: [log in to unmask]
Hello all:
With respect to the dc:contributor mappings, those were established
sometime in the aughts, circa 2007. They were the outcome of a joint
group between members of LC’s Network Development and MARC Standards
Office and the Dublin Core Metadata Initiative. Because the mappings
were the result of an agreement, we have never altered or otherwise
revisited/augmented those mappings.
When the Relators dataset was published at ID in 2010, with those
relationships to DC in place, each resource was declared a MADS/RDF
Authority, SKOS Concept, and RDF Property (and later OWL
ObjectProperty). It was this way for quite some time, but, as this
thread has shown, that’s not the case presently. We are still
investigating how/when the Property declaration was mistakenly dropped,
but its omission was very much an oversight. We have restored it;
declaring Relator resources as both types was, and remains, our intention.
In fact, we had a lively discussion about this back in June 2010 on the
ID listserv [1]. (Karen, you participated! J) As mentioned in that old
thread, I recall performing, with a colleague at the time, tests to
determine what ramifications, if any, might be caused by this and found
none. Let us know if that has changed. It is not unusual or odd for
words to exist and be equally useable as verbs and nouns depending on
the sentence, and our experience with RDF resources as subjects/objects
or predicates has been no different. This, of course, incudes the
decade Relators resources existed at ID both as concepts and properties.
As for Bibframe, to my recollection, BF 1.0 used Relators as properties;
the Relators-as-objects pattern was formally introduced with BF2.x. A
few reasons were behind that decision, but one of the main ones was a
need/desire to make additional statements about those relationships.
And it wasn’t an unusual need/desire as evidenced by schema.org
developing a similar indirection when it comes to associating Things
with Agents [2].
As most of us know, our data – library data – often defy the simpler
modelling patterns, which touches on another point: it was viewed as a
poorer outcome to encourage two different patterns, a direct one and
indirect one. The Relators-as-objects pattern (i.e. the indirect
approach) was certainly a decision with tradeoffs, especially when it
comes to be ability to infer relationships, but our own
practice/implementation has proven this indirect modelling to work and
I’m not convinced it is impossible to perform the type of inferencing
with roles you are thinking about, Steven. Granted, it may not be
possible using an RDF inferencing engine, but there are all types of
ways to make or extract inferences from RDF data.
We expect that communities or profiles will choose their preferred usage
when it comes to these dual-defined resources. We’ve not observed or
heard about any real-life ill effects to this to warrant the additional
overhead of publishing two separate datasets. It’s a slippery slope
because this issue is not unique to Relators. If anyone has encountered
a practical implementation issue with the single-dataset,
dual-definition design, please let us know.
Thanks for bringing this omission to our attention.
All the best,
Kevin
[1]
https://listserv.loc.gov/cgi-bin/wa?A2=ind1006&L=ID&X=1AA9B7293C54B79174&P=20499
<https://listserv.loc.gov/cgi-bin/wa?A2=ind1006&L=ID&X=1AA9B7293C54B79174&P=20499>
[2] http://blog.schema.org/2014/06/introducing-role.html
--
Kevin Ford
Network Development and MARC Standards Office
Library of Congress
Washington, DC
*From:*Bibliographic Framework Transition Initiative Forum
<[log in to unmask]> *On Behalf Of *Steven Michael Folsom
*Sent:* Tuesday, November 29, 2022 1:16 PM
*To:* [log in to unmask]
*Subject:* Re: [BIBFRAME] LoC Relators as Properties
Years ago, when we (I forget which LD4 phase) were giving feedback on BF
(1.0, I think), we definitely felt it odd to be using relators in the
object position of the BF contribution pattern. Up until that point, I
had always assumed relators were strictly defined as relationships...
probably because we were only using them in MARC where the RDF semantics
didn't matter as much.
When beginning to work in RDF, we created an activity pattern[1] in a
proof-of-concept ontology[2] as one possible way for BF to evolve, but
nothing ever came of it.
Re: search, Over time, I guess I've stopped expecting the ability to do
anything semantically interesting/useful with roles... e.g. take
advantage of formal semantics/reasoning class or property hierarchies
provide, or broader/narrower relationships if modelled as SKOS.
Re: creation, I know some RDF editing systems have assumptions about how
properties are used, which may preclude being able to easily have
something defined as a property in an object position.
Re: exchange, I think you hit on it earlier when talking about LC's
position. Their implementation and their vocabularies often become the
default standard. So maybe exchange either means compliance with their
practice, or conversion of their data to a desired local model... which
has its own cost/benefit exercise.
[1] http://bibliotek-o.org/1.1/ontology.html#Activity
[2] http://bibliotek-o.org/overview/overview.html
------------------------------------------------------------------------
*From:*Bibliographic Framework Transition Initiative Forum
<[log in to unmask]> on behalf of Karen Coyle <[log in to unmask]>
*Sent:* 29 November 2022 12:23 PM
*To:* [log in to unmask] <[log in to unmask]>
*Subject:* Re: [BIBFRAME] LoC Relators as Properties
Steven & MJ, Thanks.
My understanding from the DC folks is that the addition of
dc:contributor superproperty was instigated by DC, possibly so that
those relators could be used as properties with DC-based data. I don't
know if it was ever really embraced by LoC or if it was just seen as
something that didn't get in the way.
Note that this took place so long ago that the superproperty is in the
old DC 1.1 namespace. It's interesting to me that anyone (you, Steven!)
noticed this.
I'm not totally sold on something being both a property (verb) and a
SKOS concept (noun). I can twist my brain into accepting it but it feels
iffy. I suppose the SKOS concept could be expressed as "is contributor
of" and the property could be transitive? In any case, I think there
needs to be some real coordination between the property form and the
object form.
I also wonder if there is concern in the BIBFRAME community about using
the same IRIs for a property and a concept -- what it means for
creation, searching, exchange. Would there be confusion? Would a
different IRI be better for the properties, e.g.
http://id.loc.gov/agent/ctb
That is somewhat similar to what RDA is doing, defining agent types
rather than roles with types.
kc
On 11/28/22 4:52 PM, Steven Michael Folsom wrote:
Hi Karen,
In various projects throughout the years, I've run into this
property/skos "punning" that LOC does with relators. I think for
data producers interested in properties that link directly from
bibliographic resources to an agent, relators as properties would be
an ideal solution.
Maybe you've already come to this sense, but I think the issue has
always been LOC has been trying to support direct and indirect
relationships between bib resources and agents without creating
separate resources for both patterns. In doing so, implementers are
confused and reluctant to use the relators for either pattern
despite LOCs position as a standards body.
If LOC wanted to more clearly support both patterns, I'd welcome
having relator properties that link in some way to corresponding
(but separate) SKOS vocabulary concepts or classes. That said,
depending on what you expect users to do with your data... (maybe
there's no expectation that anyone will ever reason on the data) you
might just ignore the confusing RDF practices around relators and
choose the definition that works for you. In this case that would
mean ignoring the concept definitions and opting into the property
definitions currently in the relators. Note that in their BIBFRAME
implementation, LOC is ignoring the property definitions, instead
using the relators as role concepts[1].
Thanks,
Steven
[1] https://id.loc.gov/resources/works/14385483.bibframe.nt
------------------------------------------------------------------------
*From:*Bibliographic Framework Transition Initiative Forum
<[log in to unmask]> <mailto:[log in to unmask]> on
behalf of Karen Coyle <[log in to unmask]> <mailto:[log in to unmask]>
*Sent:* 28 November 2022 5:09 PM
*To:* [log in to unmask] <[log in to unmask]>
<mailto:[log in to unmask]>
*Subject:* [BIBFRAME] LoC Relators as Properties
All,
I'm writing to solicit your thoughts on using LoC relators [1] as
properties. It's a bit more complex of a question than it sounds, but
I'll try my best.
This comes about because of a project at Dublin Core for a Scholarly
Resources Application Profile [2] (SRAP). The developers of SRAP (from
the Finnish National Library) would like to use the following relators
as properties in their profile:
Degree supervisor | http://id.loc.gov/vocabulary/relators/dgs
Editor | http://id.loc.gov/vocabulary/relators/edt
Funder | http://id.loc.gov/vocabulary/relators/fnd
Opponent | http://id.loc.gov/vocabulary/relators/opn
Praeses | http://id.loc.gov/vocabulary/relators/pra
(More may be added later).
As you may know, LoC relators are defined in MADS and in SKOS as
concepts. In the downloaded MADS file you can find the declaration:
rdfs:subPropertyOf <http://purl.org/dc/elements/1.1/contributor>
in about 105 of the nearly 400 relators defined there. This was
added in
the early 2000's to relators that were deemed to be in the spirit of
dc:contributor.
For example
<http://id.loc.gov/vocabulary/relators/act> a madsrdf:Authority ;
madsrdf:authoritativeLabel "Actor" ;
madsrdf:code "act" ;
madsrdf:definitionNote "A performer contributing to an expression of a
work by acting as a cast member or player in a musical or dramatic
presentation, etc."@en
<mailto:%22A%20performer%20contributing%20to%20an%20expression%20of%20a%20%0bwork%20by%20acting%20as%20a%20cast%20member%20or%20player%20in%20a%20musical%20or%20dramatic%20%0bpresentation,%20etc.%22@en>
;
madsrdf:editorialNote "changed MARC def"@en ;
madsrdf:hasBroaderAuthority
<http://id.loc.gov/vocabulary/relators/prf> ;
madsrdf:hasNarrowerAuthority
<http://id.loc.gov/vocabulary/relators/vac> ;
madsrdf:isMemberOfMADSCollection
<http://id.loc.gov/vocabulary/relators/collection_BIBFRAMEWork>,
<http://id.loc.gov/vocabulary/relators/collection_PastPresentRelatorsEntries>,
<http://id.loc.gov/vocabulary/relators/collection_RDA>,
<http://id.loc.gov/vocabulary/relators/collection_RDAContributor>,
<http://id.loc.gov/vocabulary/relators/collection_RDAWork> ;
madsrdf:isMemberOfMADSScheme <http://id.loc.gov/vocabulary/relators> ;
rdfs:subPropertyOf <http://purl.org/dc/elements/1.1/contributor> .
Because of this subproperty declaration, it follows that these relators
can be used as properties in RDF. Unfortunately, most of the relators
that SRAP wishes to use are not so defined.
Note that RDA defines relators as "agent" properties [3] and the
National Library of Sweden has created its own list based LoC's
relators, but in which they are defined as properties.[4] However,
it is
generally thought that the LoC list is the best known, the sine qua non
of relator lists, and that is what the developers of SRAP prefer to use.
All of that is background for this question:
IS THERE A DESIRE IN THE COMMUNITY TO USE LoC RELATORS AS PROPERTIES?
If so, the when and how could be discussed next.
kc
[1] https://id.loc.gov/vocabulary/relators
[2] https://github.com/dcmi/dc-srap
[3] http://www.rdaregistry.info/Elements/a/
[4] https://id.kb.se/vocab/
--
Karen Coyle
[log in to unmask]
http://kcoyle.net
--
Karen Coyle
[log in to unmask]
http://kcoyle.net
