After DC2008 discussion with Karen and others, I started playing with an idea for an alternative RDF/OWL modeling style. It takes FRBR more loosely as a requirements document for distinctions that should be made, rather than a set of specific classes.

Some notes here – http://lists.w3.org/Archives/Public/public-owl-dev/2008JulSep/0110.html
rough diagram here – http://www.flickr.com/photos/danbri/2891150205/

Thinking was that the FRBR distinctions can also be made using RDFS/OWL’s subclassing machinery, by subsetting the universe at different levels of specificity.

This is entirely an exploratory exercise, I’m not suggesting it as a mature alternative to any of the FRBR-as-classes designs. I just suspect that some data will naturally take this shape, and so documenting the design pattern could be worthwhile.

All that aside, I’m interested to hear of any updates to the models here… especially the RDF expressions…

I’m having trouble understanding one suggestion from Bruce D’Arcus though: “Treating simple properties like titles as full resources is modeling overkill in my view.” Can someone explain this a bit to me? I still don’t get it. (Thanks!)

The examples are all displaying in RDF/XML now, but I still can’t seem to manage to debug the XML in the model well enough to get it to display, so it still appears as a Word document. I’ll keep working on this. (I’m getting a message about the rdfs lines not corresponding to the rdf document definition…)

I’d like to say that I agree with Bruce’s comment about Works, Expressions, Manifestations and Items being disjoint. Richard and I pored over the FRBR specification and we believe that making these classes disjoint best expresses the intent of the FRBR specification authors.

Subclassing has nothing to do with the way the data is presented to the end user – it’s a way of making logical separations of distinct data types. The structure that matters to the user is the relationships between the things being described. When a user’s search turns up a work then its relationships (the RDF properties) should be used to include related resources in the display. That’s the whole point of modelling this as RDF – expressing useful semantic relationships between things so people can discover things more easily.

Yeah, I can see that. I can also see that it’s a little unnerving to explode the traditional integrated record like this.

For the bibo ontology work, I had previously played around a lot with FRBR (and Fred had experience with it from work on the musical ontology), but decided instead to keep things simpler and just focus at the traditional document view (for the most part). But that doesn’t mean dismissing FRBR entirely. Indeed, we’ve defined bibo:Document as a subclass of frbr:Manifestation. This move, then, reflects a perspective that sees FRBR as allowing one to layer a more abstract view on top of legacy data; sort of like a bridge to FRBR.

Admittedly, if you were to integrate this metadata into a system oriented around FRBR it’d yield some data duplication, but I see that as a small price to pay. I personally don’t want to have to think about FRBR; would rather leave that to others

Intermediation tool requirements
Carrier encoding format
Materials applied to carrier
Carrier polarity
Carrier generation
Carrier base materials
Process used to produce carrier
Configuration of playback channels
Carrier recording type
Carrier broadcast standard
Carrier name
Relationship among manifestations
Relator terms
Expression access
Appendages to the expression
Nature of modification
Nature of the relationship
Other Creators
Related works
Mode of issuance
Original physical characteristics of work
applied material:
original base material:
Content of work
Principle creator relator term

It doesn’t say “inheritance” but since the subjects are only associated with the work level that’s the only think you can conclude. Personally, I think this is an example of some fuzzy thinking that needs to be re-thought.

Bruce: “I’d say that the manifestation embodies some textual expression of a work that has topics x, y, z. The topics are linked at the work level, and it shouldn’t be any more complicated than that.”

Well, I can grok that, but we still need some kind of workable relationship between the manifestation and the work, and I do think that if you look at the attributes in FRBR you’ll find inconsistencies in what you can assume about the relationships between the different levels.

Bruce: “Do you follow me here on the implications of subclassing in RDF and why I think the existing FRBR-in-RDF work has it right?”

I think I get the point, but I need to go back to the FRBR-in-RDF and see how it was done there.

Yeah, I wouldn’t presume inheritance in this case. Does the report actually say that explicitly, or is that just how some in the library world read it?

I’d say that the manifestation embodies some textual expression of a work that has topics x, y, z. The topics are linked at the work level, and it shouldn’t be any more complicated than that.

Keep in mind that inheritance in RDF is typically used in order to enable inferencing. So if I say X is a subclass of Y, then if I add some triples that say some URI is of type X, then the system will add another triple that says it is of type Y.

But it gets more complicated. Let’s switch back the FRBR view and assume Martha’s modeling. If I define a property (let’s say x:translationOf) whose domain is x:Expression, and then I make a statement that some URI has that property. The inferencer will then logically conclude not only that this resource is in fact an x:Expression, but also that it is an x:Work. Clearly, that would be an incorrect inference, since a translation is typically understood to be a new expression.

Do you follow me here on the implications of subclassing in RDF and why I think the existing FRBR-in-RDF work has it right?