Trying to catch up on this thread, and I can't help but wonder: when is a
string just a string? Are the classes being discussed here (Title, Note,
etc.) really substantial enough to merit more complex modeling?

As one member of our local BIBFRAME group wondered, is the purpose of all
these separate properties, or potential new types (e.g., bf:frequencyNote
or bf:FrequencyNote), just to let us generate display constants in an OPAC?
Do users really need to know that the string "Annual" is a Frequency Note
rather than just a plain old note? Why do we need this kind of note in the
first place?

If we want structured data, wouldn't it be better to use a property like
bf:frequency and point to a defined value vocabulary for frequency of
issuance, with attendant URIs?

Of course, it would be useful to be able to specify the language of a note,
but couldn't that be done simply with a language tag on the string (e.g.,

Similarly, with Titles, is it really that important to be able to keep
parsing out things like subtitles? I guess a hypothetical researcher might
want to do a macroanalysis of the evolution of subtitles over time, but
that seems like an edge case.

So, why not just jettison everything but bf:titleStatement and be done with
it? I'm being purposely extreme, and I don't mean to be obtuse, but I think
it would be helpful if a clearer case could be made here--not for the
soundness of a class-based approach to data modeling (I think that case has
been made), but of the specific value of modeling strings like Note and
Title in this way. Certain subproperties like bf:variantTitle or
bf:localNote might be necessary, but as a cataloger I have to say that
radical simplification (vis-à-vis the mess of MARC) has its charms.


Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

On Wed, Nov 5, 2014 at 7:43 PM, Young,Jeff (OR) <[log in to unmask]> wrote:

>  One of the reasons I like is that their properties are based
> on the probabilistic and
> instead of the deterministic
> and
>  Set theory has its limits in a practical world.
> Jeff
> On Nov 5, 2014, at 7:12 PM, Simon Spero <[log in to unmask]> wrote:
>   On Nov 5, 2014 6:12 PM, "Karen Coyle" <[log in to unmask]> wrote:
> > That's not quite what I said. You can infer class of the subject from
> properties, but cannot do the versa -- you cannot infer the class of a
> property from the class of the subject. Therefore where:
> >
> > bf:workTitle has domain bf:Title
> >
> > and
> >
> >
> > :X a bf:Work
> >       bf:workTitle[  a bf:Title  ;
> >             bf:titleValue"Heart of Midlothian"  ]  .
> >
> > You do not infer that bf:workTitle has a class of bf:Work from :X. Note
> that this is a common confusion for folks coming from XML or OO, where
> class is inherited to properties.
> I am not trying to be offensive; I really don't  understand what you mean
> by "class is inherited to properties" ;  could you possibly give an example
> in some object oriented language?
> Simon