N-Triples is plain-text serialization of RDF, nothing more. This is RDF's problem.
AndrewBibframe is movement into a model where there are many inter-dependencies and external requirements on the model. Going from an isolated industry standard to leveraging off international standradsAccessibility requirements;As do the programming languages used;But RDF in XML, RDF in HTML5, N-triple and JSON each bring their own requirements to Bibframe;In MARC-8 and MARC-21 you didn't have to concern yourselves with this, they essentially lived in isolation. In theory internationalisation was based on a 40+ year old model.This level of complexity would become an issue when records are being transformed into XML or HTML5 formats to be used by user agents, since accessibility requirements will kick in in various jurisdictions.And in theory the record might consist of multiple "language" tags since in script and romanisation would be different language tags in the BCP-47 sense.Two different functions and two different language tag schemes ... BCP47 vs ISO-639-2 (B)For instance RDF and XML would use one system for language tagging a record, and MARC and possibly. Bibframe use a different system for tagging the language of the item/object being described.if RDF is going to be used exclusively, but if you have N-triples and JSON in the mix as container formats ... different issue.And no, they aren't RDF's problems, RDF in XML format inherits a lot of features from XML and can leverage off ITS etc. Likewise RDF in HTML5 guise can leverage off internationalisation features in HTML5 or HTMLNext (Living HTML or whatever its called this week). The issues are more related to bibframe and the conversion process from MARC formats to Bibframe regardless of the container.
It will also impact on font rendering of content, in IE10 and latest versions of Firefox content marked up with a language tag of "tr" will kick in The Turkish language system in the font if present in the fonts OT tables, etc.
At least that's my high level tack on it.
On 8 January 2013 13:36, Ross Singer <[log in to unmask]> wrote:State Library of Victoria
Why are they issues, though? They're RDF's problems, not Bibframe's. Isn't that part of the point of using existing standards?-Ross.
On Monday, January 7, 2013, Andrew Cunningham wrote:
A lot of this is just tip of the iceberg ... esp if transforming to HTML5, language tagging in the record versus language tagging of the record, and a range of other issues.Although those legacy encodings specific to the library industry would not exist in BibframeUltimately the issues are more related to how the parsed content is going to be consumed or going to be used. If it is to be human editable or presented to user agents then more complex processing that inserts markup or formatting control characters that are not present in the MARC records would sometimes be required.
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.
328 Swanston Street
Melbourne VIC 3000
Mobile: 0459 806 589
Email: [log in to unmask]');" target="_blank">[log in to unmask]