TracNav

e-Framework as a Machine Readable Knowledgebase

Email from Wilbert Kraan, JISC. Please add comments below.

Hello,

At CETIS, we're likely to have an increasing need to be able to represent various parts of the e-framework in a variety of different contexts. For example, it'd be nice to have an up to date list of all 'search' service instances in a page on a Web API catalogue. Or a current list of all SUMs that relate to a particular SIG displayed on that SIG's page. Or all current 'search' service expressions listed inside of a SUM description that specifies a 'search' service genre. I guess other people will have similar needs.

I think there might be a way to do that by using the e-framework as a tag vocabulary in a bookmark service. I've played around with del.icio.us, and I've got it to the point where:

 http://del.icio.us/rss/tag/eframework+service_genre

Will get you an rss feed of all currently defined service genres.

The same goes for SUMs ( http://del.icio.us/rss/tag/eframework+sum) and service expressions ( http://del.icio.us/rss/tag/eframework+service_expression). Each of those bookmarks points to the relevant page on the e-f site or wiki. I've also added a few service_instance and service_toolkit examples that point elsewhere.

All entries have also been tagged by genre, so that

 http://del.icio.us/rss/tag/eframework+service_expression+search

Will get you an rss feed of all currently defined service expressions for the search genre. It's all structured with refinement in mind, so the longer your query, the narrower your result set.

There's a very quick and dirty wiki page here ( http://wiki.cetis.ac.uk/Search) that illustrates how the feeds can be used on a wiki that can render feeds. You could also use the Google feed API ( http://code.google.com/apis/ajaxfeeds/documentation) to render the feeds on any website- maybe something for the e-f wiki itself? Both the Google API and something like Yahoo pipes would allow you to slice and dice the e-f feeds with all kinds of other sources, of course.

I think it'd be great if we could extend and maintain the collection collaboratively, and in a more structured way. At the moment, for example, the eframework+{something} tag combinations are open to everyone on del.icio.us. That's a feature rather than a bug, but sometimes you'd want to be sure that the feed that lists all the service genres in particular, only ever contains those that have been agreed.

For that purpose, we could set up an 'eframework' account (alright, I set it up already :-) that is looked after by the editors. That way

 http://del.icio.us/rss/eframework/service_genre

will get you just the agreed ones

Everyone in the eFIG plus invited experts and other mates could become part of that account's network. That way, any new components bookmarked by any one of us is easily visible in the network, and can be added to the eframework account by a single click. The network also shows the popularity of the submission.

if people think this is a good idea, then what would need to be done next is:

  • transferring the account to the editors
  • eFIG people to put the 'eframework' user in their del.icio.us account's networks (and for the editors to add these 'fans' to the eframework's network)
  • set up and bookmark a lot of wiki pages for those service genres that have been agreed and listed in the registry, but haven't been described yet.
  • bookmark all those implementations, toolkits and instances that are useful to your own community

Any comments?

Cheers,

Wilbert

Comment by Kerry Blinco (email) on Fri Sep 28 13:37:11 2007

Definitely looks like a great idea. Early on I had hoped we would use del.i.cous tags to help build the knowledge base itself particularly for toolkits and instances and things that the e-F doesn't have control over and to build the resources section (you will even see it on the menu) but no one had done anything about it.

But using it to tag the e-F as well is a great idea. - and we could use it to build the liking bits on the site that we don't know because they would currently be hand constructed - like going from genres to related expressions...as you have shown... (and wouldn't that be great that everyone could see if not just your SIG (:-)

Am sure there are lots of uses and to have communities start to help as was the original idea would be fantastic!

Comment by LyleWinton on Fri Sep 28 15:29:15 2007

Great light weight solution, Wilbert. I like some of it, but not sure about some bits...

I love del.icio.us, but the problem I find is that it doesn't support groups well. (Bad for closed collaborations and research in that respect.) "Networks" don't seem to amount to much other than bookmarks of other users. And the for:eframework tag is private.

So I'll suggest a slight change, that is we use Connotea instead. Or at least we evaluate this option.

Also, because del.icio.us uses the URL of the bookmark as the ID for the entry, this can change. But on Connotea I'm pretty sure it doesn't. However the link does go back to Connotea. I suppose we could use handles for persistence. This would mean wiki/in-progress components could keep the same ID/bookmark but the tags would change when they are published.

Additionally, if we use Connotea and we somehow get e-Framework publications into CrossRef we can populate DC information from a Handle/DOI. (Or perhaps this will never happen.)

Comment by wkraan on Fri Sep 28 22:36:52 2007

Thanks for the suggestion, I had not heard of connotea before. I like the RDF output of its API, and I especially like the more powerful URL query language (you can do AND and OR, and arbitrary combinations of users and tags)

I've had a very quick look at the group function in connotea, but I couldn't see an immediate difference with del.icio.us' networks in the GUI: it looked like just the union of all member's bookmarks and not much more. Or did I miss something?

