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 


> 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.
> cheers
> stuart
> --
> I have a new phone number: 04 463 5692
> / 
> <>
> ------------------------------------------------------------------------
> *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.
> Ron Murray
>  * 
> **
> From: Robert Sanderson <[log in to unmask] <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Forum <[log in to unmask] 
> <mailto:[log in to unmask]>>
> Date: Tuesday, April 28, 2015 at 6:08 PM
> To: Bibliographic Forum <[log in to unmask] 
> <mailto:[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).
> Rob
> On Tue, Apr 28, 2015 at 12:21 AM, [log in to unmask] 
> <mailto:[log in to unmask]> <[log in to unmask] 
> <mailto:[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.
>     See
>     Tim Berners-Lee
>     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.
>     Best,
>     Jörg
>     On Mon, Apr 20, 2015 at 8:54 PM, Kelley McGrath
>     <[log in to unmask] <mailto:[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 16^th century dramatists or plays written in Elizabethan
>         England.
>         Kelley
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600