It seems to me that there is a “graph QA” issue here, whose tradeoffs need to be reflected upon.

If a resource description graph contains only one of a pair of directional relationships known to exist, an inferential mechanism capable of ferreting out the missing relationship must be available on every occasion when the related nodes come into play. (I gather that inferencing engines vary in cleverness, but also wonder whether this capability can be used to enrich the graph behind the scenes.)

On the other hand, providing both directional relationships eliminates the requirement for an ever-present inferencing mechanism and increases measures of graph connectivity.* This implies increased reachability and improves prospects for pattern searching and other well-established graph operations. But as indicated below, resource description graph QA should require periodic graph integrity checks (is the target still there?) on the part of linkers and linked. But shouldn’t such systematic graph integrity checking take place anyway – possibly as a Web-based service, accessible to all?

So we can consider tradeoffs along a “loosely-connected resource description graph–highly active inferencing mechanism” vs. “strongly-connected resource description graph–less active inferencing mechanism” dimension – with the idea of a background, graph integrity-checking mechanism floating off to the side. In the sparse description case, I’m reminded somewhat of issues floating around the use of digital negative formats (DNG), ** where DNG converter characteristics have to be managed over time along with the image data.

Ron Murray


From: Robert Sanderson <[log in to unmask]>
Reply-To: Bibliographic Forum <[log in to unmask]>
Date: Tuesday, April 28, 2015 at 6:08 PM
To: Bibliographic Forum <[log in to unmask]>
Subject: Re: [BIBFRAME] Linked data and directionality

Hi Jörg,

Normally we agree on these sorts of points so I'm interested that on this particular one (that inverse relationships are an anti-pattern) we differ.

Too Long; Didn't Read: In order to follow point 4 of Linked Data (Include links to other URIs. so that they can discover more things) both halves of the relationship are needed.

Long Version:

In my opinion, the world has moved on from those posts of 9 years ago and inverse relationships are quite the opposite of an anti-pattern in Linked Data.
My reasoning is based on the differences between RDF and the Linked Data usage of the framework.

In RDF, where anyone can say anything about any resource, it's pretty clear that you don't really need explicit inverse relationships. Using child/parent as the predicate, if you want to say that X is the child of Y, and all you have is parent, then you say Y is the parent of X.  Having two ways to say the same thing *with no way to differentiate which way is better* leads to spending time making meaningless choices.

However, the clock has moved on, and we have now have a more restricted view on what and how information should be expressed using RDF.  In Linked Data, you make assertions about your own resources, and dereferencing the resource returns the description of it.  If you control both X and Y, then sure you might not need to have both predicates.  But when X and Y are controlled by different institutions, you definitely need both predicates.  This is particularly true in BIBFRAME where distributed cataloging practices would need to be able to express, for example, that an Instance is bf:instanceOf a Work that was created by another institution.  That institution might wish to link back to all of the instances, and hence need to be able to express its Work bf:hasInstance the remote Instance.

Translations and other work/work or instance/instance relationships are even clearer that the same institution will not control all of the entities involved in the graph. Otherwise the clever, inferencing search engines won't be able to find the descriptions to inference on (or at least have a much harder time doing so).


On Tue, Apr 28, 2015 at 12:21 AM, [log in to unmask] <[log in to unmask]> wrote:
Yes, if the ontology marks the property as inverse with "owl:inverseOf", it can be followed backwards.

It is a good behavior to avoid inverse properties.


It is close to impossible to make years into URIs, because years are part of calendars (gregorian is just one calendar type), where time events are defined as time instants or periods. You always have a numeric unit in it. As a result, you would have millions and millions of different URIs, a situation which is not possible to handle efficiently in an implementation, and very cumbersome for users.

Search engines are smarter. If they are required to search for all 16th century dramatists or plays written in Elizabethan England, they do not operate on RDF graphs but on inverted files where filters can be defined. No need to worry for that on RDF level.



On Mon, Apr 20, 2015 at 8:54 PM, Kelley McGrath <[log in to unmask]> wrote:

This would seem to be a basic question, but I was asked the other day and I wasn't sure how to answer. Looking at a linked data graph that says that Hamlet - has creator - Shakespeare, there is an arrow pointing from Hamlet to Shakespeare. This person said they assumed that you can go the other way, too. Obviously Hamlet has creator Shakespeare logically implies that Shakespeare created Hamlet. However, the RDF statement has directionality so from a practical point of view, what happens when someone starts from Shakespeare rather than Hamlet? Is there some way for them to traverse the statement backwards or does the opposite statement need to be explicitly made (which would seem to create a nightmare for data maintenance)?

How about if the endpoint is a literal, say Shakespeare has birth year 1564? This would not seem to work backwards so maybe we should be making years into URIs so we can find all the 16th century dramatists or plays written in Elizabethan England.


Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305