RE: Disjointedness of FRBR classes

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Tuesday, November 01, 2011 12:37 AM
> To: public-lld@w3.org
> Subject: RE: Disjointedness of FRBR classes
> 
> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> 
> > IMO, "FRBR" purists are shooting themselves in the foot by denying
> > the reality of "Group 1 Entity". That's why I'm attracted to
> > http://schema.org/CreativeWork and/or
> > http://purl.org/dc/terms/BibliographicResource as useful
> > alternatives. I suspect that the former has the inside track because
> > the URI actually resolves to something human-friendly, (among other
> > reasons).
> 
> Jeff, I agree that a Group 1 Entity seems useful in many
> circumstances. It does not, however, as I read it, have the same scope
> as http://schema.org/CreativeWork or dc:/BibliographicResource. I
> believe that you need to at least include the Group 2 entities from
> FRBR to have something equivalent to the schema.org class, because
> that class includes a creator entity. 

I am confused by the statement that schema:CreativeWork "includes a creator entity". The "creator" *property* refers to either a Person or Organization entity but I don't think that implies those entities are "included" in the CreativeWork.

Here is a simple example using the Schema.org vocabulary:

:creativeWork1 
	a schema:CreativeWork;
	schema:name "Hamlet";
	schema:creator :person1 .
:person1 
	a schema:Person;
	schema:name "Shakespeare" .

Here's the same example using the DC Terms vocabulary:

:creativeWork1 
	a dcterms:BibliographicResource;
	dcterms:title "Hamlet";
	dcterms:creator :person1 .
:person1 
	a dcterms:Agent;
	dcterms:title "Shakespeare" .

The same patterns COULD be applied at a finer granularity if FRBR mapped to a higher level of abstraction like so:

# I'm hedging my bets by using both schema:CreativeWork and dcterms:BibliographicResource. Take your pick.
frbr:Work 
	rdfs:subClassOf schema:CreativeWork, dcterms:BibliographicResoure .
frbr:Expression 
	rdfs:subClassOf schema:CreativeWork, dcterms:BibliographicResoure .
frbr:Manifestation 
	rdfs:subClassOf schema:CreativeWork, dcterms:BibliographicResoure .
frbr:Item 
	rdfs:subClassOf schema:CreativeWork, dcterms:BibliographicResoure .

# Group 1/2 relationships defined in section 5.2.2 of the FRBR Final Report
frbr:createdBy 
	rdfs:subPropertyOf schema:creator, dcterms:creator;
frbr:isRealizedBy 
	rdfs:subPropertyOf schema:creator, dcterms:creator;
frbr:isProducedBy 
	rdfs:subPropertyOf schema:creator, dcterms:creator;

> Neither FRBR Group 1 nor ISBD
> include entities that represent creators (they include only a
> statement of responsibility, which is a textual statement).

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.

As suggested above, FRBR splits the "creator" (schema:creator or dcterms:creator) property into 3 implied subproperties with a Group 1 Entity (schema:CreativeWork or dcterms:BibliographicResoure) on one end and Group 2 Entity (schema:Person, schema:Organization, dcterms:Agent) on the other. The models aren't really all that different as the mappings above should demonstrate. (I could show these side-by-side in UML if someone though it would help.)

> 
> DC's BibliographicResource seems to be rather abstract and I think you
> could make the argument that it is either equivalent to FRBR:Work
> and/or to the entirety of FRBR using all 3 groups. (Actually, I'd like
> to hear which of those others think it is... or if it is something
> else altogether.)

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.

> 
> >
> > Likewise, I think that "FRBR" does our patrons (and thus us) a
> > disservice by rejecting the vital and intuitive notions of
> > http://schema.org/Book and http://schema.org/Movie as 1st class
> > objects.
> 
> It will be interesting to see if those objects work in practice, and
> what people do with the grey areas. We all know what a prototypical
> book looks like, but there are edge cases, like a spiral-bound
> soft-cover 100-page government training document. Is it anything
> between covers? What if the covers are missing? 

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.

:notebook_manifestation1
	a schema:Book, frbr:Manifestation;
	schema:description "spiral-bound soft-cover 100-page government training document." .
:notebook_item1
	a schema:Book, frbr:Item;
	frbr:isAnExemplarOf :notebook_manifestation1;
	schema:description "gutted w/ missing covers" .

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

> My guess is that
> schema.org can afford to ignore the edge cases in a way that libraries
> cannot. schema.org is not endeavoring to catalog and preserve
> materials. I think that libraries can display materials to patrons AS
> IF books and movies were first class objects without having to design
> their schema to treat them as such.

I like the Schema.org vocabulary because I think that intuition is underrated.

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

Received on Tuesday, 1 November 2011 19:00:49 UTC