Print

Print


On Monday, January 7, 2013, Andrew Cunningham wrote:

> Just reading through Roy Tennant's article at
> http://www.thedigitalshift.com/2013/01/roy-tennant-digital-libraries/library-of-congress-bibframe-initiative-part-2/
>
> And it got me to thinking, a point quoted in the article was that each of
> the implementations is doing different transformations on the MARC records
>
> The second point is that RDF/XML, N-triples and JSON formats are supported.
>
> One markup format, one plain text format, one javascript format.
>
> Which got me to thinking, each of these formats has different
> requirements; for instance:
>
> * RDF/XML would use markup where N-triples and JSON would use Unicode
> Formatting Control Characters.
>
> * RDF/XML and N-triples would reference characters outside the Basic
> Multilingual Plane directly as characters or as six digit hexadecimal
> numerical entities, while JSON requires to four digit hexadecimal numerical
> entities representing UTF-16 surrogate pairs.
>
> * RDF/XML can use characters directly or XML/HTML style hexadecimal or
> decimal numerical character references or named entities (e.g. Ā)while JSON requires javascript nuerical entities ,e.g. \u0100; finally
> N-triples is more agnostic but has some interesting requirements, e.g.
> requires support for all Unicode characters and references charmod, and
> indicates a preference for actual characters over escaped characters,
> except where required by the encoding.
>
> So different intermediation processing of characters maybe required for
> each format, as well as logic to handle markup versus Unicode format
> control characters.
>
> If this makes sense?
>

It does, but I'm not sure why it matters?  It's all RDF and presumably one
would be using RDF parsers to handle the character encodings.

I mean, we deal with this already with MARC8, UTF-8 (in MARC-21), and
MARCXML. It's only really a problem because we use encodings that nobody
else in the world uses so we have to come up with our own parsers and
serializers (and, in many languages, MARC-8 support is just ignored).

The RDF community is already dealing with this (plus other serializations),
so I don't really see how this is an issue.

Although, admittedly, I may be missing your point here.

-Ross.

>
>
>
> On 8 January 2013 08:55, Andrew Cunningham <[log in to unmask]<javascript:_e({}, 'cvml', [log in to unmask]);>
> > wrote:
>
>> I hate to tell you this but numbers aren't language neutral.
>>
>> But there are bigger internationalisation issues and potentially a lot of
>> things that bibframe will inherit from parent markup standars including
>> language tagging, bidi, encoding requirements, variatiin selectors, its,
>> etc.
>>  On 08/01/2013 8:42 AM, "J. McRee Elrod" <[log in to unmask]<javascript:_e({}, 'cvml', [log in to unmask]);>>
>> wrote:
>>
>>> Andres Cunniungham said:
>>>
>>> >Although, my primary interest and concern is the internationalisation
>>> >architecture that will underly Bibframe.
>>>
>>> Moving from language neutral numbers to English based html markup is
>>> hardly a move towward internationalisation.
>>>
>>>
>>>    __       __   J. McRee (Mac) Elrod ([log in to unmask] <javascript:_e({},
>>> 'cvml', [log in to unmask]);>)
>>>   {__  |   /     Special Libraries Cataloguing   HTTP://www.slc.bc.ca/
>>>   ___} |__ \__________________________________________________________
>>>
>>
>
>
> --
> Andrew Cunningham
> Project Manager, Research and Development
> Social and Digital Inclusion Team
> Public Libraries and Community Engagement
> State Library of Victoria
> 328 Swanston Street
> Melbourne VIC 3000
> Australia
>
> Ph: +61-3-8664-7430
> Mobile: 0459 806 589
> Email: [log in to unmask] <javascript:_e({}, 'cvml',
> [log in to unmask]);>
>
> http://www.openroad.net.au/
> http://www.mylanguage.gov.au/
> http://www.slv.vic.gov.au/
>