Integration with web applications and wiki syntax

[Louis-Philippe Huberdeau]

Hello,

I am a developer on the Tikiwiki project and we are currently looking
for ways to integrate with Zotero. This will likely happen sometimes
over the summer, once budgets are approved from sponsors and such. At
this time, I am searching for possibilities and what can be done and
what hooks are available. If modifications are required in Zotero, I
would like to know to which extent it would be possible to contribute
code back.

Before I begin, I will quickly introduce the use case.

<use case>
Researchers would collaborate on reports and articles through the
wiki. Once the content is fixed, they would switch to a different tool
(Word, OpenOffice.org, ...) for the final formatting. In the mean
time, they still need to keep track of their references. Zotero would
be used for this and they would share their library through
synchronization.
</use case>

Part of the integration has to do with exposing our data so it can be
referenced by Zotero. OpenURL COinS seems like a great option for us.

The other part is accepting reference drops in the text area. At this
time, HTML is provided for rich text and plain text in other areas.
The primary issue is that the semantics are lost when dropping plain
text in a text area. We would need a little more flexibility.

* To be able to capture the reference information in wiki syntax to
expose it back as OpenURL COinS
* To be able to request the rich text version under a specific
formatting (ie Harvard) in rich text (HTML works), to preserve
consistency on the website
* When copying back in OpenOffice.org, it would be nice if references
were converted from the OpenURL tags

As part of my research, I went through a possible list of solutions.
Loosely, those are the options I considered, and in most cases
discarded as I familiarized myself with the product.

1. Get the users to input some reference ID, query the Zotero API from
the backend. Obviously, I then realized that the server was solely
used for synchronization and that the API were client side.
2. From JavaScript, query the Zotero API on the client side. This
sounded easy and perfect as it required nearly no configuration.
Security policies prevent the pages from accessing the API. An
extension would be required.
3. Register a callback for Zotero to call when dropping a source.
Firefox extensions won't let you do that as I could find. However,
that lead me to adding a listener on a custom event, which seems
reasonable.

I would like to know if I missed critical information along the way
and if there are alternatives I have not considered.

Thank you for your time.

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To post to this group, send email to zoter...@googlegroups.com.
To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.

[Richard Karnesky]

> Part of the integration has to do with exposing our data so it can be
> referenced by Zotero. OpenURL COinS seems like a great option for us.

COinS is a reasonable starting point because it is standard and
embeddable. Note that context objects are limited & future support
for a richer standard (such as RDF) should probably stay on your map.

> * To be able to capture the reference information in wiki syntax to
> expose it back as OpenURL COinS
> * To be able to request the rich text version under a specific
> formatting (ie Harvard) in rich text (HTML works), to preserve
> consistency on the website

These are quite possible. For the former, look to the Wikpedia
Citation Templates [1] export translator for some inspiration. You
may even want to add support for WP citation templates to Tikiwiki, to
be able to benefit from tools other than Zotero. If you do want to
make a custom exporter, you might first look into the citation style
language [2]. The citation style would be easier to program and
maintain and still works with the zotero quick copy [3]. If you
really want rich text to be output into regular HTML forms, it may be
appropriate to make a zotero plugin [4] (because this is most often
not what is desired)

[1] https://www.zotero.org/trac/browser/extension/trunk/translators/Wikipedia%20Citation%20Templates.js
[2] http://www.zotero.org/support/dev/creating_citation_styles
[3] http://www.zotero.org/support/creating_bibliographies#quick_copy
[4] http://www.zotero.org/support/dev/sample_plugin

> * When copying back in OpenOffice.org, it would be nice if references
> were converted from the OpenURL tags

Given that the OO.o export is built within your software, it would
seem that you would need to build this capability in if you wanted
it. I don't see how the Zotero client would be of much help.

> 1. Get the users to input some reference ID, query the Zotero API from
> the backend. Obviously, I then realized that the server was solely
> used for synchronization and that the API were client side.

There is a server-side API as well. There is some unofficial
documentation already & official documentation is forthcoming.

> 3. Register a callback for Zotero to call when dropping a source.
> Firefox extensions won't let you do that as I could find. However,
> that lead me to adding a listener on a custom event, which seems
> reasonable.

What do you expect that call-back to do, precisely? It seems to me
that you could create either a CSL file or an export translator to
format a dropped reference properly.

--Rick

[Louis-Philippe Huberdeau]

> * To be able to capture the reference information in wiki syntax to
> expose it back as OpenURL COinS
> * To be able to request the rich text version under a specific
> formatting (ie Harvard) in rich text (HTML works), to preserve
> consistency on the website

