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