Update: see a more recent post about RDF in VIAF: http://outgoing.typepad.com/outgoing/2010/05/viafs-new-linked-data.html.
We announced Linked Data support for VIAF some time ago, but the actual RDF that we generated was fairly rudimentary FOAF. Since VIAF is expected to support more than just people (the vision includes corporations, families, geographics, titles, etc.), FOAF seemed fairly limiting, plus the match between FOAF's concepts and typical library authority files is not very good.The Library of Congress is bringing up LCSH as SKOS, and we have plans here at OCLC to do something similar for the FAST subject vocabulary, so SKOS is an attractive application of RDF for us to use. Unfortunately SKOS does not have the notion of a person, and lacks some nice RDF classes that FOAF has, such as the ability to specify birth and death dates, or to have a link to a person's publications.
My initial approach was to just bundle up a SKOS and FOAF description of our VIAF personas. Unfortunately I'm told that our RDF really shouldn't claim that our personas are two different rdf:type's. Andy Houghton here has been helping with this and says that this is not only a bad idea, but that it just doesn't make sense from an OWL/RDF perspective (Keep names separate applies here).
So maybe some of the FOAF properties can be used within SKOS? Yes, but none of the ones that imply you are describing a person (e.g. you can use foaf:name, but not foaf:publications). It all makes sense, or at least is consistent, but doesn't help me describe this concept-that-is-a-person. So where are we? Well, Andy can come up with ways of having multiple real-world-object resources which could be described separately as FOAF and SKOS and then linked, but that seems overly complicated to me. For right now we'll probably just put out a SKOS concept and people will have to go to the XML object to get more information if they need it. I'm interested in alternative approaches if anyone has ideas about it.
I can't say I'm happy with much of this. RDF seems so complicated that it will be very surprising to see it used consistently at all. I'm reminded of other technologies that needed to be widely deployed, but proved overly complicated, e.g. SGML, and the OSI 7-layer model for communications and ended either morphing into something simpler (SGML to XML) or just ignored (the use of TCP/IP for telecom).
Here's a link to Jane Austen's RDF: http://viaf.org/viaf/39373043.rdf. Do a 'view-source' on the page to see the XML/RDF.
--Th
"I can't say I'm happy with much of this. RDF seems so complicated that it will be very surprising to see it used consistently at all."
The issues you are grappling with have nothing to do with RDF per se; it's about fitting your local data into a global information space. This includes fitting incredibly idiosyncratic library data traditions into more general vocabularies. I really commend you for trying to do this, but think it's important to properly diagnose the problem.
Posted by: Bruce D'Arcus | December 10, 2009 at 12:48
I would recommend creating your own classes and properties that fit the semantics of authority records (as you understand them), and let others worry about how they will map them to FOAF or SKOS. (This is the approach Freebase and DBpedia have taken.) I don't think SKOS is such a great fit for authority records, and as you point out, neither is FOAF. People will tell you it's best practice to reuse vocabulary, and that's true, but when you have a data set as large and important (and idiosyncratic) as yours, I think it's better not to shove it into a poorly-fitting data model. The "use a SKOS concept and people will have to go to the XML object to get more information if they need it" approach is the worst of all worlds, because now you're forcing people to use two different toolsets and two different models (graphs and trees) to get at your data, when the whole point is to make your data easily consumable. Far better to either make all the data available as RDF using a VIAF-specific vocabulary, or just forget RDF and use Atom or something. (Or even better: do both.)
Posted by: Ryan Shaw | December 10, 2009 at 13:10
I agree with what Bruce said about RDF not being the problem. The problem lies in RDF forcing you to think about data modeling issues instead of just sweeping them under the carpet. Mark Pilgirm's comments http://www.xml.com/pub/a/2003/08/20/dive.html on Atom and RDF from 2003 still seem relevant today to me.
I guess I probably missed it on public-esw-thes or foaf-dev, but I'd be interested to see the discussion of why you can't use FOAF for people, and GeoNames Ontology for places, etc. Also I'm not sure I see how the "Keep Names Separate" applies to instance data. I also agree with your assessment that minting different URIs for the FOAF concept and SKOS concept, and linking them together seems overly complicated. I still don't see what's wrong with typing a resource as skos:Concept and foaf:Person honestly.
Thanks for blogging about this Thom. While I agree with Ryan's comments too I think that a good faith effort needs to be made to reuse vocabularies...and you are clearly doing that. I've heard Tom Baker and Antoine Isaac talk about starting up a semweb for libraries group either at the W3C or somewhere else. I definitely think having a telecon between people would help a lot in coordinating these things.
Posted by: Inkdroid | December 11, 2009 at 11:13
I share some skepticism about RDF. Although I'm sure you could model your stuff as RDF effectively; if it requires creating your own vocabularies that nobody else uses anyway, is it worth the trouble? Some will strenuously argue 'yes'. I'm not sure.
But the important thing is to make the data available in machine readable format, and with URIs for each concept/entity involved. If you can do this effectively in RDF, great. If your winding up spending so much time trying to figure out how to do it in RDF that you wonder if it's worth it, and put it up in some kind of XML (I can't think of anything but some kind of XML that will be practically useful for the consumer, if not RDF) -- I personally will still be satisfied, and I suspect most actual potential users of the data will be too, even if the RDF theorists/purists will complain.
Most of the promise of RDF (as opposed to some kind of XML, even custom XML schema) is, from my perspective, mostly just _promise_, not currently delivered. Now the benefit of the promise is great enough that, all things being equal, if it's just as easy to do it in RDF as something else, sure, do it in RDF, support the RDF experiment.
But, IMO, if it doing it in RDF is going to mean not doing it at all (or delaying it significantly) as you try to figure out how to do it -- just start out with non-RDF XML, the most important thing is making the data available in an easy to use format.
Posted by: Jonathan Rochkind | December 14, 2009 at 01:59
SKOS was developed for thesauri, not for authority data. It barely, if at all, works for LC subject authorities, and really should not be used for name authorities, IMO. We need to create SAOS - Simple Authority Organization System - or maybe even CAOS - Complex Authority Organization System. It would be interesting to work on this in conjunction with the FRAD model. I have a lot of questions about that model (such as the treatment of preferred names and identities as entities), and this might allow us to work through some issues about how the model might work in real systems.
Posted by: Karen Coyle | December 16, 2009 at 10:51