Print

Print


Yes, if the criticism is that BIBFRAME requires creation of too many resources (either blank nodes or reusable resources) then that is a somewhat different issue from blank nodes alone.   Most of the complaints I hear about blank nodes is that they are not linked-data friendly (vs. creating reusable resource) which is what I though your point was.

Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
Sent: Wednesday, May 13, 2015 6:26 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] RDF dual properties

Of course blank nodes are not required.

Your original request was, as an example of a larger issue, to find a way to avoid using bf:Title resources.  It looks as though we either get blank nodes or bf:Title resources.  (Yes, we could use another form of persistent identifier instead of bf:Title, but does that save effort?)


Joe


From: Denenberg, Ray<mailto:[log in to unmask]>
Sent: Wednesday, May 13, 2015 1:26 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] RDF dual properties

I believe the issue of blank nodes is a red herring.    There is nowhere in the BIBFRAME “specification” (i.e. vocabulary + guidelines + papers, etc) that dictates that you have to create a blank node; you can always create a persistent resource.

If I am mistaken, point me to where it is implied that a blank node is required, and it will be corrected.  There is no intent that blank nodes be required;  it is an implementation choice.

That said,  Rob’s approach similarly does not necessitate blank nodes.   If you want to create a reusable resource for
_:work bf:hasTitle [ rdf:label "Lord of the Flies" ]
there is nothing to preclude you from doing that.

Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: Wednesday, May 13, 2015 4:13 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] RDF dual properties


We already have that problem :) We shouldn't introduce another one.

Rob

On Wed, May 13, 2015 at 1:05 PM, Joseph Kiegel <[log in to unmask]<mailto:[log in to unmask]>> wrote:
This approach introduces more blank nodes, which are viewed as a problem in some quarters.  Are we trading one problem for another?


Joe


From: McCallum, Sally<mailto:[log in to unmask]>
Sent: Wednesday, May 13, 2015 12:54 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] RDF dual properties

With your correction does this solve all of our problems?  Sally

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of Robert Sanderson
Sent: Wednesday, May 13, 2015 2:16 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] RDF dual properties


The higher level question is why this is needed at all.  In the Annotation space it has introduced significant issues ... I won't go in to the details, but the use is not encouraged and restricted to very specific situations.

So ... in my opinion:

(c) Pick one and have a consistent model, rather than requiring content providing implementers to choose between options and consumers to implement both in order to be interoperable.  As the information in the short term will likely be created by conversion scripts, and in the future via editors, no human ever needs to manually construct the objects in the model, so there is no opportunity cost in doing the right thing.

Which could be simplified to:

(c`) Always have a resource, and allow it to be very simple wrapper around a string:

_:work bf:hasTitle [ rdf:label "Lord of the Flies" ]


HTH,

Rob


On Wed, May 13, 2015 at 10:58 AM, Denenberg, Ray <[log in to unmask]<mailto:[log in to unmask]>> wrote:
We are working on a number of improvements to the BIBFRAME vocabulary – more on that soon.

One critical issue is “dual properties”.  There has been discussion on this, here on this listserv, but rather than rehash old discussion I ask that we take a fresh look.

If a single RDF property can, for some triples,  have as its object a literal (string), and for other triples, a resource – is this necessarily a bad thing?  Or should there be dual properties defined.

There are several such potential BIBFRAME properties  (by “potential”, I mean in the revised/improved vocabulary we are working on) and while I hesitate to single out one, I’ll use title for an example.

Clearly, people want to be able to say ….

            <http://bibframe.example.com/workX>   bf:title   “Lord of the Flies” .

… without having to construct a bf:Title resource.

And it is equally clear that there will be a need, in many cases, to create a bf:Title resource.

So what’s better (a) a single property, bf:title, that can take on literal or resource;  or (b) dual properties, bf:titleLiteral and bf:title  (or bf:title and bf:titleResource; take your pick).


The debate seems to go along these lines:  Approach (a) imposes on a client the burden of inspecting the object to determine its type.  On the other, hand it is argued, the added complexity of dual properties outweighs that burden.

Furthermore,  It seems that the debate hinges on whether or not you are optimizing the ontology for inferencing: if so, then you want dual properties.  If not, then the extra complexity of dual properties should be avoided.

In fact, this exact debate was played out recently in the W3C, over annotations. Many (if not most) annotations are going to be short strings, “simple textual bodies”,  in some cases, a few characters. The first draft of the model defined dual properties for an annotation body, hasBody and hasBodyLiteral.   There was debate and the result is that the current draft model (http://www.w3.org/TR/annotation-model/)  has a single property, hasBody.

As is the case for  annotations, I believe, we are not optimizing the BIBFRAME vocabulary for inferencing, which would suggest approach (a).

Opinions on this issue are solicited.

Ray







--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305