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