RE: Disjointedness of FRBR classes

> > I agree that a "statement of responsibility" (datatype) property
> > feels somehow redundant, but I don't think it should cause us to
> > doubt the need for a "creator" (object) property.
> 
> No, it doesn't do that. They aren't actually redundant because the
> "creator" is (in library parlance) a heading,

I agree this is how we talk, but the metaphysics don't align with common sense reality. "Headings" aren't capable of creating anything; they're just words. Our treatment of "headings" as surrogates for the things being named is especially problematic in a heterogeneous multilingual networked environment.

> and the "statement of
> responsibility" is part of the transcribed surrogate for the title
> page. They are distinctly different data elements. Both are needed.
> (Personally, I could live without the statement of responsibility, but
> the cataloging rules - based on ISBD - are quite clear about its
> necessity.)

I agree there are use cases for "statement of responsibility" as a transcribed literal. Like you, I'm not sure they're worth the cost and confusion except in rare cases. The time would be better spent looking up and recording an identifier for the responsible party.

> 
> > As argued above, I think WEMI (Group 1 Entities) should be modeled
> > as subclasses of schema:CreativeWork/dcterms:BibliographicResource.
> > Treating Group 2/3 Entities as subclasses of same seems too
> > philosophical to me.
> 
> Maybe not the same, but there needs to be the possibility of a graph,
> perhaps a named graph, that includes all of the information needed for
> a complete bibliographic description, including everything you wish to
> index and display. 

If you buy my argument that FRBR WEMI are each subclasses of dcterms:BibliographicResource, then presumably the "complete bibliographic description" for each subclass will be distinctive. Combined they will cover the possibilities. Whether these various flavors of "complete bibliographic description" are limited to "concise bounded descriptions" or include cached information from surrounding entities (e.g. labels) has more to do with network optimization and specific use cases than anything else.

> This is one of the things that worries librarians
> about moving from MARC, which is a stand-alone record, to linked data.
> They are afraid of parts getting lost or not been available when
> needed. I presume that we will have a "transfer" format that
> encompasses the entire "bibliographic record" for data exchange.

I think that the notions of "open-world assumption", VoID Dataset, and "concise bounded description" are relevant here. Maybe JSON is worth mentioning also.

1) The open-world assumption implies we never have "complete information" about anything. Pretending otherwise is wasteful and burdensome. There is a serious flaw in the FRBR interpretation that says Manifestation "records" must also identify and describe their Expressions and Works. IMO, it should be perfectly reasonable to believe their existence is merely implied and/or can be accounted for elsewhere.

2) A VoID Dataset identifies a graph that (at least potentially) transcends diverse "records" (e.g. a bulk aggregation of N-Triples)
 
3) "Concise bounded description" implies minimal redundancy when transmitting "normalized" bundles of information as "records" (aka "documents" or "graphs"). 

4) I don't like people believing that JSON is fundamentally different from Linked Data, but maybe this is the little white lie they need to get past concerns about UI display.

Note that I'm not saying that all use cases can be satisfied with information delivered as either perfectly normalized "records" and/or a bulk N-Triple dump and/or UI-oriented JSON responses. Instead, I'm suggesting that these are useful alternatives to idiomatic XML record-based mashups that we are constantly getting frustrated by. 

Mostly I'm saying we need more intuitive vocabularies across the lot regardless of format.

> 
> > I don't see the harm of letting someone claim that a notebook is a
> > Book. Being able to say it is also a frbr:Item or frbr:Manifestation
> > would make it even clearer.
> 
> Remember that a FRBR:Item must instantiate a FRBR:Manifestation,

Sorry if this is picky, but you seem to be using "instantiate" in an unusual way. Here's an example for comparison:

:manifestation1 a frbr:Manifestation;
	frbr:isExemplifiedBy :item1.
:item1 a frbr:Item;
	frbr:isAnExemplarOf :manifestation1.

This says that :manifestation1 (an individual) is an instance of frbr:Manifestation (a class). Likewise, :item1 (an individual) is an instance of frbr:Item (a class). In contrast, you seem to be saying that :item1 (an individual) is an instance of :manifestation1 (also an individual), which isn't quite right. It would be better to say there is a cardinality constraint of 1 on the frbr:isAnExemplarOf property. These are two separate individuals that are closely and necessarily related. For comparison, you are a separate individual from your parents and yet closely/necessarily related to them. Nevertheless, you do not instantiate them. The cardinality constraint on hasParent is 2.
 
> which
> in turn must manifest a FRBR:Expression of a FRBR:Work. Everything is
> always at least:
> W|WE|WEM|WEMI. No bibliographic resource can be "just" an Item or a
> Manifestation. At least, NOT the way that FRBR is defined. An Item is
> always an Item *of*...

As I read it, there is a many-to-many relationship between frbr:Manifestation and frbr:Expression that undermines any tree-like notion of WEMI hierarchy.

I happen to believe that an item is just an item, a manifestation is just a manifestation, etc. At the same time, I would be willing to accept the implied existence of any part of the stack. After all, most frbr:Works only have a single frbr:Manifestation and vice versa. Granted, explicit identification and description of each individual in the WEMI stack would be useful, but sometimes being implied is good enough. Take most frbr:Expressions for example.

