Print

Print


I think that Cyganiak's take on it is worth looking at. He says:

<quote>

  * They are fine for transient data that’s not meant to be stored.
  * They can be the only viable option if a changeable upstream data
    source doesn’t provide identifiers that persist across requests/updates.
  * They can be tolerable for unimportant auxiliary resources that don’t
    correspond to a meaningful entity in the domain of interest (e.g.,
    some n-ary relations) and are not worth the hassle of maintaining a
    stable URI.

In all other cases, blank nodes should be avoided. </quote>

Joseph's questioning about how they relate to sharing is pertinent. If 
we see "BIBFRAME data" (which I define as data coming out of BIBFRAME 
applications, not all data using the BIBFRAME vocabulary) as being 
primarily limited to  the exchange of complete BIBFRAME "documents" 
between libraries, then you may not have a problem. But what about other 
uses of the data? Will anyone perform confederated searches across data 
from different sources? What happens if you share Bf:Works among 
datastores with different BF:Instances, all of whom have locally defined 
bnodes? Perhaps a bigger picture that isn't limited to something that 
essentially mimics the exchange of MARC records would answer these 
questions.

kc


On 11/18/14 8:57 AM, [log in to unmask] wrote:
> Blank nodes (or anonymous nodes) are part of RDF and are not a problem 
> at all. They are essential to build embedded resources. When the RDF 
> graph moves physically (e.g. from triple store to triple store) they 
> must get renumbered internally so the embedded resource is still valid 
> at the other place, and can be continued to use in the new environment 
> without internal graph node collisions.
>
> These tasks are opaque to applications, they are part of RDF graph 
> management of the RDF store implementor, and are not related or 
> controllable by Bibframe.
>
> All embedded resources can be turned into externally visible resources 
> by assigning IRIs to them, if you want to avoid embedded resources. 
> The result is often too verbose and does not look very concise, and in 
> most cases, there is no requirement of doing that.
>
> Jörg
>
>
> On Tue, Nov 18, 2014 at 5:07 PM, Joseph Kiegel 
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>     There has been discussion of blank nodes earlier on the list, and
>     perhaps agreement that there should be as few of them as
>     possible.  But we don't have a model where they are eliminated
>     entirely.
>
>     I have a question about blank nodes in regard to BIBFRAME as a
>     carrier.
>
>     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".  A function of BIBFRAME, as a carrier, is to move
>     linked data from one institution to another, that is, from one RDF
>     store to another.  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?
>
>
>
>

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