These are quite possible.  For the former, look to the Wikpedia
Citation Templates [1] export translator for some inspiration.  You
may even want to add support for WP citation templates to Tikiwiki, to
be able to benefit from tools other than Zotero.  If you do want to
make a custom exporter, you might first look into the citation style
language [2].  The citation style would be easier to program and
maintain and still works with the zotero quick copy [3].  If you
really want rich text to be output into regular HTML forms, it may be
appropriate to make a zotero plugin [4] (because this is most often
not what is desired)

[1] https://www.zotero.org/trac/browser/extension/trunk/translators/Wikipedia%20Citation%20Templates.js
[2] http://www.zotero.org/support/dev/creating_citation_styles
[3] http://www.zotero.org/support/creating_bibliographies#quick_copy

[4] http://www.zotero.org/support/dev/sample_ Export translator seems to be the right concept.plugin

I did look into CSL, but I figured this is not really what I need. I don't want to create new citation formats, I want to output them differently.

In the ideal solution, we would keep both the semantics as attributes and the formatted version for display as the researchers expect them to be, whichever is their preference. We probably won't keep the HTML, but basic formatting is easy to convert back to wiki syntax.

 

> * When copying back in OpenOffice.org, it would be nice if references
> were converted from the OpenURL tags

Given that the OO.o export is built within your software, it would
seem that you would need to build this capability in if you wanted
it.  I don't see how the Zotero client would be of much help.

There is no automated export. I was just thinking of a situation where you copy a paragraph from some web page and paste it into OpenOffice.org, it would be nice that it preserved the references. I did not look whether this can be done from an OO.o plugin. It might be out of the scope, I'm looking at the whole solution at this time.

 

> 1. Get the users to input some reference ID, query the Zotero API from
> the backend. Obviously, I then realized that the server was solely
> used for synchronization and that the API were client side.

There is a server-side API as well.  There is some unofficial
documentation already & official documentation is forthcoming.

Could I have a link on those?

 

> 3. Register a callback for Zotero to call when dropping a source.
> Firefox extensions won't let you do that as I could find. However,
> that lead me to adding a listener on a custom event, which seems
> reasonable.

What do you expect that call-back to do, precisely?  It seems to me
that you could create either a CSL file or an export translator to
format a dropped reference properly.

I had not encountered export translators. It may just be what I need. I just looked at the MediaWiki one and it looks fine. I guess my question at this point is if Zotero has any mechanism to query the underlying document to figure out which export translator is appropriate to use.

Thank you for your reply.

--

LP

[Richard Karnesky]

> I did look into CSL, but I figured this is not really what I need. I don't
> want to create new citation formats, I want to output them differently.

But see, for example, the BibTeX CSL. CSL simply defines how to
format a bunch of bibliographic information. One possible way to
format it is to use wikitext. Most of the functionality of the
Wikipedia citation template export translator could probably be re-
done in CSL.

> There is no automated export. I was just thinking of a situation where you
> copy a paragraph from some web page and paste it into OpenOffice.org,

I don't think the systems that Zotero uses to store this data can
roundtrip to HTML in Word or Writer. So, this would most likely be a
larger task of makng better word processor plugins.

> > There is a server-side API as well.  There is some unofficial
> > documentation already & official documentation is forthcoming.
>
> Could I have a link on those?

http://groups.google.com/group/zotero-dev/browse_thread/thread/44abcdd1ac921593/965322f7f2bc6537

> I guess my question at this
> point is if Zotero has any mechanism to query the underlying document to
> figure out which export translator is appropriate to use.

Presently, you can define the quick copy function per doman/path.
This also lets you choose to use HTML or plain text.

--Rick

[Erik Hetzner]

At Tue, 18 May 2010 13:59:33 -0700 (PDT),

Richard Karnesky wrote:
>
> > Part of the integration has to do with exposing our data so it can
> > be referenced by Zotero. OpenURL COinS seems like a great option
> > for us.
>
> COinS is a reasonable starting point because it is standard and
> embeddable. Note that context objects are limited & future support
> for a richer standard (such as RDF) should probably stay on your
> map.
>

> […]

Hi -

Apologies in advance for thread hi-jacking.

Respectfully, I don’t think COinS is a good option. It is not a
standard or recommendation or internet draft, it is a very convoluted
way to embed metadata in HTML, and I don’t myself care about or use
OpenURL, so any time spent learning its idiosyncrasies is time wasted.

I am not happy with unAPI, either, though I like it much more than
COinS. It uses a custom, unAPI-specific mechanism which could easily
be replaced with links, plain old HTTP, and content negotiation. While
not particularly difficult to implement, it is harder than it could
be, and the time spent coding it is not easily reused for linked data
applications. It is, as far as I can tell, supported on the client
side only by Zotero.

