LISTSERV mailing list manager LISTSERV 16.0

Help for MODS Archives


MODS Archives

MODS Archives


MODS@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MODS Home

MODS Home

MODS  December 2010

MODS December 2010

Subject:

Re: MADS/RDF for review

From:

"Hickey,Thom" <[log in to unmask]>

Reply-To:

Metadata Object Description Schema List <[log in to unmask]>

Date:

Wed, 1 Dec 2010 10:36:47 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (237 lines)

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:

http://viaf.org/viaf/102333412/rdf.xml 

> ** 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.

Jeff

-----Original Message-----
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
supportive?

** 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,
mostly.

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
/data/.

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. :)

rob

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
> [1]. (Almost certainly contains some errors.)
>
>  @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
>
>  <http://id.loc.gov/authorities/lcsh/sh2007010620>
>      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 .
>
>  <http://id.loc.gov/authorities/lcsh/sh85000368>
>    skos:prefLabel "Minnesota" ;
>    a skos:Concept .
>
>  <http://id.loc.gov/authorities/lcsh/sh85061212>
>    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/>.
>
>



-- 
rob

Rob Styles
tel: +44 (0)870 400 5000
fax: +44 (0)870 400 5001
mobile: +44 (0)7971 475 257
irc: irc.freenode.net/mmmmmrob,isnick
web: http://www.talis.com/
blog: http://www.dynamicorange.com/blog/
blog: http://blogs.talis.com/nodalities/
blog: http://blogs.talis.com/n2/

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

January 2020
December 2019
October 2019
September 2019
August 2019
June 2019
May 2019
March 2019
February 2019
January 2019
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager