Print

Print


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.

[snip much]

 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

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305