Print

Print


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:
> 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:
>> 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 Schema.org <http://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]
>>     <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]  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