If I visit “Make your site Zotero ready” [1], it is suggested that I
use one of the two above options. For a project I am working on, what
I would like to do is be able to leverage work done to support linked
data to also support Zotero. Some thoughts about this follow.

For instance, how could I let Zotero know how to get metadata for an
item using content negotiation or, alternately, a different URI? In a
linked data sense, if I have a URI A which represents a book (the
non-information resource), and A' which is the HTML describing the
book, how can I let Zotero know when a user is viewing A' that there
exists an alternative representation of A' that provides
machine-readable metadata about A?

For instance, I can imagine supplying, in the HTML <head>,

<link rel="alternate" type="application/rdf+xml" href="...">

to let Zotero know that an RDF representation of information contained
at A' was available at a given location.

On a page that represents search results, I can imagine using:

<div xmlns:dc="http://purl.org/dc/elements/1.1/"
about="/a_book">
<span property="dc:creator">John Doe</span>.
<a href="/a_book"><span property="dc:title">A book</span>.</a>
<a type="application/rdf+xml" href="/a_book"/>
</div>

A little complicated, true, combining RDFa with links to more
information, but it gives some metadata about a book and a link to the
full metadata about the book.

While I have in the past done extra work to support Zotero, by
implementing unAPI, I would prefer, going forward, to be able to save
development time by re-using linked data work for Zotero. I don’t
think this should be difficult, but I don’t see a way to do it in
Zotero as it currently stands. I am willing to work on translators to
support this, but I want to get some feedback from the community first
as to the best way forward with this.

Thanks for Zotero, and thanks for reading this!

best,
Erik Hetzner

1. http://www.zotero.org/support/make_your_site_zotero_ready

[Avram Lyon]

2010/5/18 Erik Hetzner <ehet...@gmail.com>:

> For instance, I can imagine supplying, in the HTML <head>,
>
>  <link rel="alternate" type="application/rdf+xml" href="...">
>
> to let Zotero know that an RDF representation of information contained
> at A' was available at a given location.

RDFa as a desired format has come up before as a desired format that
Zotero should support, and I certainly agree. Since OpenURL/COinS is
apparently not being developed, there is little hope for it fixing the
existing bugs (missing fields, lack of multiple author support).
Fortunately, RDFa could be implemented rather easily, and it would
obviate the need for unAPI.

If you're looking at overhauling the embedded metadata detection in
Zotero, then taking the DOI, Embedded RDF, COinS, and unAPI
translators, adding a new RDFa translator, and tying them together in
a single translator that does all 5 in a single pass (calling the
extant translators) is something that I've wanted to do for some time.
While I'm not a Zotero team member, I believe that such a project
would be looked upon kindly; it hasn't been done only for lack of
developer time.

Avram

