RE: [open-bibliography] MARC Codes for Forms of Musical Composition

Erik,

My justification for saying this is a "logical conclusion" was the quote I gave from Barbara Tillett's "What is FRBR?" <http://www.loc.gov/cds/downloads/FRBR.PDF> I'll repeat it since it got dropped: 

"Before FRBR our cataloging rules tended to be very unclear about using the words “work,” “edition,” or “item.” Even in everyday language, we tend to say a “book” when *we may actually mean several things*." (emphasis added).

Barbara believes the concept of "book" is ambiguous. I believe her. As far as I know, FRBR does not resolve this conflation by encouraging us to believe a "book" is a "manifestation".

Keep in mind that I'm not the one you have to worry about conflating books and chocolate desserts here. I'm the guy who says different "types" should be identified separately. I can imagine someone creating a chocolate desert that conforms to a reasonable definition of book (messy as it may be). I have no problem with using owl:sameAs in this case but would still encourage them to identify the rdf:types separately:

http://bakershop.com/bibo:Book/12345 owl:sameAs http://bakeryshop.com/bakeo:Chocolate_cake/67890 

Jeff

-----Original Message-----
From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On Behalf Of Erik Hetzner
Sent: Friday, July 09, 2010 12:47 AM
To: public-lld
Subject: Re: [open-bibliography] MARC Codes for Forms of Musical Composition

Hi Jeff,

Before I rant & rave, I want to say that I very much agree with your
point in a later email:

> Using umbel:isLike is just a suggestion and there are clearly
> broader implications (including multiple rdf:types) as we've been
> noting. These are excellent examples to use as the basis for this
> kind of discussion and I hope everyone takes the opportunity to
> share their opinions about the relative importance and limits of
> identity and sameness.

You & Andy have certainly caused me to think more carefully about the
use of sameAs.

At Thu, 8 Jul 2010 09:36:09 -0400, Young,Jeff (OR) wrote:
> 
> We don't need to call this a rule or best practice. Call it an
> appeal to respect subtle differences.
> 
> Here's Ross' example taken to its logical conclusion:
> 
>   <http://purl.org/NET/book/isbn/0192838024#book> a 
>     <http://purl.org/NET/book/vocab#Book>,
>     <http://purl.org/ontology/bibo/Book>,
>     <http://vocab.org/frbr/core#Work> ,
>     <http://vocab.org/frbr/core#Expression> ,
>     <http://vocab.org/frbr/core#Manifestation> ,
>     <http://vocab.org/frbr/core#Item> .

I am having trouble seeing why that would be the logical conclusion.
The FRBR WEMI semantics are quite distinct from the semantics of the
others. You may as well say that the logical conclusion is that a book
is also a chocolate dessert.

Here is the definition of a book/vocab#Book:

  The abstract concept of a particular book, e.g. Stephen Hawking's A
  Brief History of Time.

Here is the definition of a bibo/Book:

  A written or printed work of fiction or nonfiction, usually on
  sheets of paper fastened or bound together within covers.

As far as I am concerned, there is no semantic problem with saying
that a URI has both those types. There is no conflation.

You seem to think that my point is that one should assign as many
types as one can think of to a resource. It is not. My point is,
rather, that one must balance the trade-offs between identifying
different resources (e.g. the difference between a person as a person
and a person as a concept) and the understanding when two statements
are about the same thing (e.g. Ross’ example that Bob Dylan
(songwriter) knows the same people that Robert Zimmerman (person)
knows).

In other words:

- “Assign distinct URIs to distinct resources.” [1]
- “A URI owner SHOULD NOT associate arbitrarily different URIs with the
  same resource.” [2]

I am sure we can all agree to that! The tricky part is figuring out
when resources are distinct or the same. :)

best, Erik

1. http://www.w3.org/TR/webarch/#id-resources

2. http://www.w3.org/TR/webarch/#uri-aliases

Received on Friday, 9 July 2010 14:16:26 UTC