Interpretation of zotero embedded URIs (in openoffice doc)

bmcm

So, I've been trying to make sense of the URIs that zotero embeds with citations in (say) an openoffice document; for example:

http://zotero.org/groups/3463/items/2M7JSWRM

The most obvious thing to try is to see if this returns anything if I try it in a browser (or other web agent). I would not expect it to return anything useful (or anything at all) in the case of items taken from my private, local, "My Library". But for items from a public groups library on zotero.org it seems reasonable to think that it might return something relevant. Right now it does not; but I am wondering if it is supposed to, and if so, what that is planned to be?

Separately from this embedded URI, I can browse to the "corresponding" item, via this URI:

http://www.zotero.org/groups/aishe-j/items/42368748

Which gives me another, but different, unique (?) identifier for this metadata item (NB: I don't mean an ID for the thing being described by this metadata, which would be another idea altogether). But I can't see any natural relationship between these two URIs.

I did find this previous discussion which is at least somewhat relevant, where Dan Stillman mentions:

(URLs generated in the client and embedded in documents will use the item's secondary key, which is a random 8-character string, instead of the id, which is now server-generated and no longer synced to clients, but, e.g., http://zotero.org/bdarcus/items/2H8FWNL3 will redirect to http://zotero.org/bdarcus/items/12345. We use ids for items on the site because they're less unwieldy.)

which suggests to me that there is or was an intention that the URI embedded in the citation (using the "random 8-character string" which is the item's "secondary key") would automatically redirect to the "corresponding" URI (using the item's "server-generated" id). Is that correct, or am I just not following any of this?

(The background question in my mind, of course, is whether the embedded URIs are intended to be usable as stable links to harvest item metadata into the future? And yes, I know that "stable" would still, at best, only mean "subject to anybody with write access to the item on zotero.org choosing to modify or delete it".)

Thanks - Barry.

dstillman

Yes, the key-based URI is intended to resolve to the item's page—it just doesn't yet.

The background question in my mind, of course, is whether the embedded URIs are intended to be usable as stable links to harvest item metadata into the future?

We've considered this is in the past, but full embedded metadata is likely a better (decentralized) solution, assuming the technical hurdles with embedding in the various applications and document formats and modes can be overcome.

bdarcus

My basic point in all this is that projects like Zotero need to work towards a situation where their implementations make no assumptions about where the data comes from.

bmcm

Hi Dan -

Thanks for that response. You wrote that "... full embedded metadata is likely a better (decentralized) solution, assuming the technical hurdles with embedding in the various applications and document formats and modes can be overcome." And I do certainly look forward to that; but I also see worthwhile use cases for linkage to metadata, so I don't think it needs to be an "either/or" situation. Ideally, embedding and external linkage can ultimately co-exist, with users being able to choose which is more suitable for their specific needs. In any case, it's good to have a better idea what the roadmap is.

dstillman

What's the downside of embedded metadata, other than somewhat larger file sizes? A server-based solution also gets into issues of access privileges and data permanence that an embedded solution avoids.

I don't mean to imply that we wouldn't still store URIs with the embedded data so that links between items in different libraries could be maintained, but I don't see much advantage to using that mechanism for metadata retrieval (again, assuming we can solve cross-platform issues with embedded data).

bmcm

Dan asks: "What's the downside of embedded metadata?", so, to be clear, I don't think there is any downside to it at all; I just wanted to check that it wasn't a question of removing the linkage once metadata is embedded, but that is now clear.

bmcm

Hi -

Just "pinging" this issue again. Dan previously said "Yes, the key-based URI is intended to resolve to the item's page—it just doesn't yet"; as far as I can see that is still the situation (i.e., these embedded citation URI's still don't resolve to the corresponding items). I have not done anything that would rely on this in the meantime anyway, but just want to check that that that is still the planned functionality?

Thanks - Barry.