VIAF doesn't conflate the foaf:Person and the skos:Concept. These are two different types of things that are related via foaf:focus. The meaning and purpose of these terms are documented in those vocabularies and it would be an error to assume their use in VIAF is idiomatic.

That said, it is interesting to walk through specific examples to illustrate the mechanism and ponder ways to iron out new use cases. I see that Jorg has raised such a case, so I'll shift over to that.

Jeff

Sent from my iPad

On Feb 16, 2013, at 1:06 AM, "Karen Coyle" <[log in to unmask]> wrote:

Jeff, I've looked at VIAF. Many of us have looked at and used VIAF. And I must say that I am not entirely comfortable with the use of skos:concept for persons. This is why I would like more of an explication of the reasoning for using skos for things that are not concepts. Unless, perhaps, that the use of skos:concept in VIAF is something like the LC authorities designation of a name authority heading being usable ALSO for subjects. A bit more documentation about the decisions made in the development of VIAF would be very useful. The code itself doesn't provide those explanations, at least not to me.

kc

On 2/15/13 4:45 PM, Young,Jeff (OR) wrote:
[log in to unmask]" type="cite">
Look at VIAF.

Sent from my iPad

On Feb 15, 2013, at 7:38 PM, "Karen Coyle" <[log in to unmask]> wrote:

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:
[log in to unmask]" type="cite">
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]> 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]> 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]> 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]

The opinions in this message do not necessarily constitute those of
EBSCO Publishing.

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 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

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