Print

Print


Unfortunately, we've explained this to Mac this SEVERAL times, but he 
insists on coming back and saying the same tired (and wrong) thing. I 
don't think there's a way to get this message through.

Then again, all of us need to be thinking more about labels and less 
about property names. I know that Protege will display vocabulary labels 
as an option, but I don't know what it does with labels in multiple 
languages, and many labels that I've seen do not include the language 
tag. We need to get more into that groove, because it will ultimately 
solve a number of problems -- such as the lengthy discussions I'm seeing 
on a recent mailing list about the naming of properties. Really, it 
shouldn't matter a whole lot.

And... speaking of... the FRBRer and RDA in RDF vocabularies do not use 
natural language terms for property names, as a way of being truly 
international. They have properties like:
   http://rdaregistry.info/Elements/w/P10003

Of course, some folks jumped all over them for not using 
"understandable" property names, but when your properties are things 
like: "has other distinguishing characteristic of the work"@en, then a 
thoughtful developer might thank you for relying on labels. In any case, 
RDA did something very similar to MARC and got dinged for it. The 
answer, in the end, has to be in our software tools, not in how we name 
things for machines.

kc

On 4/5/15 1:28 PM, Steven Folsom wrote:
> I just want to make a point about BIBFRAME abandoning the language neutral numeric tagging of MARC. Because ontologies are written in RDFS and OWL, URIs are what we use to identify classes and properties. This means we can have multiple labels in different languages for classes and properties. Once the model solidifies, this would be work to prioritized by different language speakers.
>
> Here's a quick description of how it works:
> http://answers.semanticweb.com/questions/12385/how-to-make-multilingual-ontology
>
> I work with a very talented cataloger who responded to an early kick-the-tires session of the BIBFRAME Editor with, "Would it kill you to just use the MARC tags?!?" when discussing fields in the editor. In her defense, she was more than comfortable with the model; it was just a new vocabulary and new (pretty clunky) tool. I bring this up because MARC tags have become their own language spoken with varying levels of fluency within the library domain and nowhere else. After working with library metadata over 10 years I'm still only an entry level MARC speaker; I know what a 502 is, but I have to look up a "blank 4" in the context of 6xx's. Hopefully the learning curve will be less steep for whatever comes next.
>
>
> Forgive any typos, sent while on the run.
>
>> On Apr 4, 2015, at 1:39 AM, J. McRee Elrod <[log in to unmask]> wrote:
>>
>>
>> Stephen asked:
>>
>>> If youíre not here to have a constructive conversation, then why
>> /are you here?
>>
>>
>> To question the wisdom in this economic climate of abandoning
>> investment in present methodology.  SLC for example has many MARC
>> based programs, not just cataloguing software.  We have printed cards
>> labels, cumulating catalogues,  KWIC indexes, new book lists, subject
>> bibliographies, among other products. I suspect many libraries have
>> MARC based procedures in addition to cataloguing.  To replace them
>> would be costly.
>>
>> Two things bother me most about many Bibframe posts: an unawareness of
>> the complexity of the bibliographic universe (e.g., assuming every
>> ISBN represents a different manifestation as did one poster), and a
>> lack of awareness of economic reality.  Since so many think Internet
>> replaces the need for libraries (including Bill Mahar with whom I
>> usually agree), our clients are finding it difficult to have present
>> funding continue, much less a major investment as leaving MARC would
>> require.  (Most of our client government library  have been closed,
>> with books discarded or distributed among staff offices.)
>>
>>
>> I am not a lover of MARC (too many fixed fields dating from when it
>> was difficult to access variable fields, too much redundancy, foolish
>> order of 5XX, coding state university press publications as governnent
>> docuuments, etc., etc.).  MARC certainly needs massive improvement.
>> Our ILSs also need major development.  We are spending too much effort
>> on the building blocks, and not enough on the structure.
>>
>> A public library's cataloguers just had a demo of the library's new
>> ILS (selected by administrators on the basis of the acquisitions,
>> circulation and OPAC modules).  The catalogue module will not accept
>> input of 33X or 264.  They have to import a record with those fields,
>> and edit it for a new resource!  I see no evidence that vendors will
>> be ready for Bibframe.
>>
>> I question the wisdom of abandoning language neutral tagging for
>> English language labels.  Language by its very nature is ambiguous.
>>
>> Perhaps I am influenced by living in a bilingual country, having
>> worked in an Asian country, and having clients in Europe and Asia.
>> The Anglo centrism of RDA and Bibframe I find unfortunate.
>>
>> If we can go and return between MARC and MARCXML, that might be a
>> partial solution for those who wish to engage with the Web.  At 83, I
>> don't expect to live to see a successful implementation of Bibframe,
>> based on what I read here.
>>
>> Unless SLC  can export Bibframe data as MARC compatible (as we now
>> export RDA data as AACR2 compatible for those who can't afford to
>> upgrade their ILS, and insist on GMDs), I doubt SLC would survive any
>> longer than I.  I fear many libraries would suffer the same fate;
>> their institutions may choose to close libraries rather than incur
>> this expense.
>>
>> Thanks for asking that question.  I enjoyed answering it.  Sorry I
>> upset you.
>>
>>
>>    __       __   J. McRee (Mac) Elrod ([log in to unmask])
>>   {__  |   /     Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
>>   ___} |__ \__________________________________________________________
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

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