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