Also... it might make sense to treat some of the material-specific information (maps, music) as coherent extensions to BF rather than mixing them together in a general "notes" rubric. I see no reason why detailed maps information couldn't be its own graph, annotating the Instance, available when desired but treated as an optional extension for those who don't need it. Development of such a body of metadata could be given to whatever organization maps librarians use to represent them. The "one record to rule them all" may not be the best way to go, and with the ability of RDF to link together any graphs, we now have  technology that would allow this kind of specialization.

kc

On 11/6/14 7:29 AM, Karen Coyle wrote:
[log in to unmask]" type="cite"> 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 screen.

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.)

kc
[1] http://www.w3.org/community/openannotation/


On 11/5/14 6:10 PM, Tim Thompson wrote:
[log in to unmask]" type="cite">
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]> wrote:
One of the reasons I like Schema.org is that their properties are based on the probabilistic http://schema.org/domainIncludes and http://schema.org/rangeIncludes instead of the deterministic http://www.w3.org/2000/01/rdf-schema#domain and http://www.w3.org/2000/01/rdf-schema#range.

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



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

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