On 11/4/14 4:46 AM, [log in to unmask] wrote:
On Nov 3, 2014, at 8:25 PM, Karen Coyle <[log in to unmask]> wrote:
This is true, but it leaves us with the dilemma of how do we add new types. In the MARC world, this has been a real problem. When you cannot use a string, the new type has to be defined in the vocabulary before it can be used "in the wild."
If types are URI's then a library can mint its own URI (which will not be understood by anyone else, and may not be correctly used by its own system). If types are subclasses, then we have the problem that BF is "owned" by LC, and to add new subclasses we need an extension method that doesn't break our ability to share.
It is not true that adding a new type is difficult: (etc)
It's not technically difficult. It is "habitually" difficult because of the way the library world has handled standards in the past. And it sure looks to me like we're headed along that same path with BIBFRAME and with RDA.
Note the suggestion in the document that: " Aternatively, bf:title could be retained and bf:workTitle and bf:instanceTitle eliminated. bf:title would be distinguishable as a Work title (formerly, uniform title) or Instance title (formerly title proper) because it would be a property of a bf:Work or bf:Instance respectively."
Some of the "sub" title properties, e.g. bf:workTitle, either have a domain of bf:Work or bf:Instance. bf:title has the domain of Title. The statement above assumes that you would know whether you have a work title or an instance title because the bf:title would take on the "class" from the bf:Work or bf:Instance that it describes (predicates?). This is that complicated part of RDF where the domain of the property defines the class of the subject, not vice versa (as in XML, for example). A property is not a property of a class; a property's domain determines the "classness" of the subject.
Â If BIBFRAME is not assuming that the work title and the instance title are key "definers" of the entity, then that is fine.