Re: [CODE4LIB] viaf
The ontology document shouldn't 404s, but either way I'm pretty sure that all the vocabulary terms defined there are obsolete (e.g. viaf:NameAuthorityCluster). The diagram referenced in the 2011-04 Outgoing blog post is still current: http://outgoing.typepad.com/.a/6a00d83459bf2269e20147e410996d970b-popup This document from the W3C LLD XG use case gathering phase may also provide some extra historical context from around that time: http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Virtual_International_Authority_File_%28VIAF%29 The SKOS-XL vocabulary was used early on, but was eventually factored out in favor of straight SKOS. The reference to xmlns:skos-xl is vestigial. Jeff From: Richard Wallis [mailto:richard.wal...@dataliberate.com] Sent: Monday, April 07, 2014 11:26 PM To: Code for Libraries Subject: Re: [CODE4LIB] viaf You are correct that in the xmlns namespace definitions in the xml http://viaf.org/viaf/231063554/rdf.xml references a namespace that is no longer used in the output. There is a single commented out reference to 'viaf:NameAuthorityCluster' in the output. This post covers the change that deprecated the use of this: http://outgoing.typepad.com/outgoing/2011/04/changes-to-viafs-rdf.html From the other xmlns definitions it can be seen that use is made of void, owl, foaf, skis-xl, skis, RDA ElementsGR2, FRBRentitiesRDA to describe VIAF resources. I'll pass this on to some of the team behind VIAF to see if they have further comment ~Richard. On 7 April 2014 23:04, Eric Lease Morgan emor...@nd.edumailto:emor...@nd.edu wrote: On Apr 7, 2014, at 10:52 PM, Richard Wallis richard.wal...@dataliberate.commailto:richard.wal...@dataliberate.com wrote: Is this what you are looking for: http://viaf.org/viaf/data/ Alas, no, not really. I'm looking for an RDF file listing the classes and properties used by VIAF. VIAF can return RDF for specific entities, as in curl: curl -L -H accept: application/rdf+xml http://viaf.org/viaf/231063554/ Upon what RDF schema is this output based? The header of the output alludes to the following URI, but it returns an error: http://viaf.org/ontology/1.1/#http://viaf.org/ontology/1.1/ - Eric Morgan -- Richard Wallis Founder, Data Liberate http://dataliberate.com Tel: +44 (0)7767 886 005 Linkedin: http://www.linkedin.com/in/richardwallis Skype: richard.wallis1 Twitter: @rjw
Re: [CODE4LIB] OpenURL linking but from the content provider's point of view
If the referent has a DOI, then I would argue that rft_id=http://dx.doi.org/10.1145/2132176.2132212 is all you need. The descriptive information that typically goes in the ContextObject can be obtained (if necessary) by content-negotiating for application/rdf+xml. OTOH, if someone pokes this same URI from a browser instead, you will generally get redirected to the publisher's web site with the full-text close at hand. The same principle should apply for any bibliographic resource that has a Linked Data identifier. Jeff -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Owen Stephens Sent: Wednesday, November 21, 2012 9:55 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OpenURL linking but from the content provider's point of view The only difference between COinS and a full OpenURL is the addition of a link resolver address. Most databases that provide OpenURL links directly (rather than simply COinS) use some profile information - usually set by the subscribing library, although some based on information supplied by an individual user. If set by the library this is then linked to specific users by IP or by login. There are a couple(?) of generic base URLs you can use which will try to redirect to an appropriate link resolver based on IP range of the requester, with fallback options if it can't find an appropriate resolver (I think this is how the WorldCat resolver works? The 'OpenURL Router' in the UK definitely works like this) The LibX toolbar allows users to set their link resolver address, and then translates COinS into OpenURLs when you view a page - all user driven, no need for the data publisher to do anything beyond COinS There is also the 'cookie pusher' solution which ArXiv uses - where the user can set a cookie containing the base URL, and this is picked up and used by ArXiV (http://arxiv.org/help/openurl) Owen PS it occurs to me that the other part of the question is 'what metadata should be included in the OpenURL to give it the best chance of working with a link resolver'? Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com Telephone: 0121 288 6936 On 20 Nov 2012, at 19:39, David Lawrence david.lawre...@sdsu.edu wrote: I have some experience with the library side of link resolver code. However, we want to implement OpenURL hooks on our open access literature database and I can not find where to begin. SafetyLit is a free service of San Diego State University in cooperation with the World Health Organization. We already provide embedded metadata in both COinS and unAPI formats to allow its capture by Mendeley, Papers, Zotero, etc. Over the past few months, I have emailed or talked with many people and read everything I can get my hands on about this but I'm clearly not finding the right people or information sources. Please help me to find references to examples of the code that is required on the literature database server that will enable library link resolvers to recognize the SafetyLit.org metadata and allow appropriate linking to full text. SafetyLit.org receives more than 65,000 unique (non-robot) visitors and the database responds to almost 500,000 search queries every week. The most frequently requested improvement is to add link resolver capacity. I hope that code4lib users will be able to help. Best regards, David David W. Lawrence, PhD, MPH, Director Center for Injury Prevention Policy and Practice San Diego State University, School of Public Health 6475 Alvarado Road, Suite 105 San Diego, CA 92120 usadavid.lawre...@sdsu.edu V 619 594 1994 F 619 594 1995 Skype: DWL-SDCAwww.CIPPP.org -- www.SafetyLit.org
Re: [CODE4LIB] OpenURL linking but from the content provider's point of view
If David is coining his own ContextObjects, he could add his own Linked Data rft_id in addition to or instead of the dx.doi.org URI. The rft_id key is repeatable. If he does coins his own Linked Data URI, though, I would recommend having his Linked Data URI assert owl:sameAs with the dx.doi.org URI in the RDF. OTOH, if he's merely consuming ContextObjects via his own OpenURL Resolver and wants to deliver the content locally, he treat the dx.doi.org URI as a mere identifier and direct the requester to the copy he is hosting instead. Jeff -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jason Stirnaman Sent: Wednesday, November 21, 2012 10:20 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OpenURL linking but from the content provider's point of view Sorry. I guess I misunderstood. I thought David meant resolving OpenURLs pointed at his content. Jason Jason Stirnaman Digital Projects Librarian A.R. Dykes Library University of Kansas Medical Center 913-588-7319 From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Young,Jeff (OR) [jyo...@oclc.org] Sent: Wednesday, November 21, 2012 9:08 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OpenURL linking but from the content provider's point of view If the referent has a DOI, then I would argue that rft_id=http://dx.doi.org/10.1145/2132176.2132212 is all you need. The descriptive information that typically goes in the ContextObject can be obtained (if necessary) by content-negotiating for application/rdf+xml. OTOH, if someone pokes this same URI from a browser instead, you will generally get redirected to the publisher's web site with the full-text close at hand. The same principle should apply for any bibliographic resource that has a Linked Data identifier. Jeff -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Owen Stephens Sent: Wednesday, November 21, 2012 9:55 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OpenURL linking but from the content provider's point of view The only difference between COinS and a full OpenURL is the addition of a link resolver address. Most databases that provide OpenURL links directly (rather than simply COinS) use some profile information - usually set by the subscribing library, although some based on information supplied by an individual user. If set by the library this is then linked to specific users by IP or by login. There are a couple(?) of generic base URLs you can use which will try to redirect to an appropriate link resolver based on IP range of the requester, with fallback options if it can't find an appropriate resolver (I think this is how the WorldCat resolver works? The 'OpenURL Router' in the UK definitely works like this) The LibX toolbar allows users to set their link resolver address, and then translates COinS into OpenURLs when you view a page - all user driven, no need for the data publisher to do anything beyond COinS There is also the 'cookie pusher' solution which ArXiv uses - where the user can set a cookie containing the base URL, and this is picked up and used by ArXiV (http://arxiv.org/help/openurl) Owen PS it occurs to me that the other part of the question is 'what metadata should be included in the OpenURL to give it the best chance of working with a link resolver'? Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com Telephone: 0121 288 6936 On 20 Nov 2012, at 19:39, David Lawrence david.lawre...@sdsu.edu wrote: I have some experience with the library side of link resolver code. However, we want to implement OpenURL hooks on our open access literature database and I can not find where to begin. SafetyLit is a free service of San Diego State University in cooperation with the World Health Organization. We already provide embedded metadata in both COinS and unAPI formats to allow its capture by Mendeley, Papers, Zotero, etc. Over the past few months, I have emailed or talked with many people and read everything I can get my hands on about this but I'm clearly not finding the right people or information sources. Please help me to find references to examples of the code that is required on the literature database server that will enable library link resolvers to recognize the SafetyLit.org metadata and allow appropriate linking to full text. SafetyLit.org receives more than 65,000 unique (non-robot) visitors and the database responds to almost 500,000 search queries every week. The most frequently requested improvement is to add link resolver capacity. I hope that code4lib users will be able to help. Best regards, David David W. Lawrence, PhD, MPH, Director
Re: [CODE4LIB] COinS
If the goal is to embed bibliographic metadata in HTML, I would suggest Schema.org instead of COinS. Jeff Jonathan Rochkind rochk...@jhu.edu wrote: It _IS_ an old unused metadata format that should be replaced by something else (among other reasons because it's actually illegal in HTML5), but I'm not sure there is a something else with the right balance of flexibility, simplicity, and actual adoption by consuming software. But COinS didn't have a whole lot of adoption by consuming software either. Can you say what you think the COinS you've been adding are useful for, what they are getting used for? And what sorts of 'citations' youw ere adding them for? For my own curiosity, and because it might help answer if there's another solution that would still meet those needs. But if you want to keep using COinS -- creating a COinS generator like OCLC's no longer existing one is a pretty easy thing to do, perhaps some code4libber reading this will be persuaded to find the time to create one for you and others. If you have a server that could host it, you could offer that. :) On 11/20/2012 4:47 PM, Bigwood, David wrote: I've used the COinS Generator at OCLC for years. Now it is gone. Any suggestions on how I can get an occasional COinS for use in our bibliography? Do any of the citation managers generate COinS? Or is this just an old unused metadata format that should be replaced by something else? Thanks, Dave Bigwood dbigw...@hou.usra.edu Lunar and Planetary Institute
Re: [CODE4LIB] COinS
Jonathan Rochkind wrote: What do you mean by suggest schema.org? I'm suggesting Schema.org as a cross-domain extensible vocabulary that that can be (but doesn't have to be) embedded in HTML (e.g. via Microdata http://www.w3.org/TR/microdata/ and/or RDFa http://www.w3.org/TR/rdfa-lite/ attribute annotations). That same Schema.org vocabulary also happens to be suitable for “raw” serialization as RDF/XML, Turtle, N-Triples, JSON-LD, etc. In terms of vocabulary, Schema.org is “extensible” via several mechanisms including mashups with other vocabularies or, ideally, direct integration into the Schema.org namespace such as we’ve seen with RNews http://blog.schema.org/2011/09/extended-schemaorg-news-support.html , JobPostings http://blog.schema.org/2011/11/schemaorg-support-for-job-postings.html , and GoodRelations http://blog.schema.org/2012/11/good-relations-and-schemaorg.html . This is a win/win scenario, but it requires communities to prove they can articulate a sensible set of extensions and deliver the information in that model. Within the “bibliographic” community, this is the mandate set for the http://www.w3.org/community/schemabibex/ group. If you are disappointed with OpenURL metadata formats, poor support for COinS, and disappointing probabilities for content resolution, here’s your chance for leveraging SEO for those purposes. However, the vocabulary suggested by schema.org does not have terms for the citation details in OpenURL COinS, including volume, issue, start page -- or even including both an article title and a containing journal title, I think. As part of the WorldCat.org Linked Data initiative, we prototyped some basic Schema.org extensions in the http://purl.org/library namespace. These serve as proof-of-concept for the more community-based Schema Bib Extension group. The current set of “library” extensions don’t include very many journal-oriented terms like volume, issue, start page, but that’s mainly because WorldCat.org doesn’t include very much article-level data, not that these aren’t within scope of the group’s extension efforts. And is there any useful consuming software that will use it? As mentioned above, the Schema.org vocabulary is fully-compatible with Linked Data/RDF, which means that Linked Data/RDF tools should be able to deal with it. I’m not familiar with any Microdata parsers, but RDFa parsers and “distiller” services are available such as http://www.w3.org/2012/pyRdfa/#distill_by_input and http://www.w3.org/2012/pyRdfa/#distribution. Jeff
Re: [CODE4LIB] Worldcat schema.org search API
Karen,
Your output looks like it comes from the old 2007 RDFa 1.0 parser:
http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fwww.worldcat.org%2Foclc%2F527725format=pretty-xmlwarnings=falseparser=laxspace-preserve=true
The new 2012 RDFa 1.1 parser does a better job:
http://www.w3.org/2012/pyRdfa/extract?uri=http%3A%2F%2Fwww.worldcat.org%2Foclc%2F527725format=xmlrdfagraph=outputvocab_expansion=falserdfa_lite=falseembedded_rdf=truespace_preserve=truevocab_cache=truevocab_cache_report=falsevocab_cache_refresh=false
Note the comment on the old interface page: http://www.w3.org/2007/08/pyRdfa/
Users are advised to migrate to RDFa 1.1 in general, including the RDFa
1.1 distiller.
RDFa 1.1 is still pretty new and getting more tools to support it will help.
Jeff
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Karen Coyle
Sent: Thursday, July 12, 2012 6:16 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Worldcat schema.org search API
Ross, it might not be yahoo, but that doesn't mean I know what it is.
The pyRDFa utility returns garbage for RDF/XML and TTL, but not for
JSON. It's only in the JSON output that I am getting any bibliographic
data. The other two send me back a bunch of links to css files. I guess
this is good news for folks who prefer JSON. Also, I see the OCLC
number
in the JSON, but not the URI, although the URI appears in the div with
the RDFa:
div itemid=http://www.worldcat.org/oclc/527725; itemscope=
itemtype=http://schema.org/Book;
resource=http://www.worldcat.org/oclc/527725;
typeof=http://schema.org/Book;a
href=http://www.worldcat.org/oclc/527725;http://www.worldcat.org/oclc
/527725/a
I must say I wonder a bit about those double but what do I know?
Anywhere, here's what I get from pyRDFa:
RDF/XML:
rdf:RDF_4:Book rdf:about=http://schema.org/Book/rdf:Description
rdf:about=http://www.worldcat.org/title/selection-of-early-
statistical-papers-of-j-neyman/oclc/527725xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/css/loginpop
up.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/html/masthea
d.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/css/alerts.c
ss/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/css/modals_j
query.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/html/layered
_divs.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/cssj/N245213502/bundles/
print-min.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/css/cr_print
.css/xhv:stylesheet
rdf:resource=http://static.weread.com/css/booksiread/relbookswidget.cs
s?0:5/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/css/itemform
at.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/cssj/N1807112156/bundles
/screen-min.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/html/record.
css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/html/yui/bui
ld/reset-fonts-grids/reset-fonts-grids.css/xhv:stylesheet
rdf:resource=http://static1.worldcat.org/wcpa/rel20120711/html/new_wco
rg.css//rdf:Description/rdf:RDF
JSON:
{
@context: {
library: http://purl.org/library/;,
oclc: http://www.worldcat.org/oclc/;,
skos: http://www.w3.org/2004/02/skos/core#;,
madsrdf: http://www.loc.gov/mads/rdf/v1#;,
schema: http://schema.org/;,
http://purl.org/library/placeOfPublication: {
@type: @id
},
http://schema.org/about: {
@type: @id
},
http://schema.org/publisher: {
@type: @id
},
http://schema.org/author: {
@type: @id
},
http://www.w3.org/2004/02/skos/core#inScheme: {
@type: @id
},
http://www.loc.gov/mads/rdf/v1#isIdentifiedByAuthority: {
@type: @id
}
},
@id: oclc:527725,
@type: schema:Book,
schema:inLanguage: {
@value: en,
@language: en
},
library:holdingsCount: {
@value: 285,
@language: en
},
schema:author: {
@id: http://viaf.org/viaf/24666861;,
@type: schema:Person,
madsrdf:isIdentifiedByAuthority:
http://id.loc.gov/authorities/names/n50066374;,
schema:name: {
@value: Neyman, Jerzy, 1894-1981.,
@language: en
}
},
schema:name: {
@value: A selection of early statistical papers of J. Neyman.,
@language: en
},
schema:datePublished: {
@value: 1967.,
@language: en
},
schema:numberOfPages: {
@value: 429,
@language: en
},
library:oclcnum: {
@value: 527725,
@language: en
},
schema:about: [
{
@type: skos:Concept,
madsrdf:isIdentifiedByAuthority:
http://id.loc.gov/authorities/subjects/sh85082133;,
schema:name: {
@value: Mathematical statistics.,
@language: en
}
},
{
@id: http://dewey.info/class/519/;,
@type: skos:Concept,
skos:inScheme: http://dewey.info/scheme/;
},
{
@type: skos:Concept,
schema:name: {
@value: Statistique mathématique.,
@language: en
}
},
{
@id:
[CODE4LIB] Planned changes to the VIAF RDF
Thom Hickey posted a blog entry about our plans to streamline the VIAF RDF. http://outgoing.typepad.com/outgoing/2011/04/changes-to-viafs-rdf.html I can elaborate on the listserv if anyone wants to discuss the changes. Jeff --- Jeffrey A. Young Software Architect OCLC Research, Mail Code 410 OCLC Online Computer Library Center, Inc. 6565 Kilgour Place Dublin, OH 43017-3395 www.oclc.org http://www.oclc.org Voice: 614-764-4342 Voice: 800-848-5878, ext. 4342 Fax: 614-718-7477 Email: jyo...@oclc.org mailto:jyo...@oclc.org
Re: [CODE4LIB] Planned changes to the VIAF RDF
Update: Somebody offline asked why the diagrams have links to external Swiss and German authority resources, but not LC. The reason is that LC doesn't currently publish their name authority file as linked data. When they do, the owl:sameAs links to their URIs can be added to VIAF. The only VIAF contributors we're aware of today that publish their own authority Linked Data are Deutsche Nationalbibliothek, National Library of Sweden, and the National Széchényi Library (Hungary). Jeff From: Young,Jeff (OR) Sent: Tuesday, April 12, 2011 10:21 AM Subject: Planned changes to the VIAF RDF Thom Hickey posted a blog entry about our plans to streamline the VIAF RDF. http://outgoing.typepad.com/outgoing/2011/04/changes-to-viafs-rdf.html I can elaborate on the listserv if anyone wants to discuss the changes. Jeff --- Jeffrey A. Young Software Architect OCLC Research, Mail Code 410 OCLC Online Computer Library Center, Inc. 6565 Kilgour Place Dublin, OH 43017-3395 www.oclc.org Voice: 614-764-4342 Voice: 800-848-5878, ext. 4342 Fax: 614-718-7477 Email: jyo...@oclc.org
Re: [CODE4LIB] Planned changes to the VIAF RDF
It would make perfect sense for LC to publish the LCNAF in their id.loc.gov domain. I think the foaf:focus pattern is important for name authorities, though, and would encourage them to coin two URIs instead of just one. For example: http://id.loc.gov/authorities/n50042127#concept a skos:Concept ; skos:inScheme http://id.loc.gov/authorities#nameAuthorityFooBar skos:prefLabel Bourbaki, Nicolas ; skos:altLabel Burbaki, N. foaf:focus http://id.loc.gov/authorities/n50042127#thing . http://id.loc.gov/authorities/n50042127#thing a owl:Thing . I wouldn't want to tell LC how to model the #thing resource, but I think it is important for them to at least coin a placeholder identifier for it so it doesn't get confused with the #concept. Jeff -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Jonathan Rochkind Sent: Tuesday, April 12, 2011 2:34 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Planned changes to the VIAF RDF I like that you said when rather than if, heh. Have you guys at VIAF made it clear to LC that you'd consider them publishing in linked data to be a complement to VIAF, rather than duplication? I think maybe some people think it'd be duplication, which I think is not true. -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Young,Jeff (OR) Sent: Tuesday, April 12, 2011 1:50 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Planned changes to the VIAF RDF Update: Somebody offline asked why the diagrams have links to external Swiss and German authority resources, but not LC. The reason is that LC doesn't currently publish their name authority file as linked data. When they do, the owl:sameAs links to their URIs can be added to VIAF. The only VIAF contributors we're aware of today that publish their own authority Linked Data are Deutsche Nationalbibliothek, National Library of Sweden, and the National Széchényi Library (Hungary). Jeff From: Young,Jeff (OR) Sent: Tuesday, April 12, 2011 10:21 AM Subject: Planned changes to the VIAF RDF Thom Hickey posted a blog entry about our plans to streamline the VIAF RDF. http://outgoing.typepad.com/outgoing/2011/04/changes-to-viafs-rdf.html I can elaborate on the listserv if anyone wants to discuss the changes. Jeff --- Jeffrey A. Young Software Architect OCLC Research, Mail Code 410 OCLC Online Computer Library Center, Inc. 6565 Kilgour Place Dublin, OH 43017-3395 www.oclc.org Voice: 614-764-4342 Voice: 800-848-5878, ext. 4342 Fax: 614-718-7477 Email: jyo...@oclc.org
[CODE4LIB] FW: VIAF linked data and non-Latin searching
Here is some information about pending updates to the VIAF Linked Data. I'm working on before/after diagrams to better explain the differences and will share them soon. Questions and comments are welcome. Jeff From: Hickey,Thom Sent: Monday, April 11, 2011 12:57 PM To: v...@listserv.log.gov Cc: Young,Jeff (OR) Subject: VIAF linked data and non-Latin searching Non-Latin searching: We believe we have resolved a reoccurring issue with non-Latin searching failing (it had to do with restarting VIAF in different environments). If anyone still has issues with this, please let us know. Linked Data: We have taken another look at the RDF generated for linked data. The attached files show a personal, corporate and geographic (there are few pure geographic records in VIAF as of yet, but a mixed record such as Missouri's may be identified as geographic) record rendered in RDF. We think the new records are both simpler and easier to understand and use. The biggest difference is that we have eliminated the viaf:NameAuthorityCluster that acted as a record hub. Formerly, this record hub was responsible for linking to the separately identified primary entity. In the new record structure, contributed authorities bypass this record hub and link directly to the primary entity themselves. The description of the primary entity appears first in the record inside an rdf:Description element followed by skos:Concept entries, one for each source file, each of which links back to the primary entity via foaf:focus. We have included some deprecated identifiers matching those used in previous RDF, which may help those processing it as linked data. For those simply parsing it as XML and pulling information out of it, we have switched to fully qualified URIs which should make that easier. We will probably phase the new RDF in over the next two months. This month we will generate both for those getting full dumps of VIAF, then next month switch both the online and offline versions to the new format. For those with suggestions about the new format, this would be an ideal time to let us know. If we stay with the schedule outlined above we have until mid to late May before the new formats are in production. --Th barbara.rdf Description: barbara.rdf www.rdf Description: www.rdf missouri.rdf Description: missouri.rdf
Re: [CODE4LIB] FW: VIAF linked data and non-Latin searching
Thanks Ed. Note that the URI without the trailing slash does a 303 (Linked Data) redirect to the URI with the slash. Doing a 301 back would create a redirect loop. VIAF uses the trailing slash URI to support the Linked Data Cool URIs pattern called 303 URIs forwarding to One Generic Document http://www.w3.org/TR/cooluris/#r303gendocument. Unfortunately, I didn't heed the warning documented in the alternative pattern called 303 URIs forwarding to Different Documents http://www.w3.org/TR/cooluris/#r303uri: When the RDF and HTML representations of the resource differ substantially, the previous setup should not be used. Unfortunately, the die is probably cast. The HTML negotiated from the current generic resource is destined to deliver a user-interface experience that has very little correlation with the RDF. I have an idea for a solution, but it will require some effort to implement. :-( Jeff -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Ed Summers Sent: Monday, April 11, 2011 3:25 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] FW: VIAF linked data and non-Latin searching Nice, Jeff. I really like the simplified VIAF RDF. In particular I like how you've modeled the deprecation of resources. Are you planning to use a 301, e.g. http://viaf.org/viaf/77390479/ - http://viaf.org/viaf/77390479 ? //Ed On Mon, Apr 11, 2011 at 3:18 PM, Young,Jeff (OR) jyo...@oclc.org wrote: Here is some information about pending updates to the VIAF Linked Data. I'm working on before/after diagrams to better explain the differences and will share them soon. Questions and comments are welcome. Jeff From: Hickey,Thom Sent: Monday, April 11, 2011 12:57 PM To: v...@listserv.log.gov Cc: Young,Jeff (OR) Subject: VIAF linked data and non-Latin searching Non-Latin searching: We believe we have resolved a reoccurring issue with non-Latin searching failing (it had to do with restarting VIAF in different environments). If anyone still has issues with this, please let us know. Linked Data: We have taken another look at the RDF generated for linked data. The attached files show a personal, corporate and geographic (there are few pure geographic records in VIAF as of yet, but a mixed record such as Missouri's may be identified as geographic) record rendered in RDF. We think the new records are both simpler and easier to understand and use. The biggest difference is that we have eliminated the viaf:NameAuthorityCluster that acted as a record hub. Formerly, this record hub was responsible for linking to the separately identified primary entity. In the new record structure, contributed authorities bypass this record hub and link directly to the primary entity themselves. The description of the primary entity appears first in the record inside an rdf:Description element followed by skos:Concept entries, one for each source file, each of which links back to the primary entity via foaf:focus. We have included some deprecated identifiers matching those used in previous RDF, which may help those processing it as linked data. For those simply parsing it as XML and pulling information out of it, we have switched to fully qualified URIs which should make that easier. We will probably phase the new RDF in over the next two months. This month we will generate both for those getting full dumps of VIAF, then next month switch both the online and offline versions to the new format. For those with suggestions about the new format, this would be an ideal time to let us know. If we stay with the schedule outlined above we have until mid to late May before the new formats are in production. --Th
Re: [CODE4LIB] universal citation index
Lars,
Just so we're clear, I'm arguing the citations should be separately
identifiable. Web service APIs and HTML mashups create barriers for
interoperability.
Even though libris.kb.se publishes Linked Data URIs, it's hard to guess
how they should choose to support multiple text/plain citation
representations:
Linked Data URI: http://libris.kb.se/resource/bib/5060570
Accept: application/rdf+xml
Web Document URI:
http://libris.kb.se/data/bib/5060570?format=application%2Frdf%2Bxml
Accept: text/html
Web Document URI: http://libris.kb.se/bib/5060570
Accept: text/plain
Web Document URI: ???
Jeff
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf
Of
Lars Aronsson
Sent: Tuesday, July 20, 2010 3:35 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] universal citation index
On 07/20/2010 08:40 PM, Young,Jeff (OR) wrote:
I tried to keep the examples abstract in my earlier message, but
probably to the point of obscurity. If you think these URIs or
something
like them would help, then convince someone at OCLC to implement
them:
http://www.worldcat.org/oclc/{oclc#}/citation-apa.txt (text/plain)
http://www.worldcat.org/oclc/{oclc#}/citation-chicago.txt
(text/plain)
The Swedish national library's online catalog already
provides a similar service. Say you want to cite Perl 5
for Dummies, http://libris.kb.se/bib/5608622
(First click English at the top of the page, if the
user interface isn't already intelligble.)
Just click CITE, and a list of citations appear, that
you can cut-and-paste. At the bottom is the Swedish
version of Wikipedia's cite book template, which
is quite popular.
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
Re: [CODE4LIB] universal citation index
Stuart,
Sorry, I didn't mean to discount citation representations along other
content-negotiable dimensions. It seems likely that BCP-47
http://tools.ietf.org/html/rfc5646 will eventually be upgraded to recognize
signwriting. If so, my URI pattern suggestion could be extended to support
language, script, etc. like so:
http://example.org/manifestation/1/citation-apa.{bcp-47}.txt
In FRBR, serials are recognized as a distinct class so I assume this URI
pattern could be applied to suit all:
http://example.org/serial/2/citation-apa.{bcp-47}.txt (text/plain)
Jeff
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
stuart yeates
Sent: Tuesday, July 20, 2010 4:14 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] universal citation index
Young,Jeff (OR) wrote:
http://example.org/manifestation/1/citation-apa.txt (text/plain)
The problem I have with the use of (text/plain) is that too many
platforms still assume / default to latin1 for text/plain. While this
appears to be reducing, with signwriting still coming through the
standards pipeline we're not out of the woods yet.
And yes, there are serials in signwriting.
cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/ New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/ Institutional Repository
Re: [CODE4LIB] universal citation index
I suspect this discussion happened on code4lib before the thread got
cross-posting to LLD XG where I first saw it.
There are undoubtedly a ton of diverse use cases, but that doesn't mean
APIs are the best solution. Here are some spitball possibilities for
not just manifestations and we need page numbers.
http://example.org/frbr:serial/2/citation-apa.{bcp-47}.txt
http://example.org/frbr:manifestation/1/citation-apa.{bcp-47}.txt?xyz:st
artPage=5xyz:endPage=6
I'm imagining an xyz ontology with startPage and endPage, but we can
surely create it if something doesn't already exist.
Jeff
-Original Message-
From: Tom Morris [mailto:tfmor...@gmail.com]
Sent: Tuesday, July 20, 2010 5:37 PM
To: Young,Jeff (OR)
Cc: Karen Coyle; Jodi Schneider; public-lld; Code for Libraries; Brian
Mingus
Subject: Re: universal citation index
On Tue, Jul 20, 2010 at 1:40 PM, Young,Jeff (OR) jyo...@oclc.org
wrote:
In terms of Linked Data, it should make sense to treat citations as
text/plain variant representations of a FRBR Manifestation.
As Karen mentioned, many types of citation need more information than
just the manifestation. You also need pages numbers, etc.
Tom
Re: [CODE4LIB] universal citation index
Just to bring things back to where (I think) we started. I think
people
are
talking about three separate things here:
* URIs for bibliographic works (which, as Karen pointed out, are
missing
some crucial bits of info like page numbers)
URIs for bibliographic works: I assume you mean works in the sense
of frbr:Group1 or possibly owl:Thing.
(As an aside, does code4lib ever talk about OWL?)
* Actual text representations of a citation in a variety of
thick-book-specified formats (e.g., ALA, MLA)
Consider the URI patterns I suggested.
* The cites/cited-by graph for everything everywhere.
If cites and cited-by are the only verbs you find acceptable, then
define them as owl:inverseOf properties in an ontology. Honestly, I will
help. Consider irw:isAbout and irw:isTopicOf as existing alternatives,
though. Linked Data RWOs and Web Documents presumably serve the same
purpose. Web standard solutions already exist for this part.
I understood the original post to be about the latter. E.g., if every
book,
chapter, section, and article actually had a DOI, then we could build
a
doi[1] references doi[2] graph and be done with it. Since everything
doesn't
have a DOI, the question is in two parts: (a) how do we
algorithmically
generate unique URIs in a way that guarantees preservation of the
identity
relationship,
You should believe that URIs are names. It is impossible to express
semantics adequately in a name. That's what HTTP GET and RDF are for.
and (b) how do we actually generate/store/query the
resulting
graph.
Use Linked Data.
Jeff
Jodi, is any of this correct?
On Tue, Jul 20, 2010 at 5:33 PM, Young,Jeff (OR) jyo...@oclc.org
wrote:
Stuart,
Sorry, I didn't mean to discount citation representations along
other
content-negotiable dimensions. It seems likely that BCP-47
http://tools.ietf.org/html/rfc5646 will eventually be upgraded to
recognize signwriting. If so, my URI pattern suggestion could be
extended to
support language, script, etc. like so:
http://example.org/manifestation/1/citation-apa.{bcp-47}.txt
In FRBR, serials are recognized as a distinct class so I assume this
URI
pattern could be applied to suit all:
http://example.org/serial/2/citation-apa.{bcp-47}.txt (text/plain)
Jeff
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
Behalf Of
stuart yeates
Sent: Tuesday, July 20, 2010 4:14 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] universal citation index
Young,Jeff (OR) wrote:
http://example.org/manifestation/1/citation-apa.txt (text/plain)
The problem I have with the use of (text/plain) is that too many
platforms still assume / default to latin1 for text/plain. While
this
appears to be reducing, with signwriting still coming through the
standards pipeline we're not out of the woods yet.
And yes, there are serials in signwriting.
cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/ New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/ Institutional Repository
--
Bill Dueber
Library Systems Programmer
University of Michigan Library
Re: [CODE4LIB] dc:identifier in Google XML
UOM presumably indicates some sort of identifier from the University of Michigan. UCSC is presumably University of California Santa Cruz. Try going to their library catalogs and see if the numbers that follow line up somehow. If the person who coined these identifiers understood Linked Data, we could click on them to figure it out without hassle. Jeff -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of David Kane Sent: Monday, July 19, 2010 12:55 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] dc:identifier in Google XML HI All, I am getting data from google books that I do not understand in the dc:identifier field. I understand ISBN: ISSN: LCCN: OCLC: but UOM:, and UCSC:? Can anyone help with what these two mean. Are they Universities? Here is a snippet of xml; dc:formatbook/dc:format dc:identifierr0xMMAAJ/dc:identifier dc:identifierUOM:39015035700759/dc:identifier dc:subjectMedical/dc:subject dc:titleAbstracts [of the] annual meeting/dc:title ... generated from this URL: http://www.google.com/books/feeds/volumes?q=Abstracts%20of%20the%20annual%20meeting Thanks, David. -- David Kane, MLIS. Systems Librarian Waterford Institute of Technology Ireland http://library.wit.ie/ T: ++353.51302838 M: ++353.876693212
Re: [CODE4LIB] Library Class Registration System
Mike, Google Docs might be worth a look. http://docs.google.com/support/bin/static.py?page=guide.csguide=20322t opic=20330 Jeff -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Bell, Mike (Libraries) Sent: Monday, July 12, 2010 4:17 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] Library Class Registration System One of my teams is considering building a system for handling library class signup. That is, for one-time classes such as How to Search Pubmed, not for enrollment in academic courses like BIO101. Before building it, we are looking around to see if there is already something out there that could do it for us (either open-source or commercial). Do you have any suggestions? Here are the key requirements: Super simple sign-up no accounts (email response, captcha). -or LDAP integration Student needs to be able to cancel enrollment in a class Reminders to students that they're scheduled for class Calendar of available classes available in multiple formats day/week/month/list (printable) Take Attendance Flexible Reporting on attendance Let instructors schedule classes Allow Instructor to easily see who's registered Instructor or Administrator can cancel a class Users can Search Browse available classes Thank you. ___ Mike Bell University of Rochester
Re: [CODE4LIB] audio/video citations in an OpenURL
The sap2-2004 Community Profile (http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecordmetadat aPrefix=oai_dcidentifier=info:ofi/pro:sap2-2004) only recognizes oai_dc and MARC21. The mods metadata format was registered to support the rtm-2007 profile (http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecordmetadat aPrefix=oai_dcidentifier=info:ofi/pro:rtm-2007). It's possible that a SAP2-2004 resolver *could* recognize the mods metadata format, but it would be non-standard behavior. Jeff -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Ross Singer Sent: Wednesday, January 07, 2009 12:01 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] audio/video citations in an OpenURL On Wed, Jan 7, 2009 at 11:33 AM, Jonathan Rochkind rochk...@jhu.edu wrote: Hmm, I could send a DC KEV OpenURL (ie info:ofi/fmt:kev:mtx:dc ; there is no format for an XML DC? Kind of odd), and use the type element. http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecordmetadata Pr efix=oai_dcidentifier=info:ofi/fmt:xml:xsd:oai_dc Other possibilities here would be: http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecordmetadata Pr efix=oai_dcidentifier=info:ofi/fmt:xml:xsd:MARC21 and http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=GetRecordmetadata Pr efix=oai_dcidentifier=info:ofi/fmt:xml:xsd:mods The latter is in trial use, but it would be odd for it not to be approved at some point in the not too distant future. -Ross.
Re: [CODE4LIB] next generation opac mailing list
In our effort to redefine the future, it is important that we all challenge our assumptions. We should cherish our heretics, right or wrong. My $.02 is that we don't need yet another system; we need to develop and adopt standards and coerce everyone in sight to play along. Standards enable innovation. Systems deter it. Jeff -Original Message- From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of Teresa Victoriana Sierra Sent: Tuesday, June 06, 2006 2:25 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] next generation opac mailing list I generally don't get into the discussion threads, but merely enjoy what is being said. However, Eric...you have touched a nerve. I agree that we need to be thinking about the way libraries will look in the future. But to say that the library catalog is serving only the purposes of the people who fund them and feed on their vanity, is pretty strong and misguided. Maybe you ought to sit with a reference librarian and ask why and how the catalog and OPAC are used. Teri Sierra, Chief Serial and Government Publications Division Library of Congress 202-707-5277 202-707-6128 (fax) [EMAIL PROTECTED] 06/05/06 8:50 PM I would argue that our energy would be better spent thinking about the next generation library rather than the next generation opac. Is it just me, or does anyone else feel that the very idea of having a catalog as an important component of a library smacks of retrograde thinking? To my mind, in a clean-slate NG Library architecture, the library catalog should only exist as a facade that recognizes of the vanity of libraries and the people who fund them. I can think of no technical justification for library catalogs as we look forward. If not the next generation, then the next-next generation of libraries. The functions that exist today in library catalogs need to be pushed in two directions- toward the user on one hand, and towards global registries on the other. the other Eric -- Eric Hellman, DirectorOCLC Openly Informatics Division [EMAIL PROTECTED]2 Broad St., Suite 208 tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 http://www.openly.com/1cate/ 1 Click Access To Everything
Re: [CODE4LIB] Authority records and the OSS ILS
Ed, Could you make a distributed solution work? We have a search service available at http://alcme.oclc.org/eprintsUK/index.html. (Currently, it only includes LC name authorities only.) Perhaps we could add COinS of some sort to allow you to link back into your system. Jeff On 5/25/06, Edward Corrado [EMAIL PROTECTED] wrote: Hello All, I have been asked to set up an Open Source ILS for someone who is teaching a cataloging class this summer. One of the things she was hoping to be able to do with it is have students work with MARC Authority records. I can't find any evidence that any of the currently available [1] Open ILS systems use MARC Authority records [2]. Does anyone know of one that does? Maybe I'm missing something. Ed C. [1] A 2002 article in Information Today (http://www.librarytechnology.org/ltg-displaytext.pl?RC=9975) mentions that the LearningAccess ILS uses MARC Authority records, but I went to there website and didn't see any evidence that this product was still an Open Source program (and also I didn't see no way to download it). I will probably contact them separately if I can't find another system to use. [2] It appears that Evergreen will use MARC Authority records, but the wiki says authority control in marc editor is still on the to-do list* *
