About YeeRDF

I don't know too much about RDF, but I see that this dicussion is about something that is previous: information representation. So I will address only some of the problems related with this matter.

Yee's article begins with some considerations about structure and granularity. I see some misunderstandings depicted in this phrase: "People who dislike the MARC21 format already argue that it its too granular and therefore requires too much of a learning curve before people can use it"

That's partially true. MARC21 is too granular, yes. But any database of some complexity is almost as granular as MARC. The problem is not the granularity but the exposed granularity, i.e., the degree of the core structure that is presented to the user. Any digitized representation has several levels of granularity. A field is not a field, but a string of characters, a character is not a character, but a portion of memory or a value in a register in the  micro processor, and so on. It depends on your point of view: a low level programer cares about memory areas, the programer of an application take the computer memory as a basement, so she sees "strings", the database manager sees "fields".

Following this logic, the librarian ... what does she see?. Before FRBR librarians always has seen "fields", since MARC21 sees "fields"; but librarianship is not about "fields". And that's the very reason the learning curve is so hard.

I have the same approach of you, Karen, when you talk about "things". The FRBR entities are some of the "things" that is about librarianship. MARC21, DublinCore, etc,  are just techniques for representing these things. Of course a professional must learn some of these techniques in many situations, but these are just tools which can be replaced when a more  appropiate one arrives. 

On question 1, you say: "The transcribed publisher, the cataloger supplied publisher, and the identifier for the corporate body that is the publisher of the resource – are these really the same thing?"

I answer the same as your implicit answer: no, they are not the same thing. In the model I've working on last years, I separate these entities following this schema: an entity (the corporate body) has many names, and it uses one of them for signing a resource (the cataloger supplied publisher). It has an  identifier which identifies it univocally as unique in a definite universe, in this case, the rest of the  publishers. And a little more granular: to be a publisher is just a role of the corporate body. An university, for example, perform many other actions than publishing.

That phrase of Yee goes on this direction: "I have defined two different classes for place: Place as Jurisdictional Corporate Body and Place as Geographic Area."

As you may suspect, my point of view is object oriented. Object technology is about defining things first: what they are, how they behave, which relationships establishes with other things, etc.

From that perspective, I can't agree with this: "a system works with data, and the key to systems functionality is in the data". That's true only for systems based on structural paradigm. Object systems doesn't work with data, they work with objects, and objects are not data structures. For objects, data is something secondary. Which is important is how objects behave; showing data in a particular way is one of the many ways an object behave; retrieving other objects is another one.

And I think that when you say "Many of the problems that we have in today's data are due to the fact that we present the data as a string with the elements in a single sort order, but we don't fully explain what those elements are" you are in the same conceptual direction.

You can't sort data, i.e. strings, other than alphabetically. But if personal name is an object, which is related with a person, who was borned in a country which has conventions, for example, a way of showing and sorting personal names, then you can sort it differently.

I could go on with similar considerations on the other questions, but I think it would be boring.

As a conclussion, for interact with RDF, supossing it is totally devoted to define and represent concepts, we may define an represent concepts as well in our domain. FRBR is just the first attempt to perform this task.

(My intention was to make a comment on "YeeRDF" but this blog doesn't admit more than 2000 characters)

Norberto Manzanos

CAICYT-CONICET

Argentina