I apologize for my delayed reply. I was traveling and had limited access to email. Thanks for your careful reading of my article and your comments.
The issue of how to represent the distinction between FRBR Works and more concrete realizations of Creative Works in Schema.org is certainly one of the most unstable parts of the models being discussed in the Schema Bib Extend community and developed at OCLC. What must be resolved is whether it serves the goal of improved library resource description to induce the distinction in a published ontology that does not recognize it; and if so, how to do it parsimoniously. That’s a tall order.
The solution presented in the article that uses the draft proposed Schema.org properties hasInstance/isInstanceOf represented thinking by OCLC colleagues and some in the Schema Bib Extend community at the time that I was writing my article—around March 2013 or so. The idea was to use the Schema Creative Work properties to create more and less concrete descriptions corresponding roughly to FRBR Works and Manifestations and wire them together with the hasInstance/isInstanceOf draft properties. This idea tracked very closely what was being discussed in the BIBFRAME Early Experimenters’ group, which was also interested in drawing distinctions between Work-level and Manifestation-level properties. Of course, we considered using rdfs:subClassOf, and for the same reasons you give: the description would be more parsimonious and understandable by data consumers outside the library community. Though an rdfs:subClassOf relationship implies that the more abstract properties would be inherited into the more concrete description, this result seemed entirely fortuituous, given that the author, title, and subject of a Work is usually the same as that of a Manifestation.
So why not use rdfs:subClassOf instead of the properties we have invented? The main problem is that the relationship between a FRBR Work and a Manifestation is not strictly a set-theoretic one. Instead, we have many reasons to believe that Work and Manifestation are strongly associated concepts whose relationship must be defined, by experts in library resource description. In other words, we need to 'own' this part of the ontology of resource description. First, FRBR Work is somewhat fuzzy and may not be relevant to all resource types. If the resource is unique, it may make sense only to create a ‘Manifestation’-level description with no associated Work, and the ambiguity in the Schema.org Creative Work class permits us to do that. In other cases, Work may need to have more than one level of hierarchy, as we grapple with how best to represent the common content in a literary classic that has been published many times, has been translated, recast as a comic book, and made into a movie or opera. Another issue is that FRBR Works and Manifestations may specify the same properties but have different values, which implies that the relationship between the two classes is not strictly one of inheritance. For example, the Manifestation for a work of fiction may introduce a different subtitle or subject headings that usually supplement but may sometimes replace the Work-level values.
At OCLC, we are still discussing how to represent the relationship between FRBR Works and Manifestations in our models. The hasInstance/isInstanceOf is a bit inelegant, as you point out, but part of the problem is the name. We need to be careful about defining properties containing the word ‘instance’ if it is not obvious that the relationship is between Works and Manifestations is one of instantiation. More strictly speaking, an 'instance' of a FRBR work would be a particular Work, not a Manifestation. In some cases, such as a narrative poem handed down through a preliterate oral tradition, the Manifestation is immaterial or irrelevant--or at least, many interesting things can be said about it without ever needing to mention its physical realization. In light of problems like this, the Schema Bib Extend Community has taken another stab at the problem of relating Works to Manifestations by considering the property names exampleOfWork and workExample to connect the different levels of the FRBR model through some formalism that falls short of a set-theoretic relationship. Here is a pointer to the relevant discussion: <http://www.w3.org/community/schemabibex/wiki/CreativeWork_Relationships>
Yet others in the Schema Bib Extend community have argued that the distinction need not be made at all – see the ‘Work/Manifestation’ discussion at <http://www.w3.org/community/schemabibex/wiki/Areas_for_Discussion>. But the problem with doing nothing is that we would have no conceptual underpinning for asserting that some collections of creative works have the same intellectual content – a problem that publishers have not addressed in any meaningful way. So we continue to look for a solution.
All the best,
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Vladimir Skvortsov <[log in to unmask]>
Sent: Tuesday, October 01, 2013 9:49 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] The revised version of the Schema/BIBFRAME position paper is now available
That is very delicate but important matter in my opinion, to find right
balance between existing standard properties and new ones being created
for more informativeness.
Please note that isInstanceOf in the Figure 2.1 of proposed document is
essentially the same as standard rdfs:subClassOf, except for the case when
Instance is a single subject not defined as Class. That is BIBFRAME
Instance. However even in this case we could consider Instance consisting
of copies and define it as Class as well. It leads us away from bf: and
oa:, of course, but uses standard properties that corresponds
to “minimalist philosophy emerging from the Schema Bib Extend initiative”,
as I see, and it makes sense for me and creates no dubbing. Besides, such
approach allows to describe any hierarchies – semantic ones, like FRBR, as
OCLC proposes, or structural, like Serials – see for example my
On the other hand if new properties (in bf: or oa:) are defined correctly
with correct references to standard ones, one can use them if he wants,
for example, going to use custom applications in line with standard
browsers and crawlers. Last ones would work correctly with such properties
National Library of Russia