Dublin Core support? DC.creator, DC.date

I use Dublin Core metadata on my blog, embedded as meta elements. I noticed the following elements are not scraped properly:

* DC.creator (or DC.creator.name) is completely ignored
* DC.date (in WTN8601 format) is read, but misinterpreted
* DC.date.created is ignored.

A sample page: http://www.brainonfire.net/blog/force-ssl-for-wikipedia/
  • On my computer, it looks like DC.creator is being imported, but incorrectly (the first and last names aren't being broken apart). This is a bug.

    DC.date.created isn't supported because we currently support only unqualified DC. However, DC.created ought to work.
  • I just updated the WordPress plugin that generates these fields to use "McCormack, Tim" instead of "Tim McCormack", and creator.name instead of creator. I'll update it again to use both fields, but is one name format better?

    I'll add in DC.created for compatibility.
  • I have updated the plugin.

    * DC.creator is being read in properly now that I am using last-name-first format.
    * DC.date and DC.creator both result in a misinterpreted date. Can you recommend a known good date format? WTN8601 isn't working. [*]

    [*] "2010-05-22T22:54:14" is imported, but "y d" displays next to it and the interpreted value is "2010-00-05".
  • Hey Simon (or whoever else knows) could I get some advice on a date format to use?
  • The date parsing is good at any natural language date (and not good at computer dates). I think it'll work if you replace "T" with a space. You can test by entering such dates into teh date field of a Zotero item and seeing what shows up.
  • That seems pretty backwards -- shouldn't it parse well-known RFC formats? Anyway, that's a good tip about testing.
  • Feel free to submit a patch on zotero-dev. In the meantime, more Zotero users know how to type natural language dates than 8601 dates (and, as ajlyon said, it parses the SQL date format, without the T).
  • Ah, I think I see a point of miscommunication here. Are you saying that Zotero uses the exact same parser for both embedded metadata and the manual entry interface?
  • Yes. Or, rather, the Embedded RDF translator probably (I haven't checked) doesn't do parsing at all and just saves the field, and stored dates in Zotero are passed through Zotero.Date.strToDate() in chrome/content/zotero/xpcom/zotero.js.

    So either the Embedded RDF translator could be made to parse specific formats or strToDate() could be extended to handle 8601.
  • Not really following the details (and busy), but I tend to pay attention when I see "RDF" and "DC" in a thread. Obviously zotero should be able to input and output RDF/DC dates in standard machine-readable date formats. If it can't, that's a bug.

    That's all; sorry if this is noise.
  • The trunk now supports WTN8601.
  • Thanks to all. Come the next release, I won't have to choose between standards and Zotero. :-)
Sign In or Register to comment.