Print

Print


From: Simeon Warner

 

Thanks for the comments Simeon. I have a few observations.

 

> Section 2.2 emphasizes the 'BR' which in that section I think has to be

> read as "bibframe record" (the local data) rather than "bibframe

> resource" in the sense of the web architecture [2].

 

In the past few weeks, we have had fairly intense discussion about proposed clarifications and definitions for BIBFRAME terminology.

 

Here is what we think:   A BIBFRAME Resource is any member of the class bf:Resource. Any bf:   class is a subclass of bf:Resource, and bf:Resource is a subclass of rdf:Resource.  And any RDF resource is a Web resource (anything identifiable by a URI) but not vice versa - not every Web resource is an RDF resource - point being that we think all BIBFRAME resources are RDF resources. 

 

There are BIBFRAME classes bf:Work and bf:Instance.  A Member of one of these classes is a BIBFRAME Work or Instance (respectively).   BR, then, would be the hypothetical class which is the union of bf:Work and bf:Instance.  (I say "hypothetical" because there is no such class yet defined in the BIBFRAME vocabulary. Such a class has been proposed, but likely will not be defined.  It is introduced in the Annotation model just for modeling purposes.)

 

Now, I realize - and this is an important point - that the DRAFT model currently says that BR is the class of BIBFRAME resources, and this is NOT consistent with the above. It is, in fact, a subclass. So that just means that the Annotation model is not quite in line with current terminology, and of course that's because all this has been thought out more recently than the model.  Anyway, the Annotation model will be brought in line with BIBFRAME terminology in the next draft.

 

My point is that a member of BR is a BIBFRAME Work or Instance, and is therefore a BIBFRAME Resource. You seem to be saying, no, it's not a BIBFRAME Resource, it's a BIBFRAME description. I'm not sure what distinction you are making. My apologies if that is a misrepresentation of what you are saying.

 

 

>To me the key motivation for an

> annotation model (rather than use of a direct predicate relationship

> such as "x is_a_review_of y") is that one can then make statements

> about the act of annotation (who did it, when, why, etc.).

> 

We agree.

 

> I think the predicates "bf:payloadSource" and "bf:payloadSourceLink" do

> not play well in RDF. In the case of multiple annotation bodies, which

> do they refer to? In even the existing set of classes there are two

> bodies for cover art (bf:coverArt and bf:coverArtThumb).

> is removed if instead the body (or bodies) is the subject of predicates

> indicating the source (e.g. "body bf:source authority").

 

This is a reasonable suggestion and we will consider it for the next draft.

 

 

 

 

> ## Editorial notes

>

> ### date format

>

> The examples show dates in the ISO8601 form without hyphens (e.g.

> '20131010')

 

My mistake. Will be corrected.

 

 

 

> ### example domains

>

> The examples use domains 'xyz.org', 'xyz.com', 'local.org' for dummy

> URIs. Some of these resolve and it would be better to stick with

> official example domains (such as 'example.org' and 'example.com' [5]

> to avoid possible confusion with real domain names.

 

Will do.

 

 

> ### section 5.1 Cover Art

>

> The image has a property "annotates" whereas the set of triples has

> more specific sub-property "bf:coverArtFor". I assume the image should

> have the sub-property.

 

Well both are valid, so I suppose your point is that they should be consistent? I wonder if it is more illustrative to show both forms (perhaps add an explanatory note).

 

Thanks again, Simeon, these comments are very useful.

 

Ray