Closed sfolsom closed 3 years ago
We would like a use case for this issue and #2. Thanks!
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:
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 . }
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.
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 . } }
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 . }
Why create your own URI for the
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 .
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.
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.