> 
> 
> >> Is a flip-book a book
> >> or a movie? (It *is* an example of moving pictures.
> >
> > I would argue that it is both a schema:Book AND a schema:Movie. This
> > gets back to my complaint about forcing things into a single type.
> 
> But weren't you saying that you wanted Book and Movie to be first
> class objects? To me that implies an either/or. It seems more
> plausible to have a resource that can have both Book and Movie aspects.

It hadn't occurred to me that "first-class object" was such a strange term. I'm going to try avoiding it in the future. 

I didn't mean to imply that these two classes should be treated as disjoint. I meant to imply that they should be treated as classes, not literal values. For example, I like this:

:12345 a schema:Book.

better than this:

:12345 frbr:whatever "Book".

Or this:

:12345 frbr:whatever xyz:Book.
xyz:Book a skos:Conept;
	skos:prefLabel "Book".

> 
> > I like the Schema.org vocabulary because I think that intuition is
> > underrated.
> 
> In the cataloging interfaces, a cataloger chooses a primary format
> (Book, Movie) and is given a template that looks not unlike the
> schema.org template (except it's in MARC, but it could be a friendlier
> display). The library record makes it possible to display a book or a
> movie to the user. I don't see what we lose in terms of services.

I'm not opposed to "primary format" (or more precisely "primary class") as a basis for edit templates. What I'm opposed to is "primary format/class only". On the surface it seems simpler to say things can only be of one type, but in the library domain we gouge rather than scratch this surface. I should be able to say that something is both a Book and a Movie and have all the corresponding properties of both at my disposal. Any other workaround is bound to be weird.

> 
> But the library determination of type is not based on intuition.
> Libraries have rules that determine which template you choose. That's
> because our use case is that we want to use each other's data and it
> takes work to change someone else's Book to your Serial if you
> disagree on the primary format. If we didn't need to share so deeply,
> the rules would be less important.

IMO, libraries wouldn't have to depend so heavily on rules if they catered more to intuition. I don't think the real problem is format differences so much as it is element vocabulary differences. If the element vocabulary(ies) are well-defined (specifically using RDFS/OWL) and intuitive, then more people/systems would be able to contribute to and use the Web of Data via open-world assumption microdata structures rather than closed-world assumption macrodata structures.

Jeff

> 
> kc
> 
> >
> > Jeff
> >
> >>
> >> kc
> >>
> >> > Books, Movies, and the promotion of modern "digital"
> >> > manifestations/items to 1st class objects makes me appreciate
> >> > http://purl.org/spar/fabio as an efficient RDF vocabulary for the
> >> > library domain. Unfortunately, http://purl.org/spar/fabio/ doesn't
> >> > roll off the tongue like http://schema.org/.
> >> >
> >> > OTOH, "FRBR" and Schema.org seem to be equally blame-worthy in the
> >> > sense that both are namespace-centric and single-type-at-a-time
> >> > oriented. I suspect this is just a passing phase for Schema.org,
> >> > though.
> >> >
> >> > Jeff
> >> >
> >> >> -----Original Message-----
> >> >> From: Jakob Voss [mailto:Jakob.Voss@gbv.de]
> >> >> Sent: Monday, October 31, 2011 7:37 PM
> >> >> To: ian.davis@talis.com
> >> >> Cc: tim.hodson@talis.com; public-lld@w3.org
> >> >> Subject: Re: Disjointedness of FRBR classes
> >> >>
> >> >> Hi Ian,
> >> >>
> >> >> > I'm not party to the full discussion but in our bib data
> modelling
> >> >> > at Talis we moved on from FRBR towards describing the real
> >> >> > objects, not an abstract model of them.
> >> >>
> >> >> If you discuss about FRBR long enough, works, manifestations,
> >> >> expressions
> >> >> and items become pretty real ;-)
> >> >>
> >> >> > Rob Styles at Talis blogged about it a couple of years ago but
> his
> >> >> > blog is temporarily offline. Here's a substantial quote from it
> >> >> though:
> >> >> > http://www.frbr.org/2009/11/13/styles-bringing-frbr-down-to-
> earth
> >> >>
> >> >> Does this reflect current work at Talis on modeling/describing
> >> >> bibliographic
> >> >> resources?
> >> >>
> >> >> http://consulting.talis.com/2011/07/british-library-data-model-
> >> >> overview/
> >> >>
> >> >> I don't expect Talis and British Library to implement full FRBR,
> but
> >> I
> >> >> wonder about the lack of any concept of holdings, items, copies
> etc.
> >> >> compared to at least editions. Do the central URIs in the BL
> model
> >> >> represent physical books? What about books with two or more
> >> >> copies in the BL - two unrelated URIs? Are there no relations
> >> >> between multiple editions of the same book?
> >> >>
> >> >> Jakob
> >> >>
> >> >> --
> >> >> Verbundzentrale des GBV (VZG)
> >> >> Digitale Bibliothek - Jakob Voß
> >> >> Platz der Goettinger Sieben 1
> >> >> 37073 Goettingen - Germany
> >> >> +49 (0)551 39-10242
> >> >> http://www.gbv.de
> >> >> jakob.voss@gbv.de
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Verbundzentrale des GBV (VZG)
> >> >> Digitale Bibliothek - Jakob Voß
> >> >> Platz der Goettinger Sieben 1
> >> >> 37073 Goettingen - Germany
> >> >> +49 (0)551 39-10242
> >> >> http://www.gbv.de
> >> >> jakob.voss@gbv.de
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Karen Coyle
> >> kcoyle@kcoyle.net http://kcoyle.net
> >> ph: 1-510-540-7596
> >> m: 1-510-435-8234
> >> skype: kcoylenet
> >>
> >>
> >
> >
> >
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
>

Received on Wednesday, 2 November 2011 05:27:55 UTC