On Wed, Apr 13, 2011 at 12:37 PM, Brandon Muramatsu <[log in to unmask]> wrote:
On Wed, Apr 13, 2011 at 12:26 PM, Phil Barker <[log in to unmask]> wrote:
Hi Paul, everyone,
I like the aspects of this proposal that go beyond bookmarking as seen in Delicious (though as we discussed at the hackdays bookmarking services that don't rely on Yahoo finding the right buyer for Delicious have their attractions).

Phil, that's just the sentiment that I was planning on expressing. 

I'll phrase it a slightly different way, perhaps they want to work with all bookmarking services that provide an API (well maybe pick 2).

The way I think of this proposed idea is that the bookmarking service is a data store for at least some of the metadata. One of the reasons I think bookmarking services were successful in their day and age is that they were very simple to use: URL, title, maybe a description, and tags. As educational technologists, we'd like to see a bit more structure. But it's hard to argue with the simplicity and how much use that simplicity drove. 

(We had a set of projects called Folksemantic--linking folksonomies (essentially the self-tagging) and semantic. A few years back we were looking at how we might extract "semantic" meaning from items that were tagged up.) 

Also, I'd be a bit concerned about orphaning data if the service went down or was discontinued.

So the twist I'm suggesting is a front end to a bookmarking service that allows you to collect additional structured data while storing some (or all of it) in an existing bookmarking service. (There's a big *if* here, if the service has an API that allows this.)

My other thought is has twitter and hastags and URL shorteners replaced bookmarking services? If they have, what might that imply for the project?

This is why we chose to implement the OER Commons bookmarklet, rather than simply leveraging tech like Delicious or Diigo.  Metadata matters, and we want to collect as much of it as we can -- and we also want to target it as well as we can.  There's data we want to be *sure* we collect for our use cases.  

I looked into the possibility of defining one's own required data fields for the various social bookmarking sites.  I have yet to find one that allows that; they predefine their own fields.  Diigo comes closest in that they specify different classes of bookmarks, and the data fields they collect are different across those classes -- but those classes are still predefined, with no opportunity (yet) to define your own.

There's no reason we can't also collect data from various URL shorteners and bookmarking services, and that's how we intend to use the Learning Registry; as a place to gather as much data about a resource as possible, using the URL as the primary key.  But there's no reason that this scheme shouldn't be completely additive.  One user bookmarks a link at Diigo.  Another user tweets it.  A third uses OER Commons to capture specific learning metadata and provide a ranking.  All of that data goes into LR, from which everyone may harvest freely, and the whole becomes greater than the sum of the parts.  I think that's the future.

--g