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