[log in to unmask]" type="cite">
Hi Karen, Adam,
On Tue, Nov 4, 2014 at 7:21 AM, Karen Coyle <[log in to unmask]> wrote:--
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.
Given that it's not technically difficult, we should determine how to steer the ship away from the known dangerous waters.
In my opinion, that steering goes something like:
Ensure that the work:* is well founded on standards* is able to be understood by someone who does not have a 20 year cataloguing tenure* is well documented* is able to be implemented* is in fact implemented, and in the same way by two independent systems
We should make it easy to adopt the well understood and better methodology. But the first step is to work on the technical side ... which is what we're doing. History alone will show whether we're successful :)
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.
Surely the subject's class is determined by a statement with the predicate "rdf:type"?You can *infer* a class based on the range or domain of predicates, but that doesn't somehow trump an absolute assertion ... which all of the examples have, and should be mandatory in any reasonable implementation.
It's actually easier to *not* do it this way, as you can generate unintended inferences. If you mistakenly attached instanceTitle to a Work, that's not an error, it just implies to a reasoner that the Work is also an Instance. Much easier to just consistently use bf:title that has no such inferences.
If BIBFRAME is not assuming that the work title and the instance title are key "definers" of the entity, then that is fine.
BibFrame should not do this if it is, and therefore it is (or should be) fine. :)
Rob SandersonTechnology Collaboration FacilitatorDigital Library Systems and ServicesStanford, CA 94305
-- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600