About the model: Question 8
8. Is it possible to define a class subject and a class person and still use the class subject for a work about a person? How do you model that relationship between two classes in RDF? (The same problem occurs with works about corporate bodies and works about other works.)
“Yes. An *instance* work can be a sub-class of any other class expressed through OWL, without that instance inheriting all those classes, but you need to express it in the ontology. It’s a bit messy, but certainly doable.There’s two main ways of expressing relationships ; the class-instance hierarchy (which you’re referring to above), and using OWL (or some parts of standard RDF) to just model the things free form. Unless someone tries to validate your RDF with RDFS statements, you can build up pretty much anything you like.First, there’s some modeling differences between relationships between classes and between instances of those classes, and different “rules” (some are rules, other guidelines, some just gut feelings). We can create classes ; animal dogWe by default express the taxonomical relationship between these. Constraints between these two can be ; animal dog RDFS : instances cannot be “fish” RDFS : instances can be “furry types” furry types catNow, this gets complicated of course, but OWL ; “Oscar” is_a : dog OWL : is_subclass_of “furry types”… is perfectly legal ; the instance “Oscar” is now a subclass of “furry types” because Oscar is a particularly furry example of a dog (he really is :). I guess all of this again points to understanding all the RDF stack in necessary to do any serious modeling. I guess I would at this point be keen to model it a bit simpler. In reality, you can model all of these things without the constraints, and still get a decent model for inference models to work with. You can do ; book_a is_a manifestation_x translation_y idea_zand let inference engines work out the details. Both will work in the long run, although I understand the want and sometimes need for rigid ontologies”–September 11, 2007 email from Alexander Johannesen.
DECISION: Based on Bruce D’Arcus’ suggestion that subject should be a relationship, I defined only the FRBR entities of concept, object, time period and place and treated subject as a relationship, with subject subdivision being treated as a relationship between subject properties. All subject properties are defined as having domain of Resource.
I’m getting confused about when to label examples using class names and when to label them using properties. I got most of the way through coding the examples using only properties, assuming that that is enough since the properties are defined as belonging to particular classes in the model. However, when I came to subject headings, I realized that if you use only the properties of subject headings, you cannot specify that a particular subject heading is for a geographic heading, the name of a person, etc. In those cases, I started using class names in the examples, but I suspect I have run across an underlying problem in the model here.