lcnetdev / bibframe-ontology

Repository for versions of BIBFRAME ontology.
http://www.loc.gov/bibframe/
50 stars 7 forks source link

Request for inverse of bf:agent #3

Closed sfolsom closed 3 years ago

sfolsom commented 6 years ago

Create as inverse of bf:agent, bf:isAgentOf to link from an Agent. This is particularly important in a linked data environment, when only the Agent URI is known/dereferenced.

kirkhess commented 6 years ago

We would like a use case for this issue and #2. Thanks!

ntra00 commented 6 years ago

I don't believe you need the inverse; it's duplicative. If I know a work I can it's authors, and if I know authors I can get their works, with just two conditions:

find all the authors of this work

SELECT ?agent WHERE { http://id.loc.gov/resources/works/c002695079 bf:contribution ?contrib . ?contrib bf:agent ?agent. }

vs: Find all the works by this author: SELECT ?work WHERE { ?contrib bf:agent http://id.loc.gov/authorities/names/n79021164 . ?work bf:contribution ?contrib . }

sfolsom commented 6 years ago

Yes that's true for a SPARQL endpoint, but as stated in #4 in a linked data context if the only thing you have is the Agent URI, and you dereference it... you don't have a way of knowing which works were created by that agent. See also Rob Sanderson's report on BF1 about inverses, section 2.4.6 (https://docs.google.com/document/d/1dIy-FgQsH67Ay0T0O0ulhyRiKjpf_I0AVQ9v8FLmPNo/edit#heading=h.14iq7p9200tp). For instance, if the Library of Congress has a Work Entity, and Cornell has a related Agent Entity, there currently isn't a way for Cornell to link to LOC's Work Entity using BF terms.

ntra00 commented 6 years ago

If you asserted: http://id.loc.gov/resources/works/c002695079 bf:contribution [ bf:agent http://cornell.edu/rwo/agent/n12345 ]. it would. Also, if we added bf:isAgentOf, our "works by this author" query would have to change to be a deduping of a union query something like this (and the authors query would similarly be expanded to include both options.):

SELECT distinct (?work) WHERE { { ?contrib bf:agent http://id.loc.gov/authorities/names/n79021164 . ?work bf:contribution ?contrib . } UNION { http://id.loc.gov/authorities/names/n79021164 bf:isAgentOf ?work . } }

sfolsom commented 6 years ago

We would need either write access to http://id.loc.gov/resources/works/c002695079, or have to create our own URI for the Work and link it to your Work URI, or hardcode a namedgraph assumption into how we publish our linked data about the agent to include descriptions about other related entities. A simpler approach would to just be able to link directly.

Re: Queries... With declared inverses (and then reasoning for inverses), you could confidently query in either direction without having to deal with UNIONs (letting the model work for you):

SELECT distinct ?agent WHERE { http://id.loc.gov/resources/works/c002695079 bf:contribution/bf:agent ?agent . }

or

SELECT distinct ?work WHERE { http://id.loc.gov/rwo/agents/n79021164 bf:isAgentOf/isContributionOf ?work . }

ntra00 commented 6 years ago

Why create your own URI for the ? It seems if you can assert:

wrote , then you can say : writtenby .
sfolsom commented 6 years ago

In order for Cornell to publish linked data about a thing we need to control or have write access to the domain of the subject resource (or get into complicated named graph implementations).

We can't say the following because lc isn't our domain:

lc:work1 bf:contribution/bf:agent cornell:agent1 .

So we have to say something like:

cornell:Work1 bf:contribution/bf:agent cornell:Author1 ; sameAs lc:Work1 .

kirkhess commented 6 years ago

Hmm...we really could use a use case on this one (and we haven't worked on #4...)

I propose we defer these two issues, talk about implementation and other inverse issues offline and then come back with a more coherent plan.

kefo commented 3 years ago

https://id.loc.gov/ontologies/bibframe.html#p_agentOf