I was recently asked by someone at the Smithsonian how best to expose metadata to Zotero in their newly minted Solr powered catalog. Is the exposing_your metadata page comprehensive [2]? It seems to be lacking some details, particularly because it buries COinS support inside blogging software, and doesn't mention unAPI at all. I seem to remember there other standard ways folks can expose their metadata so zotero can grab it?
I would recommend you create a "For Publishers" tab in your menu right next to "For Developers" and detail all the standard mechanisms a publisher could use to expose their metadata to enable Zotero to recognize it. Or something like that :-)
Ed, I had the same feeling. The "exposing your metadata" page is currently used to list some applications that expose their metadata.
Speaking of: I don't understand why COinS is recommended. Instead of embedding a link to a metadata web service in your web page, why not just embed the metadata itself as RDF? Works great for feed discovery in blogs.
e...@pobox.com wrote: > I was recently asked by someone at the Smithsonian how best to expose > metadata to Zotero in their newly minted Solr powered catalog. Is the > exposing_your metadata page comprehensive [2]? It seems to be lacking > some details, particularly because it buries COinS support inside > blogging software, and doesn't mention unAPI at all. I seem to > remember there other standard ways folks can expose their metadata so > zotero can grab it?
> I would recommend you create a "For Publishers" tab in your menu right > next to "For Developers" and detail all the standard mechanisms a > publisher could use to expose their metadata to enable Zotero to > recognize it. Or something like that :-)
I really like this idea of a "For Publishers" section. We get frequent requests for the same kinds of information about how to tweak OPAC software, etc. to improve Zotero readability. A publishers' section would save us a lot of time spent responding to these questions, and the wiki model would allow for refinement and community contributions.
I also definitely agree that embedded RDF is the way to go. One current problem is that we don't yet have an embedded RDF model that preserves all of a Zotero item's data. It seems to me that we want something that allows for lossless roundtrips between import and export from Zotero as embedded RDF. The stumbling block right now is the degree to which such an embedded RDF draws on existing schema. We could more quickly move toward a more unilateral solution to replicate the entire Z model (e.g. just embed our current RDF export in web pages and support the detection and import of those embedded items), but there is also value in promoting a more "open" model which draws on existing formats.
> Ed, I had the same feeling. The "exposing your metadata" page is > currently used to list some applications that expose their metadata.
> Speaking of: I don't understand why COinS is recommended. Instead of > embedding a link to a metadata web service in your web page, why not > just embed the metadata itself as RDF? Works great for feed > discovery in > blogs.
> Cheers, > Sean
> e...@pobox.com wrote: >> I was recently asked by someone at the Smithsonian how best to expose >> metadata to Zotero in their newly minted Solr powered catalog. Is the >> exposing_your metadata page comprehensive [2]? It seems to be lacking >> some details, particularly because it buries COinS support inside >> blogging software, and doesn't mention unAPI at all. I seem to >> remember there other standard ways folks can expose their metadata so >> zotero can grab it?
>> I would recommend you create a "For Publishers" tab in your menu >> right >> next to "For Developers" and detail all the standard mechanisms a >> publisher could use to expose their metadata to enable Zotero to >> recognize it. Or something like that :-)
Sean Takats wrote: > I really like this idea of a "For Publishers" section. We get > frequent requests for the same kinds of information about how to > tweak OPAC software, etc. to improve Zotero readability. A > publishers' section would save us a lot of time spent responding to > these questions, and the wiki model would allow for refinement and > community contributions.
> I also definitely agree that embedded RDF is the way to go. One > current problem is that we don't yet have an embedded RDF model that > preserves all of a Zotero item's data. It seems to me that we want > something that allows for lossless roundtrips between import and > export from Zotero as embedded RDF. The stumbling block right now is > the degree to which such an embedded RDF draws on existing schema. > We could more quickly move toward a more unilateral solution to > replicate the entire Z model (e.g. just embed our current RDF export > in web pages and support the detection and import of those embedded > items), but there is also value in promoting a more "open" model > which draws on existing formats.
> Sean
> On Aug 7, 2007, at 10:15 AM, Sean Gillies wrote:
>> Ed, I had the same feeling. The "exposing your metadata" page is >> currently used to list some applications that expose their metadata.
>> Speaking of: I don't understand why COinS is recommended. Instead of >> embedding a link to a metadata web service in your web page, why not >> just embed the metadata itself as RDF? Works great for feed >> discovery in >> blogs.
>> Cheers, >> Sean
>> e...@pobox.com wrote: >>> I was recently asked by someone at the Smithsonian how best to expose >>> metadata to Zotero in their newly minted Solr powered catalog. Is the >>> exposing_your metadata page comprehensive [2]? It seems to be lacking >>> some details, particularly because it buries COinS support inside >>> blogging software, and doesn't mention unAPI at all. I seem to >>> remember there other standard ways folks can expose their metadata so >>> zotero can grab it?
>>> I would recommend you create a "For Publishers" tab in your menu >>> right >>> next to "For Developers" and detail all the standard mechanisms a >>> publisher could use to expose their metadata to enable Zotero to >>> recognize it. Or something like that :-)
> I also definitely agree that embedded RDF is the way to go. One > current problem is that we don't yet have an embedded RDF model that > preserves all of a Zotero item's data. It seems to me that we want > something that allows for lossless roundtrips between import and > export from Zotero as embedded RDF. The stumbling block right now is > the degree to which such an embedded RDF draws on existing schema. > We could more quickly move toward a more unilateral solution to > replicate the entire Z model (e.g. just embed our current RDF export > in web pages and support the detection and import of those embedded > items), but there is also value in promoting a more "open" model > which draws on existing formats.
We're closing in on a first draft of the biblio ontology which is intended to work for this.
No offense intended to RDF fans (I'm one to some degree), but...
What would be wrong with using simple, plain old meta tags in the head section of html? Meta tags have been around forever and are way easy to extract in a Zotero translator. Here is a really beautiful example from The New England Journal of Medicine (http://content.nejm.org/cgi/ content/short/357/8/753):
<meta name="citation_journal_title" content="The New England Journal of Medicine"> <meta name="citation_authors" content="Adams, Ted D.; Gress, Richard E.; Smith, Sherman C.; Halverson, R. Chad; Simper, Steven C.; Rosamond, Wayne D.; LaMonte, Michael J.; Stroup, Antoinette M.; Hunt, Steven C."> <meta name="citation_title" content="Long-Term Mortality after Gastric Bypass Surgery"> <meta name="citation_date" content="08/23/2007"> <meta name="citation_volume" content="357"> <meta name="citation_issue" content="8"> <meta name="citation_firstpage" content="753"> <meta name="citation_doi" content="10.1056/NEJMoa066603"> <meta name="citation_pdf_url" content="http://content.nejm.org/cgi/ reprint/357/8/753.pdf"> <meta name="citation_abstract_html_url" content="http:// content.nejm.org/cgi/content/abstract/357/8/753"> <meta name="citation_fulltext_html_url" content="http:// content.nejm.org/cgi/content/full/357/8/753"> <meta name="citation_pmid" content="17715409"> <meta name="dc.Contributor" content="Adams, Ted D."> <meta name="dc.Contributor" content="Gress, Richard E."> <meta name="dc.Contributor" content="Smith, Sherman C."> <meta name="dc.Contributor" content="Halverson, R. Chad"> <meta name="dc.Contributor" content="Simper, Steven C."> <meta name="dc.Contributor" content="Rosamond, Wayne D."> <meta name="dc.Contributor" content="LaMonte, Michael J."> <meta name="dc.Contributor" content="Stroup, Antoinette M."> <meta name="dc.Contributor" content="Hunt, Steven C."> <meta name="dc.Title" content="Long-Term Mortality after Gastric Bypass Surgery"> <meta name="dc.Identifier" content="10.1056/NEJMoa066603"> <meta name="dc.Date" content="08/23/2007"> <meta name="citation_publisher" content="Mass Med Soc">
On Aug 8, 6:40 am, Bruce D'Arcus <bdar...@gmail.com> wrote:
I understand the technical/intellectual interest and value in RDF ontologies.
However, don't overlook the "for publishers" part of the thread title. At the end of the day a publisher's electronic production department has to buy into the ontology you eventually develop. A bunch of large, corporate, well funded publishers may be able to pull off what you are proposing. Many more smaller, privately held (but just as important) publishers won't have the staff or budget to deliver embedded RDFa. Believe me, I've been working for these types of publishers for 15 years. Consider getting early feedback on the RDF ontology approach from a variety of publishers before you get too far.
Most any publishers can add meta tags to html today.
On Aug 23, 10:21 pm, Bruce D'Arcus <bdar...@gmail.com> wrote:
bill mckinney wrote: > I understand the technical/intellectual interest and value in RDF > ontologies.
It's thoroughly practical.
> However, don't overlook the "for publishers" part of the thread title. > At the end of the day a publisher's electronic production department > has to buy into the ontology you eventually develop. A bunch of large, > corporate, well funded publishers may be able to pull off what you are > proposing. Many more smaller, privately held (but just as important) > publishers won't have the staff or budget to deliver embedded RDFa. > Believe me, I've been working for these types of publishers for 15 > years. Consider getting early feedback on the RDF ontology approach > from a variety of publishers before you get too far.
Anyone is free to join the effort, and it is explicitly aimed at some practical balance of simplicity and expressiveness suitable for publishers and consumers.
Beyond that, I'm not going to go out of my way to contact publishers individually. I have no illusions that even if I did that every possible player in this space would standardize on any one approach.
> Most any publishers can add meta tags to html today.
Sure, so they should do that; better than nothing. The DCMI has just been working on updating their suggestions on embedding DC descriptions in HTML. That ought to be able to cover most of the baseline stuff.
|
