The mention of VIAF by Rob below caught my attention and I passed it on to Jeff Young who has done most of the VIAF RDF work.
Here is his response:
The view that bibliographic entities are names is too limiting. For example, the latest UNIMARC authority format explicitly recognizes the existence of a "primary entity" that is clearly differentiated from its name:
"Primary entity - The entity, named in the 2-- block of the record, for which the record was created. Data in the 1-- block generally pertain to characteristics of the primary entity."
What FRBR lacks (apparently intentionally) is a higher-level of abstraction to cover all classes of "primary entity". (FRSAD Thema comes close, but its restrictive definition makes it unusable for things that are merely potentially the subject of a Work.) As a simple and interoperable alternative, VIAF follows the general lead of LCSH by using SKOS as the basic model of authority data:
- The idea of an authority file is mapped to skos:ConceptScheme
- The idea of "bibliographic entity" is mapped to skos:Concept
- The idea of name as a class is mapped to rdf:PlainLiteral or skosxl:Label.
- The ideas of established and variant headings are mapped to skos/xl:prefLabel and skos/xl:altLabel.
This basic model allows for flexibility in the modeling of the "primary entity". For basic interoperability, the skos:Concept can be treated as the "primary entity". More natural models like FRBR and FOAF entities can be accounted for by using foaf:focus.
<http://viaf.org/authorityScheme/VIAF> a skos:ConceptScheme .
<http://viaf.org/viaf/102333412/#skos:Concept> a skos:Concept ;
skos:inScheme <http://viaf.org/authorityScheme/VIAF> ;
foaf:focus <http://viaf.org/viaf/102333412/#foaf:Person> ;
foaf:focus <http://viaf.org/viaf/102333412/#rdaEnt:Person> .
<http://viaf.org/viaf/102333412/#foaf:Person> a foaf:Person .
<http://viaf.org/viaf/102333412/#rdaEnt:Person> a rdaEnt:Person .
Here's a complete view of the Jane Austen cluster:
> ** use of SKOS
> In this context I would consider the use of SKOS harmful. SKOS is a
> great approach to publishing existing subject classification schemes
> where there isn't the time or money to remodel them. It is a poor
> cousin to describing the classes and relationships properly and has
> significant negatives in that a subject heading for the city of Paris
> is not the same as the city of Paris.
A major problem is that we don't have sufficiently developed and agreeable models of reality yet. SKOS ConceptScheme, SKOS Concept, and SKOS Labels provide us with a basic level of interoperability that will allow us to develop and experiment across multiple open and closed-world models.
> I would avoid it completely in the context of authority data in
> preference to rdf properties and rdfs classes.
I think that a Linked Data model for authority control needs to be based on OWL rather than straight RDF/RDFS. Mapping the "primary entity" to owl:Thing is too abstract and mapping them to a single ontology (e.g. FRBR) is too confining. SKOS has the features we need for authority control without forcing a premature choice for the model(s) of the future.
From: Metadata Object Description Schema List [mailto:[log in to unmask]] On Behalf Of Rob Styles
Sent: Tuesday, November 30, 2010 3:57 AM
To: [log in to unmask]
Subject: Re: [MODS] MADS/RDF for review
Hi all, my 2 pence worth...
Not a regular here, joining you specifically for the MADS/RDF discussion.
** Comments so far
Some of the comments so far are a tad harsh. It's great to see LoC
doing this stuff even if it's not exactly as one might have approached
it. They know their data, maybe we should try to be a bit more
** Conceptual approach
I've worked with library data for a long time and it's not simple
stuff. A common first mistake is often to assume that something like
the name authority talks about people and organisations when in fact
it talks about "bibliographic entities" - the names printed in books,
These have been modelled and re-modelled over many years and authority
data has evolved to meet specific needs. It is not an ideal starting
point for publishing Linked Data.
However, I think authority data could be approached differently to
MADS/RDF. Where MADS/RDF uses bibliographic terms, many of which come
from the record structures employed, I would prefer to see real-world
terminology used. So, a class of "Name" would be a good thing to have,
then we can talk about names. Where it is possible to identify a real
person it would be good to use a class of Person (ideally the foaf
one) and where we know the name is a pseudonym it would be great to
have a Pseudonym class too. The current MADS/RDF approach remodels the
authority /record/ where it may be preferable to model the authority
The downside to that approach is that it can make round-tripping
between the syntaxes harder. Consider round-tripping MARC and MARC/XML
as compared with MARC and Dublin-Core XML?
I would look again at anywhere you have a structure word such as
/element/, /list/ or value as they are likely to be describing a
record rather than describing things from the world.
** use of SKOS
In this context I would consider the use of SKOS harmful. SKOS is a
great approach to publishing existing subject classification schemes
where there isn't the time or money to remodel them. It is a poor
cousin to describing the classes and relationships properly and has
significant negatives in that a subject heading for the city of Paris
is not the same as the city of Paris.
I would avoid it completely in the context of authority data in
preference to rdf properties and rdfs classes.
** use of rdf:List
List support is coming in the syntaxes and query languages, but it is
not really there yet. Querying lists is painful right now and they are
a difficult structure for people to understand and work with.
If a name has several alternative forms then simply list them. If
sequencing really is important then consider using rdf:Sequence (which
has different side-effects but is easier to work with than rdf:List).
I doubt, though, that sequencing really is important in any of this if
the record-ness of the model has been addressed.
** standalone or mixing of ontologies
Comments on the list suggest re-using other namespaces and, on the
whole, I would agree. Only, though, where they do actually describe
the same thing as you are describing.
The counter argument is that LoC should hopefully be a long-term,
stable and persistent place for classes and properties describing
bibliographic names. You have a good case for keeping them in your own
namespace, but a less good case for re-inventing the wheel.
I hope that helps and that we can get to a really great authority
representation from this. :)
PS - how have VIAF solved some of these problems?
On 29 November 2010 23:30, Erik Hetzner <[log in to unmask]> wrote:
> Please consider the environment before printing this email.
> Find out more about Talis at http://www.talis.com/
> shared innovation(tm)
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
> Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America.
> ---------- Forwarded message ----------
> From: Erik Hetzner <[log in to unmask]>
> To: <[log in to unmask]>
> Date: Mon, 29 Nov 2010 15:30:42 -0800
> Subject: Re: [MODS] MADS/RDF for review
> At Sun, 28 Nov 2010 15:27:42 -0500,
> Bruce D'Arcus wrote:
>> I'm going to be awfully blunt.
>> This is a horribly complicated way to represent these data that a)
>> doesn't play well with others, and for that reason b) nobody will use
>> outside a small circle of the library world. It reflects no attempt to
>> reconcile the idiosyncratic library view of these things (people,
>> places, etc.) with the rest of the world, and so despite the nod
>> towards open, linked data, it is not.
>> As for some specific comments, I'll just go the core of the problem,
>> which is the purpose statement at the beginning, and in particular
>> this statement:
>> "MADS/RDF is a more specifically defined data model to represent the
>> complexities of authority data."
>> This is circular logic to the extreme: why on earth does anyone
>> consider it reasonable to design a "new" data model whose purpose
>> appears is to represent the "complexity" of an old model? What value
>> is "complexity" anyway, absent any other more fundamental goals?
>> I would much prefer, a la Jakob and Quentin, if you'd instead look at
>> exactly the limitations in FOAF and SKOS, and added extension
>> properties and/or classes where needed.
> Hi Bruce,
> MADS/RDF subclasses SKOS classes and properties.
> For an example of how MADS/RDF be reduced to useful SKOS data, here is
> a by-hand reduction of MADS/RDF to SKOS for the example document at
> . (Almost certainly contains some errors.)
> @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
> skos:prefLabel "Iron mines and mining--Accidents--Minnesota--History--20th century" ;
> skos:member <http://id.loc.gov/authorities/lcsh/collection_LCSH_General> ;
> skos:inScheme <http://id.loc.gov/authorities/lcsh> ;
> a skos:Concept .
> skos:prefLabel "Minnesota" ;
> a skos:Concept .
> skos:prefLabel "20th century" ;
> a skos:Concept .
> Now, I think there is probably some enhancements that could be made
> here in the subclassing of SKOS. For example, when reducing to SKOS we
> seem to lose the linkage between these related concepts; it would be
> nice if those were retained.
> Perhaps the SKOS-MADS/RDF connection could be made clearer. It would
> be helpful if SKOS-only variants of the MADS/RDF examples could be
> placed on the MADS/RDF web site.
> best, Erik
> 1. http://www.loc.gov/standards/mads/rdf/examples/sh2007010620.ttl
> Sent from my free software system <http://fsf.org/>.
tel: +44 (0)870 400 5000
fax: +44 (0)870 400 5001
mobile: +44 (0)7971 475 257