Notes and attachments are just items and don't have a separate URI pattern.
Group data:
Same as above, but with /groups/[group_name]/*
Abstract items:
/items/[abstractItemID]
User and group items will be asynchronously linked to abstract items using owl:sameAs. User/group-item-specific metadata can be represented with a separate URI, e.g., /users/[username]/items/[itemID]/data, in RDF, but /users/[username]/items/[itemID] is what the web page will be and what will be served by the API as the user item's URI.
An "item" is what an item always has been in Zotero parlance—the foundational user-editable entity in a Zotero library. Some are standalone, and some are child items, and they can belong to collections, have associated tags, be related to other items, etc. This is why notes and attachments are just types of items.
There's a distinction between user item URIs and group item URIs because the items belong to specific libraries, and the separation provides for more transparent URLs, which is important for the site and for the API.
As Fred said on the BIBO list, it'd probably be helpful to put this all together; to show the proposed encodings in a little more detail. Let's take something from today's New York Times.
http://www.nytimes.com/2009/05/27/business/27auto.html You wrote:
There's a distinction between user item URIs and group item URIs because the items belong to specific libraries ...
My followup question: why is this relevant? Why not the below?
My followup question: why is this relevant? Why not the below?
You're using RDF-based examples, but RDF isn't the only context in which items will be represented or accessed. Most manipulation of objects in the Zotero ecosystem is done using various ids—item ids, collection ids, creator ids—and the URIs above (and associated web pages) follow logically from various combinations of those ids. There's information about a Zotero item that's distinct from the source (e.g., NYT article page). For example, http://zotero.org/bdarcus/items/1234 is an item in your library, and you will be able to delete it by sending an HTTP DELETE request to [api.server.address]/bdarcus/items/1234.* Using your example above, there's no Zotero item id, so to delete an item or assign it to a collection or add a tag, rather than having a clear, RESTful API, you'd have to somehow shuttle around the nytimes.com URI as a representation of the Zotero item and do a URI-based lookup on the server for any actions you wanted to perform. (That is, unless you're speaking strictly of RDF output and the website/API would have completely unrelated URIs, but that doesn't make much sense to me, and it isn't how this thread began.)
* If we wanted to be daring, the API server could just use zotero.org, and the GET response format (website HTML or Atom) could be determined by content negotiation, but that would present a bunch of additional technical challenges that probably aren't worth the effort. As it is, there'll be a <link rel="alternate" type="application/atom+xml" ...> available at the main URI.
From the RDF/OWL perspective (and really, it makes sense conceptually, so is not just an artifact of the technology), if you give something (x) an owl:sameAs relationship to something else (y), you are saying "all the properties of x apply to y (and vice versa)." So if you were, say, to merge all that data in a triple store with owl:sameAs inferencing, that data would literally get smashed together.
Is that what you intend?
Or to get practical: where do you hang the data (in the exposed RDF) about who captured/bookmarked an item, when they did it, and where it came from?
My example was confusing, since I meant to have a zotero URI (the bookmark-like resource), and link to the original from there.
OK, well that changes my response, but, if your example is now correct, then I'm still not understanding your previous question re: user vs. group item URIs. You're using different URIs from the ones I posted above, but your example still has a user-specific item within an individual user's library. So it would follow that group items, which aren't owned by individual users, are within group libraries, no?
Or to get practical: where do you hang the data (in the exposed RDF) about who captured/bookmarked an item, when they did it, and where it came from?
I said above that "User/group-item-specific metadata can be represented with a separate URI, e.g., /users/[username]/items/[itemID]/data, in RDF", as you suggested, so I'm not sure what your concern is at this point. I'm generally happy to defer to you/Fred/Simon on specific recommendations for the RDF representation.
Three short thoughts about changing group name. (I skimmed this long thread, and did not see these, but apologize if repeated them.)
1) perhaps it might be helpful to average users changing a group name to warn them this will change the URI and allow them to revert. Also prevents mistakes...accidentally placed a typo in that field already.
2) Most systems like this allow you to change a title (e.g. <h1>title</h1> ) without changing a username/URI. Personally I would prefer an option of changing title, for several reasons, Or at least allow a subtitle of <h2> under the main title, so it can be a bit more explanatory of a title than a short, easier to type slug for URI.
3) if I understand correctly what you say with forwarding, someone changing the name around could, over time, deliberately or accidentally "squat" on major natural language permutations that describe a field.
Upgrade Storage
User data:
/users/[username]
/users/[username]/items
/users/[username]/items/[itemID]
/users/[username]/collections
/users/[username]/collections/[collectionID]
Notes and attachments are just items and don't have a separate URI pattern.
Group data:
Same as above, but with /groups/[group_name]/*
Abstract items:
/items/[abstractItemID]
User and group items will be asynchronously linked to abstract items using owl:sameAs. User/group-item-specific metadata can be represented with a separate URI, e.g., /users/[username]/items/[itemID]/data, in RDF, but /users/[username]/items/[itemID] is what the web page will be and what will be served by the API as the user item's URI.
Also, why does a group "item" have a different identity? Because it can be collaboratively edited?
There's a distinction between user item URIs and group item URIs because the items belong to specific libraries, and the separation provides for more transparent URLs, which is important for the site and for the API.
http://www.nytimes.com/2009/05/27/business/27auto.htmlYou wrote: My followup question: why is this relevant? Why not the below?
<http://zotero.org/users/doej/library>;
z:hasItem <http://www.nytimes.com/2009/05/27/business/27auto.html>; .
<http://zotero.org/groups/1234/library>;
z:hasItem <http://www.nytimes.com/2009/05/27/business/27auto.html>; .
E.g. link from the library (or collection) to the item, rather than the reverse. Does this still hold if my suggestion above is correct? Or rather, does this change the explanation?
I'm still a bit confused on the details of how this will work.
* If we wanted to be daring, the API server could just use zotero.org, and the GET response format (website HTML or Atom) could be determined by content negotiation, but that would present a bunch of additional technical challenges that probably aren't worth the effort. As it is, there'll be a <link rel="alternate" type="application/atom+xml" ...> available at the main URI.
My example was confusing, since I meant to have a zotero URI (the bookmark-like resource), and link to the original from there.
<http://zotero.org/users/doej/library>;
z:hasItem <http://zotero.org/users/doej/1234>; .
<http://zotero.org/users/doej/1234>;
bm:recalls <http://www.nytimes.com/2009/05/27/business/27auto.html>; .
From the RDF/OWL perspective (and really, it makes sense conceptually, so is not just an artifact of the technology), if you give something (x) an owl:sameAs relationship to something else (y), you are saying "all the properties of x apply to y (and vice versa)." So if you were, say, to merge all that data in a triple store with owl:sameAs inferencing, that data would literally get smashed together.
Is that what you intend?
Or to get practical: where do you hang the data (in the exposed RDF) about who captured/bookmarked an item, when they did it, and where it came from?
Thanks for clarifying.
(I skimmed this long thread, and did not see these, but apologize if repeated them.)
1) perhaps it might be helpful to average users changing a group name to warn them this will change the URI and allow them to revert. Also prevents mistakes...accidentally placed a typo in that field already.
2) Most systems like this allow you to change a title (e.g. <h1>title</h1> ) without changing a username/URI. Personally I would prefer an option of changing title, for several reasons, Or at least allow a subtitle of <h2> under the main title, so it can be a bit more explanatory of a title than a short, easier to type slug for URI.
3) if I understand correctly what you say with forwarding, someone changing the name around could, over time, deliberately or accidentally "squat" on major natural language permutations that describe a field.