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:

Joseph Kiegel <[log in to unmask]>

Reply-To:

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

Date:

Tue, 18 Nov 2014 11:35:43 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (133 lines)

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

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

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