I think the jury is out on that one. The intent is to make BIBFRAME work well on the web with other linked data, and in many cases, internal systems will take a while to catch up to being able to store that natively.
On 4/29/15 2:12 PM, Stuart Yeates wrote:
Your arguments are based on system internals. Isn't the consensus that BIBFRAME is an interchange format which doesn't talk about system internals?
Actually, I don't think I've seen that stated in the BF documentation. Did I miss it?
Some of the functionality of BF appears to me to be at least locally oriented if not "system internal", including the "lightweight abstraction layer" which requires one to create a local URI for every heading, and forbids the direct use of external identifiers, like LCNA. Personally, if I were linking data from multiple sources I would have little use for the internal identifiers from hundreds of local systems and would prefer a direct link to an agreed authority.
It would be of use to understand whether BF intends to be an interchange format. Especially since it appears to be implemented "as is" by some systems.
You say 'both directional relationships'. bf:instanceOf and bf:hasInstance are not two relationships. They're two representations of the same relationship,
You also ask 'shouldn’t such systematic graph integrity checking take place anyway' Yes, but every system will have a different integrity check, because every system is trying to do different things with the data and has a different existing dataset. A library system for a lending public library will have different functionality from a library system for digital-only specialist research library. Very scant information about a bf:creator will be unsuitable for many systems. but may be adequate for systems that already have extensive information in the entity in question and just need to match identifiers.
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Murray, Ronald <[log in to unmask]>
Sent: Thursday, 30 April 2015 2:22 a.m.
To: [log in to unmask]
Subject: Re: [BIBFRAME] Linked data and directionality
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.
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.
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).
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.
Tim Berners-Lee http://dig.csail.mit.edu/breadcrumbs/node/72
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.
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305