You can create feeds with group+tag in connotea (which del.icio.us can't AFAIK), but I wonder how much difference that makes in practice: you could still have duplicate bookmarks with different URLs and proposed additions mixed in with the agreed resources when querying for something like  http://www.connotea.org/group/eframework/tag/eframework+service_instance+search

The bookmark ID issue is similar: once you've made a bookmark on connotea, it is internally identified by a hash, but with a URL in the GUI ("bookmarks for  http://..."). The difference with del.icio.us is that connotea doesn't really allow you to change the URL (it gives you an option to update a URL after you press "delete bookmark", but a bug seems to prevent the system from committing the change), while del.icio.us does allow you to change a URL.

That doesn't mean that del.icio.us straightforwardly solves the problem you sketch, though. For example:

User 1 makes bookmarkA for resourceA with URLWiki and tagA and tagB

User 2 makes bookmarkA for resourceA with URLWiki and tagA and tagB

On both connotea and delicious, querying /tag/tagA+tagB will result in one bookmark: bookmarkA

In delicious, user2 can change his copy of bookmarkA to point to URLRegistry. /tag/tagA+tagB will now return two results: bookmarkA and bookmarkB, both of which are identical apart from the URL. connotea's process is different, but the result is the same: two bookmarks.

It seems to me that there are two solutions to the problem: either you add another tag to indicate the change in location and status of a component (i.e. "efigged", "agreed" or "registry" or similar), or you query your results from the eframework account alone. The editors will then make sure that there's only one bookmark for one resource, and that it points to the current version.

I personally think the eframework account solution is easier and more reliable, but that doesn't exclude anyone from doing the status tag thing. Either solution would work on del.icio.us or connotea (or any number of other bookmark services).

And that's the crux of the choice between them: it doesn't matter fundamentally. The choice boils down to a preference of lowest possible barrier to entry (lots of people have del.icio.us accounts and know how to use them) versus more powerful querying and the possibility of automatic dc import (connotea).

On balance, I think the lowest barrier to entry is the most important for our purposes. After all, more powerful querying and extra metadata are nice-to-have, but can be worked around or obtained by other means (mash-ups, microformats on the page), while community participation is essential and not so easy to fix in other ways.

Comment by LyleWinton on Mon Oct 1 15:22:42 2007

Wilbert wrote:

I've had a very quick look at the group function in connotea, but I couldn't see an immediate difference with del.icio.us' networks in the GUI: it looked like just the union of all member's bookmarks and not much more. Or did I miss something?

Maybe I haven't fully explored Networks on del.icio.us. With Groups you can explicitly say certain bookmarks are for certain groups. Unfortunately, you can't say "publicly share this bookmark but not through my groups", so all of your public bookmarks show up in all groups, like Networks. I'll try to convince the developers to add this security option.

...while del.icio.us does allow you to change a URL.

...

User 1 makes bookmarkA for resourceA with URLWiki and tagA and tagB User 2 makes bookmarkA for resourceA with URLWiki and tagA and tagB

Actually, the problem I was sketching out was not this one. And I don't think either Connotea or del.icio.us are the solution to this one. I'll try to explain. In my thinking a component (SUM, SE, SG) is a concept represented by one RSS entry. Throughout it's life it can change status and location (wiki to registry) which correspond to tag and URL changes. In connotea the URL is fixed, so you are right this would be a problem. In del.icio.us the URL is the "about", the identifier for the concept, so if you changed the URL you'd get a completely new entry. So I think we need a persistent identifier (URL) that we can use to identify the concept but redirect the URL to where it should go. (I suppose we also need version information on components.)

I personally think the eframework account solution is easier and more reliable, but that doesn't exclude anyone from doing the status tag thing.

Agreed. On reflection I think del.icio.us is probably better as the feed links straight to the URL and not some Connotea hashed page. Presumably things like the google API can do some of the more complex things we need.

Comment by wkraan on Wed Oct 3 02:06:36 2007

With Groups you can explicitly say certain bookmarks are for certain groups. Unfortunately, you can't say "publicly share this bookmark but not through my groups", so all of your public bookmarks show up in all groups, like Networks. I'll try to convince the developers to add this security option.

Ah, I see what you mean now. del.icio.us has "links for you" (which is what the for:eframework tag does). That ends up in an inbox of the eframework account. Not ideal (because others in the network won't be able to see - unless you 'link for you' them too), but it might just about suit our purposes.

In del.icio.us the URL is the "about", the identifier for the concept, so if you changed the URL you'd get a completely new entry. So I think we need a persistent identifier (URL) that we can use to identify the concept but redirect the URL to where it should go. (I suppose we also need version information on components.)

OK, I think I see what you mean. I'd envisaged that the collection would always be queried via either account names or tags, so that the indirection would take place there. In other words: if I get at resourceA by query, then the current URL is simply one of the attributes I get back. I assume it is changeable. In the case of sets of 1 (i.e. genres), you can even flip it around:  http://del.icio.us/eframework/eframework+service_genre+search is a persistent identifier for the search SG (or at least a good enough proxy).

Proper persistent identifiers can obviously do many more things, and can do them much better- but I wouldn't know how they relate to the feed solution. Did you have a particular use case in mind?

In any case, we can stick in any kind of resolveable identifier in the URL field.

Comment by loureya on Tue Oct 23 10:02:44 2007

This comment is mainly directed towards the editorial team...

Assuming that we adopt del.icio.us to generate the feeds; we need to think about how we are going to embed these into the registry items. I have been playing around with a few different methods and have come up with the following options:

  • use an existing Feeds Module (NukeFeeds) in DNN to display (for example the related services) along side the service definition; or
  • embed a free rss-to-javascript script within the service template.

Either of these methods works fine on well structured del.icio.us tags. However the first option doesn't allow you to embed the feed into the definition. You have to add a seperate Feed module either beside (in the right pane), or below the definition. Comments???

Comment by LyleWinton on Mon Oct 29 15:01:49 2007

Do we need to embed the feeds in the registry items and definitions, or just in the display of the items? I vote for embedding in the display, otherwise we might have to manage persistence. In which case I don't mind either option. So long as I can get access to the actual raw feed link on the page. (Little RSS icon.)

Comment by LyleWinton on Mon Nov 5 23:13:47 2007

Ma.gnolia looks like the solution I've been waiting for!  http://ma.gnolia.com/

  • Links directly to the URL
  • Persistent identifiers regardless of bookmark URL changes
  • Much better collaborative/group tagging
  • Access control with private tags, public tags, your tags in groups, and group tags not in your tags, private groups, publicly readable groups, public groups
  • ranking
  • Atom, RSS, OPML, JSON, configurable microformats
  • OpenID
  • Saved copies of websites (however, not publicly viewable)

I suppose this still doesn't address the "possible barrier to entry" as del.icio.us is more popular.

Comment by LyleWinton on Tue Nov 6 08:54:38 2007

Related email discussion from the editorial team. This might add to these discussions...

2. Discuss the "tagging" issues (Ashley and Lyle). Are version changes not an issues since components will link to specific versions, and should not change even if a newer version has been added to the registry (note: added, not replaced)? I could use clarification on this! [When settled, document the procedure and rules as a site procedure for whoever may need to do this in the future.]

Sorry, I do need to clarify. The versions on the tags in this case are for the SUM, not the referred to genres/expressions. But I think you need versions everywhere.

eg.

The context is the EP4LL v1.0 SUM

The sharing tag for the SUM is "SUM_EP4LL_v1_0"

At the very least the SUM should have the tag "SUM_EP4LL_v1_0"

All components used in the SUM have the tag "UsedIn_SUM_EP4LL_v1_0"

If you need to distinguish component types you use tags like "UsedIn_SUM_EP4LL_v1_0" + "ServiceGenre"

Then you can get from a SUM to all components "UsedIn". Or perhaps we need to do all the relationships in the SUM template "ServiceUsedBy_", "KnownUseOf_", "DataSourceUsedBy_" (maybe?), "SUMRelatedTo_", "CORESUMUsedBy_".

The format for the tag is...

"relationship"_"targetName"

"targetName" = "targetType_targetLabel_targetVersion" (proposed scheme for uniqueness)

We are representing a triple: the "Object" (the thing tagged) and it's "Relationship" with the "Target" (done in the tag itself). (We are using del.icio.us as a triple store!?!)

The target and object themselves must have 2 other tags:

  1. The tag that is it's name.
  1. A tag for it's type.

EP4LL v1.0 SUM tags: "SUM_EP4LL_v1_0" + "ServiceUsageModel"

Authenticate v1.1: "SG_Authenticate_v1_1" + "ServiceGenre" + "ServiceUsedBy_SUM_EP4LL_v1_0" + ...

Search v1.0: "SG_Search_v1_0" + "ServiceGenre" + "ServiceUsedBy_SUM_EP4LL_v1_0" + ...

FRED Search v1.0: "SE_FREDSearch_v1_0" + "ServiceExpression" + "KnownUseOf_SG_Search_v1_0"

Comment by LyleWinton on Thurs Jan 3 2008

Just to clarify the above comment...

The tag "SUMRelatedTo_SUM_EP4LL_v1_0" should be interpreted in the following way...

  • The currently tagged item is a SUM Related To the EP4LL SUM version 1.0
  • Items tagged with this tag should only be SUMs.
  • This tag could be used to reconstruct the "Related Service Usage Models" section of the EP4LL SUM version 1.0 . Simply look for all items tagged with this.
  • The existence of the EP4LL SUM v1.0 tagged with "SUM_EP4LL_v1_0" implies that the "SUMRelatedTo_SUM_EP4LL_v1_0" might exist.

Note: As "Related Service Usage Models" section also exists for Service Expressions it is possible for tags to exist such as "SUMRelatedTo_SE_FREDSearch_v1_0". This tags should still be applied only to SUMs.