Tim, I think this is a question worth asking. We can't answer the 
question unless we have some idea of what we want to do with the data. 
So using your subtitle example, in what situation do you have to know 
the difference between a title and a subtitle? (I once had a use case 
for that: in record merging in a union catalog, where the recording of 
sub-titles wasn't consistent; we could compare titles and 
titles+subtitles separately. Don't know if this still is needed, tho'.)

Like you, I feel like not all notes are equal - aspect ratio, 
cartographic ascension and declination, dissertation institution .... 
etc. If it's worth providing this information, it's worth providing it 
in a way that you can do something with it other than display it on a 

General notes, tables of contents, and descriptions, btw, could be 
treated as annotations (in the sense of Open Annotation [1]) and 
therefore the annotation type could be part of the annotation. Some time 
back (about a year ago?) BF was aligning with OA, but retreated from 
that because OA was not allowing plain text annotations. I saw recently 
that as they are going through the standards process, they may be 
changing that rule. (Rob could confirm or deny, as he runs that group.)


On 11/5/14 6:10 PM, Tim Thompson wrote:
> 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., "@en")?
> 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
> --
> 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] 
> <mailto:[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]
>     <mailto:[log in to unmask]>> wrote:
>>     On Nov 5, 2014 6:12 PM, "Karen Coyle" <[log in to unmask]
>>     <mailto:[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

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600