LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  May 2015

BIBFRAME May 2015

Subject:

Re: Linked data and directionality

From:

Philip Wetzel <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Mon, 4 May 2015 12:10:38 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Hi Lars,

http://idioms.thefreedictionary.com/jury+is+still+out

Regards,  Phil

-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Martynas Jusevicius
Sent: Monday, May 04, 2015 8:02 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Linked data and directionality

Lars,

nobody can dictate that, but the different "external" and "internal"
data models will be a never-ending source of bug-prone data conversion code and developer costs.

Having one unified data model such as RDF will streamline software design and development in ways people hardly imagine right now.

Martynas

On Mon, May 4, 2015 at 1:56 PM, Svensson, Lars <[log in to unmask]> wrote:
> Nate,
>
>
>
> For someone not so accustomed to US jargon: what exactly does „the 
> jury is out on that one“ mean? Is BIBFRAME intended _only_ to be an 
> exchange format working well on the web or is it supposed to be the 
> preferred internal format, too?
>
>
>
> I daresay, that I don’t see the point in dictating any library or LIS 
> vendor how they organise their data internally….
>
>
>
> Best,
>
>
>
> Lars
>
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] On Behalf Of Trail, Nate
> Sent: Friday, May 01, 2015 4:10 PM
>
>
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Linked data and directionality
>
>
>
> Karen,
>
>
>
> 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.
>
>
>
> Nate
>
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> Sent: Thursday, April 30, 2015 12:31 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Linked data and directionality
>
>
>
>
>
> 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.
>
> kc
>
>
>
> 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 
> https://www.facebook.com/VUWLibrary / https://www.facebook.com/TKMPC
>
>
>
> ________________________________
>
> 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
>
>
>
>  *
> http://reference.wolfram.com/language/guide/GraphPropertiesAndMeasurem
> ents.html
>
> **http://en.wikipedia.org/wiki/Digital_Negative
>
>
>
> 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).
>
>
>
> Rob
>
>
>
>
>
>
>
> 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.
>
>
>
> See
>
>
>
> Tim Berners-Lee http://dig.csail.mit.edu/breadcrumbs/node/72
>
>
>
> http://richard.cyganiak.de/blog/2006/06/an-rdf-design-pattern-inverse-
> property-labels/
>
>
>
> 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]> 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.
>
> Kelley
>
>
>
>
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>
>
>
> --
>
> Karen Coyle
>
> [log in to unmask] http://kcoyle.net
>
> m: +1-510-435-8234
>
> skype: kcoylenet/+1-510-984-3600

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager