On Thu, Nov 6, 2014 at 12:53 PM, Karen Coyle <[log in to unmask]> wrote:

>  Rob, it's not a theoretical question but a practical one. Much of the
> existing bibliographic data in the world does not follow FRBR or BIBFRAME,
> and many communities may never think about the difference between a Work
> and an Instance.

Sure. So why would those communities that do not follow bibframe then
decide that they should (a) use bibframe and (b) use it incorrectly?

An easy example is a standard citation -- of which there are bazillions in
> the gazillions of already published articles, many of which are being
> digitized. A standard citation has elements like:
> author (bf:Work)
> title (bf:Instance)
> publisher (bf:Instance)
> date (bf:Instance)
> pages (bf:Instance)
> Should this data be coded in BibTex,, or whatever, it will
> almost certainly have a single resource identity to which the metadata
> elements are assigned. Presumably, at some point, this data and library
> data will be swimming in the same LoD soup, available for exploration and
> recombination.

And presumably they would then have to mint new identifiers to distinguish
the Work from the Instance, if they wanted to actually use bibframe.

> (Note that a lot of work is going into making citations linkable, e.g. at
> PLOS.)

Using bibframe? I would guess not.

Then look at the folks who are intending to follow FRBR -- e.g. RDA -- and
> you see a different division that (arguably) has three abstract levels and
> one physical one. (You could argue that bf:Instance is still abstract,
> because it does not have actually physicality; that is reserved for the
> bf:Item.)

I don't buy the argument that people who are intending to follow a
different model will suddenly require the same resource to be both an
abstract concept and a physical thing at the same time.  They simply
wouldn't use bibframe, the same way that bibframe doesn't use or

> In addition, some communities within GLAM have argued that their division
> between abstract and physical will differ from what has been laid out in


> The most radical case is that of the unique museum piece or work of art,
> which some art librarians consider indivisible, at best encompassing
> frbr:work and frbr:item, but apparently that isn't universally accepted.
> The A-V people have already weighed in to BIBFRAME that they need some
> bf:Instance properties available for bf:Work. [1]

+1 to not asserting restrictive domains on predicates that imply impossible
class combinations, to allow allied communities to work with us even though
they have slightly different modeling requirements.


> Basically, there's not going to be a single interpretation of the entities
> of description. What we need, then, is to pursue the most efficient route
> to interoperability.

Yes ... and that is explicit types and not requiring inferences based on
specific domain knowledge.


On 11/6/14 10:22 AM, Robert Sanderson wrote:
> Hi Karen, all,
>  I'm confused as to when a resource can be both a Work and an Instance at
> the same time.  When can a resource be both an abstract concept (Work) and
> a class of physical objects (Instance)?
>  I don't mind if people do inferencing in the privacy of their consuming
> application, but I definitely don't want to require it for every
> application -- be as simple as possible and no simpler.  The simple method
> here, IMO, is to be explicit about the class of the resource.
>  Rob
> On Wed, Nov 5, 2014 at 11:56 AM, Karen Coyle <[log in to unmask]> wrote:
>> On 11/4/14 5:01 PM, Robert Sanderson wrote:
>>   >>
>>  Surely the subject's class is determined by a statement with the
>> predicate "rdf:type"?
>> >
>>  You can *infer* a class based on the range or domain of predicates, but
>> that doesn't somehow trump an absolute assertion ... which all of the
>> examples have, and should be mandatory in any reasonable implementation.
>>  It's actually easier to *not* do it this way, as you can generate
>> unintended inferences.  If you mistakenly attached instanceTitle to a Work,
>> that's not an error, it just implies to a reasoner that the Work is also an
>> Instance. Much easier to just consistently use bf:title that has no such
>> inferences.
>> >>
>>  [snip much]
>>   If BIBFRAME is not assuming that the work title and the instance title
>>> are key "definers" of the entity, then that is fine.
>> >
>>  >BibFrame should not do this if it is, and therefore it is (or should
>> be) fine. :)
>>  Well, this is where we disagree. But perhaps we just have different use
>> cases. It sounds like you are warning BIBFRAME not to do inferencing, but
>> in the open world, inferencing cannot be prevented. If you want to prevent
>> inferencing on Works and Instances then you need to eliminate those as
>> classes for all properties. If you want to prevent any combination of Work
>> and Instance graphs, then you have to get into some strict disjointness,
>> but which only applies when inferencing occurs. Pretty ugly stuff.
>> In addition, I actually do want to be able to create a "thing" that is
>> both a bf:Work and a bf:Instance -- why? Well, why not? If I'm working with
>> bibliographic data created in DCterms or something simple like,
>> I see no reason why I cannot express that, for purposes of sharing, as:
>> :myThing
>>   bf:instanceTitle [blah] ;
>>   bf:creator [blah] ;
>>   bf:subject [blah] ;
>>   bf:publicationDate [blah] .
>> I also don't see a need to use rdf:type (or "a" in ttl) unless those
>> types provide necessary functionality. My impression is that the primary
>> use of rdf:type is to make data creators feel like they've created a
>> "record structure" or graph based on the type. However, it's not the
>> rdf:type but the identifier for the subject that holds it all together, and
>> any "thing" can be of more than one type. The type, whether implicit or
>> explicit, provides semantics, not structure. My suspicion is that those
>> semantics will be rarely used because of the overhead of inferencing. At
>> the same time, I can see reasons, mainly having to do with the cataloging
>> function that FRBR was designed for, for wanting to search and retrieve all
>> bf:Work properties for a defined entity, whether or not that entity has
>> separate graphs for Works and Instances. The best example of that would be
>> combining data from RDA and BIBFRAME, even though they have different
>> definitions of the bibliographic entities.
>> kc
>> --
>> Karen [log in to unmask]
>> m: +1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>  --
>  Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
> --
> Karen [log in to unmask]
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600

Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305