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  November 2014

BIBFRAME November 2014

Subject:

Re: Blank nodes again

From:

Karen Coyle <[log in to unmask]>

Reply-To:

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

Date:

Tue, 18 Nov 2014 12:09:27 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (159 lines)

It depends on what you mean by "handled." I think we need a set of 
scenarios (update-local, update-global, search across resources, data 
living on the web... etc.), and then we could try each of them out. It's 
especially difficult because we don't know how we will share data in the 
future, if we'll all have our own systems with cataloging copy, or if, 
as asoroka opines, we'll all be pulling from a single source of shared 
data. We don't know who will participate in our sharing or how. If there 
are local systems, will local system changes result in updates to the 
data in the cloud?

All of these, and more, feed into the "it depends." What I think would 
be terribly unfortunate would be if we were to design bibliographic data 
that only works well in its own silo -- and then libraries would be 
silo'd again.

kc

On 11/18/14 11:35 AM, Joseph Kiegel wrote:
> Can someone supply bibliographic examples?
>
> How would situations like this be handled?
>
> bf:publication [ a bf:Provider ;
>            bf:providerDate "[1964]" ;
>            bf:providerName [ a bf:Organization ;
>                    bf:label "Bollingen Foundation" ] ;
>            bf:providerPlace [ a bf:Place ;
>                    bf:label "New York, N.Y. " ] ],
>        [ a bf:Provider ;
>            bf:copyrightDate "1964" ] ;
> or
>
> bf:lccn [ a bf:Identifier ;
>            bf:identifierScheme "lccn" ;
>            bf:identifierValue "63010708" ] ;
>
>
> --------------------------------------------------
> From: "[log in to unmask]" <[log in to unmask]>
> Sent: Tuesday, November 18, 2014 10:34 AM
> To: <[log in to unmask]>
> Subject: Re: [BIBFRAME] Blank nodes again
>
>>> Blank node identifiers are essentially variables (in SPARQL they are 
>>> an alternative syntax for variables)
>>
>> I dont think this is wrong, but in my experience it is more common to 
>> think of blank nodes as specifically existentially-bound variables 
>> with a scope that is the document in which they are found. So the 
>> triple:
>>
>> _:x :favoriteEggType :Chicken .
>>
>> makes the assertion, "There exists a thing, to which we will refer as 
>> '_:x', but only inside this document, the :favoriteEggType of which 
>> is :Chicken". If we see in the same document:
>>
>> _:y a :Farmer .
>> _:y :hates _:x .
>>
>> We can read "There exists a thing, to which we will refer as '_:y', 
>> but only inside this document, which is a :Farmer, and which :hates 
>> the thing to which, only in this document, we are referring to as 
>> '_:x'".
>>
>> Or if we see:
>>
>> _:x :fears _:z .
>>
>> And _:z doesn't appear as the subject of a triple in our document, we 
>> can read "There is a thing that, just inside this document, we will 
>> call '_:z', and the :Weasel that inside this document we call '_:x' 
>> :fears '_:z'", and so on. Because of the lack of a unique name 
>> assumption for RDF, it is not defined whether the :Weasel :hates the 
>> :Farmer, or someone else entirely.
>>
>> That is all rather awkward reading, and this is a well-known 
>> complaint about blank nodes. Existential qualifiers are useful, but 
>> in mass they can become confusing. It is like listening to a story 
>> told by someone who cannot remember anyone's name. Often RDF isn't 
>> meant for human consumption anyway, but analogous problems occur in 
>> machine processing. For example, as Thomas Berger remarked:
>>
>>> In practice this matters when one wants to add or remove individual 
>>> statements or subgraphs from graphs: When the graphs or subgraphs 
>>> have blank nodes as their origin, you usually can't.
>>
>> Often you can't because it is very difficult to calculate exactly 
>> what changes you are making in the possible interpretations of the 
>> graph. Simon Spero's example shows that: we don't, as he says, know 
>> how many :Weasels we actually have. And once we are no longer in the 
>> scope of our original document, we can only refer to a :Weasel by 
>> some kind of query. If the attributes of :Weasels don't support 
>> queries that will identify them uniquely, we more-or-less lose track 
>> of them. This is bad if, for example, we discover new information 
>> about our :Weasels and would like to record it in a useful way.
>>
>> There are occasionally good reasons to use blank nodes, but here:
>>
>> http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/
>>
>> are some cautionary remarks about them from Richard Cyganiak, one of 
>> the editors of the RDF standards.
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>> On Nov 18, 2014, at 12:06 PM, Simon Spero <[log in to unmask]> wrote:
>>
>>> On Nov 18, 2014 11:13 AM, "Joseph Kiegel" <[log in to unmask]> 
>>> wrote:
>>>
>>> >
>>> > In RDF 1.1 Concepts and Abstract Syntax, section 3.4, we find:  
>>> "Blank > node identifiers . are always locally scoped to the file or 
>>> RDF store, > and are not persistent or portable identifiers for 
>>> blank nodes".  [...] > Isn't it true, then, that blank node 
>>> identifiers, which are valid at > Library A, are not defined when 
>>> they get to Library B? This seems like > a problem.
>>> >
>>> > Is the use of blank nodes consistent with BIBFRAME's function as a 
>>> > carrier?
>>>
>>> What the specification means is that a blank node _:x that refers to 
>>> some thing in an RDF file transferred from A to B may not  refer to 
>>> the same thing except during in the one use of that file.
>>>
>>> It may not be the name of the thing in the stores at A *or* B, and 
>>> if the same file is ingested twice, it could refer to two different 
>>> things that happen to have the same values for the stated properties.
>>>
>>> Blank node identifiers are essentially variables (in SPARQL they are 
>>> an alternative syntax for variables)...
>>>
>>> Suppose we have the following file:
>>> ---------------
>>> _:x rdf:type :Weasel.
>>> _:x :favoriteEggType :Chicken .
>>> ----------------
>>>
>>> This says that there is something that is a Weasel and whose 
>>> favorite type of egg is Chicken.
>>>
>>> If we see this twice, we cannot tell how many chicken pickin Weasels 
>>> we have.
>>>
>>> A different file could use _:x to refer to some Chicken.
>>>
>>> Simon
>>>
>>

-- 
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

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