Print

Print


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, schema.org, 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 schema.org or
bibo.



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

Ditto.


> 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.

Rob


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 schema.org,
>> 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] http://kcoyle.net
>> 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] http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>


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