[Bruce D'Arcus]

On Wed, May 19, 2010 at 1:10 PM, Avram Lyon <ajl...@gmail.com> wrote:
> 2010/5/18 Erik Hetzner <ehet...@gmail.com>:
>> For instance, I can imagine supplying, in the HTML <head>,
>>
>>  <link rel="alternate" type="application/rdf+xml" href="...">
>>
>> to let Zotero know that an RDF representation of information contained
>> at A' was available at a given location.
>
> RDFa as a desired format has come up before as a desired format that
> Zotero should support, and I certainly agree. Since OpenURL/COinS is
> apparently not being developed, there is little hope for it fixing the
> existing bugs (missing fields, lack of multiple author support).
> Fortunately, RDFa could be implemented rather easily, and it would
> obviate the need for unAPI.
>
> If you're looking at overhauling the embedded metadata detection in
> Zotero, then taking the DOI, Embedded RDF, COinS, and unAPI
> translators, adding a new RDFa translator, and tying them together in
> a single translator that does all 5 in a single pass (calling the
> extant translators) is something that I've wanted to do for some time.
> While I'm not a Zotero team member, I believe that such a project
> would be looked upon kindly; it hasn't been done only for lack of
> developer time.

+1 on the RDFa. I'd be happy to look into adding RDFa examples to this
page if there's interest:

<http://bibliontology.com/examples>

And RDFa support could also be added to what zotero.org presents.

Aside: the python version of the CSL code I've been slowly and
periodically working on uses BIBO RDFa as its internal model, and so
it's preferred HTML output mode. An (imperfect) example from a
bibliography list:

<li property="dc:references">
<span property="dc:creator" typeOf="foaf:Person">
<span content="Jane" property="foaf:givenname">J.</span>
<span property="foaf:surname">Doe</span>
</span>
<span property="dc:creator" typeOf="foaf:Person">
<span content="John" property="foaf:givenname">J.</span>
<span property="foaf:surname">Smith</span>
</span>
<span property="dc:title">Some title</span>
<span prefix=", " property="bibo:volume">12</span>
<!-- the below prefix funkiness if for debugging -->
<span prefix=" else-if 2 WORKS " property="bibo:isbn">34239845</span>
</li>

Among other things, I'd ideally like more links in the data.

Bruce

[Louis-Philippe Huberdeau]

Thank you for high-jacking, I am certain it will lead to better results.

I was not aware of the limitations of COinS. As far as I was concerned, it was a really simple format. A simple URL-encoded string in an attribute containing a list of properties. There is some encoding required to fit it in an HTML tag, but not more than a normal link href. The PHP implementation did look about 10 times more complicated than it really has to be.

I had not looked much in depth towards unAPI. The description was longer and did not really explain what it was for. Reading the website and the specification did not help either.

I find embedding the content in the page itself to be much more practical. I have never been a big fan of RDF. RDFa is a step forward, but remains very complex. I feel more comfortable with microformats. They work very well because they are easy to generate for developers like me, and machine-readable enough to convey they information they need for software that needs to read them, like Zotero. At this time, I don't see anything for bibliographical references, but I think there would be interest.

--

LP

[Bruce D'Arcus]

On Wed, May 19, 2010 at 4:20 PM, Louis-Philippe Huberdeau
<louis-p...@huberdeau.info> wrote:

> I find embedding the content in the page itself to be much more practical. I
> have never been a big fan of RDF. RDFa is a step forward, but remains very
> complex. I feel more comfortable with microformats. They work very well
> because they are easy to generate for developers like me, and
> machine-readable enough to convey they information they need for software
> that needs to read them, like Zotero. At this time, I don't see anything for
> bibliographical references, but I think there would be interest.

The question is how much complexity is appropriate to the task? I
personally think it's more than most developer assume on first glance.

Citation data is hard. Just do a search for all the microformat list
posts on hCite, which has largely failed because this stuff is harder
that it seems at first glance. The advantage of using RDFa is the
basic model, syntax and corresponding parsing tools are all set, and
BIBO provides the domain-specific stuff (which Zotero has participated
in developing, BTW).

[Louis-Philippe Huberdeau]

You are absolutely right. It depends on the task you want to accomplish. My goal is in to way to do bibliography management. This is why I see external descriptors and RDF as such an unsuitable tool. Perhaps I expressed myself not so clearly. You will have to excuse me, I'm not too clear about it either at this time.

I work on a content management system used for collaboration. The big question is how can we make it as simple as possible to bring the experience found in word processing to the web. A final document might be spread across multiple pages in the CMS. Reviewers will need quick access to the source. Because Zotero will sync the library of everyone involved, they have it. If I can put just enough markup in the page for Zotero to identify that as a citation and bring up the source information, it would be great. The goal is not so much to provide complete citations for Zotero to consume as those Amazon would produce, but more like providing enough information for Zotero to find it in its own library.

Now, what is the minimum amount of information? Hard to tell. It's not like there was a unique identifier or anything. Author, year and a few keywords from the title should be a good start for scientific articles. I don't know the complete extent of the complexity of citations.

This is where I would see hCIte as useful (thank you for the reference, I could not find it).

I just looked at the exact HTML written by Zotero as it drops in a rich text area. It does contain the COinS data. It could as well add a few classes and be hCite too.

--

LP

[Erik Hetzner]

At Wed, 19 May 2010 10:10:57 -0700,

Avram Lyon wrote:
>
> 2010/5/18 Erik Hetzner <ehet...@gmail.com>:
> > For instance, I can imagine supplying, in the HTML <head>,
> >
> >  <link rel="alternate" type="application/rdf+xml" href="...">
> >
> > to let Zotero know that an RDF representation of information contained
> > at A' was available at a given location.
>
> RDFa as a desired format has come up before as a desired format that
> Zotero should support, and I certainly agree. Since OpenURL/COinS is
> apparently not being developed, there is little hope for it fixing
> the existing bugs (missing fields, lack of multiple author support).
> Fortunately, RDFa could be implemented rather easily, and it would
> obviate the need for unAPI.
>
> If you're looking at overhauling the embedded metadata detection in
> Zotero, then taking the DOI, Embedded RDF, COinS, and unAPI
> translators, adding a new RDFa translator, and tying them together
> in a single translator that does all 5 in a single pass (calling the
> extant translators) is something that I've wanted to do for some
> time. While I'm not a Zotero team member, I believe that such a
> project would be looked upon kindly; it hasn't been done only for
> lack of developer time.

I am not sure if I am looking at an overhaul. I would like to have the
following extractors for Zotero:

1. An easy way to link to machine-readable metadata in a form that
Zotero understands, (e.g., MARC or MODS), for instance with a <link>
element.

2. An extractor for RDFa, probably using bibo ontology.

I believe that (1) would be simpler to implement than unAPI, and more
in tune with linked data, and (2) is a good way forward for embedded
data in HTML, again in tune with linked data.

Thanks for all the responses. I am sorry that these have not been
implemented previously, but as it sounds like there is interest, I
will begin looking at implementation.

best,
Erik

[Erik Hetzner]

At Wed, 19 May 2010 13:39:42 -0400,

Bruce D'Arcus wrote:
>
> +1 on the RDFa. I'd be happy to look into adding RDFa examples to this
> page if there's interest:
>
> <http://bibliontology.com/examples>
>
> And RDFa support could also be added to what zotero.org presents.
>
> Aside: the python version of the CSL code I've been slowly and
> periodically working on uses BIBO RDFa as its internal model, and so
> it's preferred HTML output mode. An (imperfect) example from a
> bibliography list:
>
> <li property="dc:references">
> <span property="dc:creator" typeOf="foaf:Person">
> <span content="Jane" property="foaf:givenname">J.</span>
> <span property="foaf:surname">Doe</span>
> </span>
> <span property="dc:creator" typeOf="foaf:Person">
> <span content="John" property="foaf:givenname">J.</span>
> <span property="foaf:surname">Smith</span>
> </span>
> <span property="dc:title">Some title</span>
> <span prefix=", " property="bibo:volume">12</span>
> <!-- the below prefix funkiness if for debugging -->
> <span prefix=" else-if 2 WORKS " property="bibo:isbn">34239845</span>
> </li>
>
> Among other things, I'd ideally like more links in the data.

Hi -

This makes me realize that it would be great if Zotero could output
HTML with embedded RDFa that could be imported back into Zotero.

I will look at using the python csl HTML output as initial input for
an RDFa Zotero translator.

best, Erik

[Erik Hetzner]

At Wed, 19 May 2010 16:20:14 -0400,

Louis-Philippe Huberdeau wrote:
>
> Thank you for high-jacking, I am certain it will lead to better results.
>
> I was not aware of the limitations of COinS. As far as I was concerned, it
> was a really simple format. A simple URL-encoded string in an attribute
> containing a list of properties. There is some encoding required to fit it
> in an HTML tag, but not more than a normal link href. The PHP implementation
> did look about 10 times more complicated than it really has to be.
>
> I had not looked much in depth towards unAPI. The description was longer and
> did not really explain what it was for. Reading the website and the
> specification did not help either.
>
> I find embedding the content in the page itself to be much more practical. I
> have never been a big fan of RDF. RDFa is a step forward, but remains very
> complex. I feel more comfortable with microformats. They work very well
> because they are easy to generate for developers like me, and
> machine-readable enough to convey they information they need for software
> that needs to read them, like Zotero. At this time, I don't see anything for
> bibliographical references, but I think there would be interest.

Hi -

I don’t want to encourage or discourage anybody else from using COinS
or unAPI, if it works for you. I myself think there is a better way,
and would like to make that possible, but I am very happy that Zotero
does not demand that web pages conform to it, but is willing to
conform to web pages in order to extract the metadata it requires.

(As an aside, you might find that unAPI is only a little more work
than COinS, but that being able to generate richer metadata than COinS
makes your job easier in the long term.)

My concern is that a user interested in supporting linked data &
Zotero is not able to repurpose code used to support the former to
help support the latter, and vice versa.

best, Erik

[Frank Bennett]

On May 20, 2:39 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
> On Wed, May 19, 2010 at 1:10 PM, Avram Lyon <ajl...@gmail.com> wrote:

> > 2010/5/18 Erik Hetzner <ehetz...@gmail.com>:

In RDFa output, how do you handle names truncated by et al., and
fields contained in the Zotero/BIBO record that are not included in
the formatted bibliography reference (in the current style)?

[Bruce D'Arcus]

On Thu, May 20, 2010 at 4:04 AM, Frank Bennett <bierc...@gmail.com> wrote:

....

> In RDFa output, how do you handle names truncated by et al., and
> fields contained in the Zotero/BIBO record that are not included in
> the formatted bibliography reference (in the current style)?

On the former, you could use hidden metadata (it's been awhile since
I've looked at this, but I believe it's the "meta" element?). On the
latter, I wouldn't attempt to include anything that wasn't defined in
the style. This relates to a broader point, which is that considering
where we are now in terms of the state of the internet generally, and
Zotero.org in particular, we really need to get away from thinking
about integrated bibliographic records, and more about shared data.

[Frank Bennett]

On May 20, 11:00 pm, "Bruce D'Arcus" <bdar...@gmail.com> wrote:

> On Thu, May 20, 2010 at 4:04 AM, Frank Bennett <biercena...@gmail.com> wrote:
>
> ....
>
> > In RDFa output, how do you handle names truncated by et al., and
> > fields contained in the Zotero/BIBO record that are not included in
> > the formatted bibliography reference (in the current style)?
>
> On the former, you could use hidden metadata (it's been awhile since
> I've looked at this, but I believe it's the "meta" element?). On the
> latter, I wouldn't attempt to include anything that wasn't defined in
> the style. This relates to a broader point, which is that considering
> where we are now in terms of the state of the internet generally, and
> Zotero.org in particular, we really need to get away from thinking
> about integrated bibliographic records, and more about shared data.

So, trying to get my head around how this would work .... if one user
publishes a page containing a bib entry for a book, rendered via CSL
in a style that doesn't give the publisher place for books, and then
another user views the page and scrapes the entry, is the publisher
place lost in the second user's data? Or is it recovered by linking
through to a record elsewhere on the net?

[Erik Hetzner]

At Thu, 20 May 2010 13:27:00 -0700 (PDT),

Frank Bennett wrote:
>
> On May 20, 11:00 pm, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
> > On Thu, May 20, 2010 at 4:04 AM, Frank Bennett <biercena...@gmail.com> wrote:
> >
> > ....
> >
> > > In RDFa output, how do you handle names truncated by et al., and
> > > fields contained in the Zotero/BIBO record that are not included in
> > > the formatted bibliography reference (in the current style)?
> >
> > On the former, you could use hidden metadata (it's been awhile since
> > I've looked at this, but I believe it's the "meta" element?). On the
> > latter, I wouldn't attempt to include anything that wasn't defined in
> > the style. This relates to a broader point, which is that considering
> > where we are now in terms of the state of the internet generally, and
> > Zotero.org in particular, we really need to get away from thinking
> > about integrated bibliographic records, and more about shared data.
>
> So, trying to get my head around how this would work .... if one user
> publishes a page containing a bib entry for a book, rendered via CSL
> in a style that doesn't give the publisher place for books, and then
> another user views the page and scrapes the entry, is the publisher
> place lost in the second user's data? Or is it recovered by linking
> through to a record elsewhere on the net?

Unless I am mistaken, you could output:

<span property="address:localityName" content="Oakland, CA"/>

But there is no requirement that RDFa embed all triples, so you could
simply link to a fuller representation and exclude the place. I do not
know which solution is best.

best, Erik

[Bruce D'Arcus]

Yeah, there are ways to solve this requirement. I guess I just
question whether it's an important required to address?

[Frank Bennett]

On May 21, 5:54 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:

This may be relevant to this discussion? (If not, sorry for the extra
traffic.)

Frank


---------- Forwarded message ----------
From: Thomas Baker <tba...@tbaker.de>
Date: Thu, May 20, 2010 at 2:03 PM
Subject: DCMI's Vocabulary Management Tool published as an Open Source
project
To: DC-ARCH...@jiscmail.ac.uk


Documentation for DCMI Metadata Terms is currently published
as a Web document [1] and as an RDF schema [2] to which term
URIs, such as http://purl.org/dc/terms/title, are redirected.

The Vocabulary Management Tool which is used to generate
these documents has now been published as an open source
project on the Web-based hosting service Github [3].

DCMI would like to modify the system to generate the
user-oriented Web document [1] with an embedded RDF
representation using a W3C standard, RDFa [4].

Interested members of the open-source community are invited
to adapt the tool for their vocabularies, help improve the
code on Github, or discuss related issues on the mailing list
of the DCMI Architecture Forum [5].

[1] http://dublincore.org/documents/dcmi-terms/
[2] http://dublincore.org/2008/01/14/dcterms.rdf
[3] http://github.com/dublincore/website
[4] http://rdfa.info/
[5] http://www.jiscmail.ac.uk/lists/dc-architecture.html

[Frank Bennett]

On May 20, 2:39 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
> On Wed, May 19, 2010 at 1:10 PM, Avram Lyon <ajl...@gmail.com> wrote:

> > 2010/5/18 Erik Hetzner <ehetz...@gmail.com>:

> >> For instance, I can imagine supplying, in the HTML <head>,
>
> >>  <link rel="alternate" type="application/rdf+xml" href="...">
>
> >> to let Zotero know that an RDF representation of information contained
> >> at A' was available at a given location.
>
> > RDFa as a desired format has come up before as a desired format that
> > Zotero should support, and I certainly agree. Since OpenURL/COinS is
> > apparently not being developed, there is little hope for it fixing the
> > existing bugs (missing fields, lack of multiple author support).
> > Fortunately, RDFa could be implemented rather easily, and it would
> > obviate the need for unAPI.
>
> > If you're looking at overhauling the embedded metadata detection in
> > Zotero, then taking the DOI, Embedded RDF, COinS, and unAPI
> > translators, adding a new RDFa translator, and tying them together in
> > a single translator that does all 5 in a single pass (calling the
> > extant translators) is something that I've wanted to do for some time.
> > While I'm not a Zotero team member, I believe that such a project
> > would be looked upon kindly; it hasn't been done only for lack of
> > developer time.
>
> +1 on the RDFa. I'd be happy to look into adding RDFa examples to this
> page if there's interest:
>
> <http://bibliontology.com/examples>

This would be very helpful. I'll need examples in order to begin
working on RDFa support in the citeproc-js processor.

Frank

[Erik Hetzner]

At Wed, 26 May 2010 02:36:09 -0700 (PDT),

Frank Bennett wrote:
>
> On May 20, 2:39 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
> > +1 on the RDFa. I'd be happy to look into adding RDFa examples to this
> > page if there's interest:
> >
> > <http://bibliontology.com/examples>
>
> This would be very helpful. I'll need examples in order to begin
> working on RDFa support in the citeproc-js processor.

Yes, please do put RDFa examples on the bibliontology page. It will
make it much easier to get a Zotero translator up & running. Thanks.

best, Erik

[Bruce D'Arcus]

I forwarded this to the BIBO list.

FWIW, Frank, you can take a look at my get_property function to get a
sense of how I'm tackling this:

<http://github.com/bdarcus/citeproc-py/blob/master/citeproc.py>

I use a hash/dict to map CSL variable names to the equivalent RDF/BIBO
structures.

Bruce

[Frank Bennett]

On May 27, 3:03 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:

Thanks. The function gives mappings for a dozen variables. If it can
be filled out for the 50 or so remaining, that would be great.

>
> Bruce

[Bruce D'Arcus]

On my TODO.

On May 26, 2010 4:49 PM, "Frank Bennett" <bierc...@gmail.com> wrote:

On May 27, 3:03 am, "Bruce D'Arcus" <bdar...@gmail.com> wrote:

> On Wed, May 26, 2010 at 10:42 AM, Erik Hetzner <ehetz...@gmail.com> wrote:

> > At Wed, 26 May 2010...

Thanks.  The function gives mappings for a dozen variables.  If it can
be filled out for the 50 or so remaining, that would be great.

>
> Bruce

--
You received this message because you are subscribed to the Google Groups "zotero-d...

[Bruce D'Arcus]

Just saw on twitter that newsweek is now serving up HTML 5 with
embedded RDFa; example:

<article class="article-text">
<header>

<h1 property="dc:title">BP's Photo Blockade of the Gulf
Oil Spill</h1>

<h2 class="subhead"
property="dc:description">Photographers say BP and government
officials are preventing them from documenting the impact of the
Deepwater Horizon disaster.</h2>

</header>

Raises the point that RDFa support in Zotero would want to be flexible
about what sorts of properties and such they'd want to understand
(Newsweek isn't using BIBO; just DC, FOAF, SIOC).

Bruce

[Erik Hetzner]

Hi all,

Last night I put together the beginnings of an RDFa translator for
Zotero, using the RDFa implementation in JS available at [1].

This morning I noticed that Zotero has it’s own RDF store, Zotero.RDF.
If I can modify the RDFa parser to parse into this, it seems I could
use existing RDF translators to parse the RDF graph into Zotero items.

However, so far I have been unable to access Zotero.RDF. I believe
this may be because I am on a page that is not RDF/XML. Here is the
error:

Zotero(2): Translate: Translation using RDFa failed:
message => Zotero.RDF is undefined

and attached is a minimal translator. Any thoughts? Thanks!

best, Erik

1. http://www.w3.org/2006/07/SWD/RDFa/impl/js/

[Dan Stillman]

On 6/10/10 11:27 AM, Erik Hetzner wrote:
> However, so far I have been unable to access Zotero.RDF. I believe
> this may be because I am on a page that is not RDF/XML.

Just guessing, but try adding Zotero.configure("dataMode", "rdf"); to
the translator. That appears to add Zotero.RDF to the sandbox (in
translate.js).

[Dan Stillman]

Oh, sorry, you have that already. Don't know, then.

[Bruce D'Arcus]

I don't know if this has any relevance, but the W3C has just published
a draft of an RDFa DOM API document:

<http://www.w3.org/TR/2010/WD-rdfa-api-20100608/>

Bruce

[Erik Hetzner]

At Thu, 10 Jun 2010 12:05:47 -0400,

Thanks for the link. It does not appear to have any implementations
yet. If/when it is implemented we could probably use it.

However it did lead me to an alternate RDFa javascript parser which
may be better than the one I was using. [1]. We’ll see.

best, Erik

1. http://code.google.com/p/backplanejs/

[skornblith]

You can't use Zotero.RDF directly from a web translator. You have to
load an RDF import translator and call the functions there, i.e.,

var translator = Zotero.loadTranslator("import");
translator.setTranslator("14763d25-8ba0-45df-8f52-b8d1108e7ac9");
var rdf = translator.getTranslatorObject();
rdf.Zotero.RDF.addStatement('x','y','z');
rdf.doImport();

(see the Embedded RDF translator, which does precisely this)

Unfortunately, at the moment, this also means that you would have to
load the data into the data store twice if you wanted to try the
Bibliontology RDF translator first and then fall back to the older
Dublin Core/Zotero RDF import translator. I'll work on a better way of
handling this for 2.1.

Simon

[Erik Hetzner]

At Thu, 10 Jun 2010 09:31:05 -0700 (PDT),

skornblith wrote:
> You can't use Zotero.RDF directly from a web translator. You have to
> load an RDF import translator and call the functions there, i.e.,
>
> var translator = Zotero.loadTranslator("import");
> translator.setTranslator("14763d25-8ba0-45df-8f52-b8d1108e7ac9");
> var rdf = translator.getTranslatorObject();
> rdf.Zotero.RDF.addStatement('x','y','z');
> rdf.doImport();
>
> (see the Embedded RDF translator, which does precisely this)
>
> Unfortunately, at the moment, this also means that you would have to
> load the data into the data store twice if you wanted to try the
> Bibliontology RDF translator first and then fall back to the older
> Dublin Core/Zotero RDF import translator. I'll work on a better way of
> handling this for 2.1.

Hi Simon,

Thanks for the very fast response. I needed to change the UUID to:

translator.setTranslator("5e3ad958-ac79-463d-812b-a86a9235c28f");

But it works great.

Would it be possible to dump the data from one Zotero.RDF to the
other, rather than parse the RDFa twice, if I understand you
correctly?

best, Erik

[skornblith]

This is possible (as is determining which translator should be used to
parse the RDF triples within the RDFa translator), but the more
efficient and elegant solution is an API addition on our end. For now,
you're probably best off pretending that there's only a single RDF
translator. It should be easy for us to modify your code to work with
the new API (and thus with multiple translators).

Simon

[Erik Hetzner]

At Thu, 10 Jun 2010 12:03:59 -0700 (PDT),

skornblith wrote:
> This is possible (as is determining which translator should be used to
> parse the RDF triples within the RDFa translator), but the more
> efficient and elegant solution is an API addition on our end. For now,
> you're probably best off pretending that there's only a single RDF
> translator. It should be easy for us to modify your code to work with
> the new API (and thus with multiple translators).

Thanks, Simon. I will do that.

If you have the time, another feature I would like to enable is
fetching alternative representations in RDF via linking as described
in [1], from HTML that looks like:

<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Alice's Homepage</title>

<link rel="alternate" type="application/rdf+xml"

title="RDF Representation"
href="http://www.example.com/data/alice" />
</head> ...

I haven’t yet figured how to do this; I’m hoping I can pass it off to
the RDF translator as well.

I only mention this to ask you to keep this use case in mind as well
when making any API additions.

best, Erik

1. http://www.w3.org/TR/cooluris/#linking

[Avram Lyon]

Erik, Simon and folks,

How does this (conversation below about RDF, changes in 2.1) currently
stand? There was some chatter online today about RDFa, and it would be
nice to get at least some preliminary support into Zotero in the near
future.

Avram

2010/6/10 Erik Hetzner <ehet...@gmail.com>:

[Bruce D'Arcus]

Since Avram brought this thread back up, and I just stumbled on
something related ...

On Thu, Jun 10, 2010 at 12:20 PM, Erik Hetzner <ehet...@gmail.com> wrote:
> At Thu, 10 Jun 2010 12:05:47 -0400,
> Bruce D'Arcus wrote:
>>
>> I don't know if this has any relevance, but the W3C has just published
>> a draft of an RDFa DOM API document:
>>
>> <http://www.w3.org/TR/2010/WD-rdfa-api-20100608/>
>
> Thanks for the link. It does not appear to have any implementations
> yet. If/when it is implemented we could probably use it.

Here's a JS implementation (with notes that it is, or will be, node.js
compatible):

<https://github.com/webr3/rdfa-api>

Bruce

[Erik Hetzner]

At Mon, 24 Jan 2011 23:42:28 +0300,

Avram Lyon wrote:
>
> Erik, Simon and folks,
>
> How does this (conversation below about RDF, changes in 2.1) currently
> stand? There was some chatter online today about RDFa, and it would be
> nice to get at least some preliminary support into Zotero in the near
> future.

Hi Avram,

No progress here, I’m afraid. But the link Bruce sent out earlier
looks promising as a way forward for RDFa processing.

best, Erik