Print

Print


Unfortunately, Jeff, you suggest SKOS/foaf:focus for just about every 
situation. Maybe you should write up your reasoning and/or arguments for 
that so we can understand why. And in particular, what the "this" is 
that you think it solves in this case. Then we can discuss the 
merits/demerits of that approach.

kc

On 2/15/13 3:36 PM, Young,Jeff (OR) wrote:
> I've suggested SKOS/foaf:focus as a solution pattern for this. I'll 
> repeat it.
>
> Jeff
>
> Sent from my iPad
>
> On Feb 15, 2013, at 6:33 PM, "Andrew Cunningham" 
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>> Hi Karen.
>>
>> The old library approach made sense back then. To be honest the 
>> library sector was tackling Internationalization issues well before 
>> the rest of the IT industry and had to create solutions that worked.
>>
>> But jnternationalisation has undergone dramatic changes since the 
>> late 1990s, and honestly has left the library industry far behind.
>>
>> This results in differences in terminology and concepts. Paradigm shifts.
>>
>> For instance an ordered list of identifiers to me comprises multiple 
>> components ... indexing and stop words on one hand, collation and 
>> sorting on another ... and then string matching for search terms is 
>> separate again.
>>
>> I suspect that bibframe doesn't need to address either collation or 
>> string matching ... those would be inherited. Although bibframe may 
>> need to identify a preferred normalisation form for data. There are 
>> various pros and cons esp for CJKV data.
>>
>> What would need to be addressed is the indexing side. Whether this 
>> should be included in bibframe, in a separate spec or via discussion 
>> with the UTC and the CLDR people should be approached to include it 
>> in CLDR so it is accessible outside library industry and accessible 
>> within core development tools is a matter for debate ... if that 
>> makes sense?
>>
>> What we have currently evolved through an historical context. But the 
>> context is very different now. And the industry need to leverage off 
>> the advances in internationalisation
>>
>> A.
>>
>> On Feb 16, 2013 9:33 AM, "Karen Coyle" <[log in to unmask] 
>> <mailto:[log in to unmask]>> wrote:
>>
>>
>>     On 2/15/13 1:08 PM, Andrew Cunningham wrote:
>>>
>>>     The more I consider Internationalization and bibframe, the more
>>>     I realise that adopting RDF places bibframe in a different data
>>>     ecosystem, inheriting a lot of internationalisation features
>>>     from the Unicode and W3C sides.
>>>
>>>     So slabs of stuff like collation may not and should not be part
>>>     of bibframe ever, but should be addressed in other forums like CLDR
>>>
>>
>>     I like the idea that collation, collocation, and order are
>>     application issues, not data issues. However, that is quite a
>>     leap from previous library practice where the goal of heading
>>     creation was precisely creating an ordered list of identifiers.
>>     If this non-collocation concept were to be accepted, wouldn't
>>     that also set bibframe apart from RDA (which I believe still has
>>     quite a bit of textual heading creation in its rules)?
>>
>>     I'm concerned that we seem to be heading in a few different
>>     directions, with no clarity as to how those may or may not ever
>>     work together. Quite honestly, moving to RDA at a time when we
>>     don't even know *when* (and perhaps *if*) we will be able to
>>     accommodate it in a machine-readable form [1] doesn't sound like
>>     a great idea.
>>
>>     kc
>>     [1] And, no, I don't think that coding "RDA in MARC" is anything
>>     more than lipstick on a ... well, on a whatever. It seems like a
>>     square-peg, round-hole exercise, more pain than gain.
>>
>>
>>>     On Feb 16, 2013 12:54 AM, "Tom Emerson" <[log in to unmask]
>>>     <mailto:[log in to unmask]>> wrote:
>>>
>>>         Andrew Cunningham writes:
>>>         [...]
>>>         > * sorting/collation in the Unicode context occurs within
>>>         either a
>>>         > languageless multilingual context, ie DUCET. Which is/has
>>>         just undergone a
>>>         > few very interesting changes, and locale specific
>>>         collations identified in
>>>         > CLDR where one or more collations are defined per locale
>>>
>>>         The engineering complexity for systems like EBSCOhost and
>>>         EBSCO Discover
>>>         Service is that many collections are multilingual and are sold
>>>         internationally. A customer in Sweden will want their data
>>>         in Swedish
>>>         sort order, while another in Egypt will want a tailoring
>>>         that uses
>>>         English with a preference for Arabic. Supporting all these
>>>         possibilities
>>>         in a scalable fashion is a real challenge.
>>>
>>>         > * matching is more problematic, since it brings in both
>>>         the need for
>>>         > normalisation and matching grapheme clusters. Although
>>>         ideally for some
>>>         > languages these would need to be custom rather than
>>>         default grapheme
>>>         > clusters.
>>>
>>>         Indeed... internationalized sorting is a very tricky thing
>>>         to get
>>>         right. You're pretty much guaranteed to annoy everyone.
>>>
>>>         Obligatory BibFrame Tie-in: I think collation is way out of
>>>         scope for
>>>         this project. Obviously filing rules are necessary in any
>>>         cataloging
>>>         system, and will need to be addressed, anything beyond that
>>>         is not worth
>>>         discussing. Adopting RDF has pretty much insured that we are
>>>         moving to
>>>         Unicode (and good riddance to MARC-8).
>>>
>>>             -tree
>>>
>>>         --
>>>         Tom Emerson
>>>         Principal Software Engineer, Search
>>>         EBSCO Publishing
>>>         [log in to unmask] <mailto:[log in to unmask]>
>>>
>>>         The opinions in this message do not necessarily constitute
>>>         those of
>>>         EBSCO Publishing.
>>>
>>
>>     -- 
>>     Karen Coyle
>>     [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>>     ph:1-510-540-7596  <tel:1-510-540-7596>
>>     m:1-510-435-8234  <tel:1-510-435-8234>
>>     skype: kcoylenet
>>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet