ED is holding a code license: New BSD License
and a content license: Creative Commons 3.0 BY
The content license comes in BY and BY-SA
BY: This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered, in terms of what others can do with your works licensed under Attribution.
SA: This license lets others remix, tweak, and build upon your work even for commercial reasons, as long as they credit you and license their new creations under the identical terms. This license is often compared to open source software licenses. All new works based on yours will carry the same license, so any derivatives will also allow commercial use.
For all the licenses:
http://creativecommons.org/about/licenses/meet-the-licenses
Showing posts with label ED. Show all posts
Showing posts with label ED. Show all posts
Monday, August 25, 2008
Aliases
ED is now recording the aliases for a term. Aliases are being recorded as an rdfs:label attached to the topic (the guid of the term).
Wednesday, August 6, 2008
Connotea Seperation
Went through the new ed_connotea.js.template javascript and finished modifying it like I did the previous ed_connotea js so that it works with the Connotea free ED that I'm working on.
Labels:
Connotea,
Connotea seperated,
ED,
ed_connotea.js.template,
js
Tuesday, August 5, 2008
URL Limit Solution
After having a talk and some code Review with Eddie on Friday, he offered an interesting solution to the URL Limit which doesn't require ajax or any modification to the servlets.
He suggested that I submit the tagging xml to the Tagging Servlets (TagManagerSaveTaggingServlet and SPARQLTaggingServlet) as a file. This would involve submitting the whole form to the TaggingServlets, which would then contain an input specifying file. Great! But... when you create an inputfileElement, it comes with the browse button which allows you to pull files from your computer. We don't want this though. We want to create a file on the fly and feed it into the input stream of which the inputfileElement uses.
I did not find out how to do that.
However, the following solution is still much like the file solution, but instead of making a file on the fly and putting it in a form (also made on the fly) and submitting said form to a url within a designated iframe....
We:
-create a form on the fly with action=TaggingServlet and target=iframe
-create an input of type hidden on the fly with the tagging xml as its value
-attach the hidden input to the form
-attach the form to the body
-submit the form
Surprisingly... this works! I've yet to find (through testing or research) a limit for the size of an input in any browser. Further testing may reveal otherwise, but IE isn't complaining, which is rare.
The other plus side is the tagging Servlets don't need modification since it works in the exact same way as before except the 'tagging' parameter is nolonger in the url, but as part of a form, which as far as the Servlet is concerned, is the same thing!
hooray.
...
for now....
He suggested that I submit the tagging xml to the Tagging Servlets (TagManagerSaveTaggingServlet and SPARQLTaggingServlet) as a file. This would involve submitting the whole form to the TaggingServlets, which would then contain an input specifying file. Great! But... when you create an inputfileElement, it comes with the browse button which allows you to pull files from your computer. We don't want this though. We want to create a file on the fly and feed it into the input stream of which the inputfileElement uses.
I did not find out how to do that.
However, the following solution is still much like the file solution, but instead of making a file on the fly and putting it in a form (also made on the fly) and submitting said form to a url within a designated iframe....
We:
-create a form on the fly with action=TaggingServlet and target=iframe
-create an input of type hidden on the fly with the tagging xml as its value
-attach the hidden input to the form
-attach the form to the body
-submit the form
Surprisingly... this works! I've yet to find (through testing or research) a limit for the size of an input in any browser. Further testing may reveal otherwise, but IE isn't complaining, which is rare.
The other plus side is the tagging Servlets don't need modification since it works in the exact same way as before except the 'tagging' parameter is nolonger in the url, but as part of a form, which as far as the Servlet is concerned, is the same thing!
hooray.
...
for now....
Friday, July 18, 2008
ED API
The web methods for the ED API have been committed, but not yet deployed.
Interesting thing I ran into when trying to do an HTTP Get on google book search using Java's URLConnection.
Google adheres to a slightly different API from other web resources when you try to connect to it.
Found out about it here:
The suggestion in this thread works for google and searchmash (which is a cool little google API that returns results as JSON to you)
http://forum.java.sun.com/thread.jspa?threadID=5140278&messageID=9515635
and
This suggestions works for google book search:
http://forum.java.sun.com/thread.jspa?messageID=1033250
Interesting thing I ran into when trying to do an HTTP Get on google book search using Java's URLConnection.
Google adheres to a slightly different API from other web resources when you try to connect to it.
Found out about it here:
The suggestion in this thread works for google and searchmash (which is a cool little google API that returns results as JSON to you)
http://forum.java.sun.com/thread.jspa?threadID=5140278&messageID=9515635
and
This suggestions works for google book search:
http://forum.java.sun.com/thread.jspa?messageID=1033250
Friday, July 11, 2008
Ajax and ED
It's time for more Ajax...
Here's the problem I'm running into with ED. When the user hits the submit button. The javascript calls a Servlet which composes the SPARQL/Update Insert statements and then submits them to the Virtuoso Server.
I have to break up the Insert statements into an Insert for Tagging information (taggedBy, taggedResource, taggedOn, etc) and an Insert for each Tag in case it doesn't already exist. The Tag Insert can be a small Insert statement or a big one depending on how many types it has. The more types it has, the bigger it is because I have to create the Type in case it doesn't already exist.
So for each insert I'm doing a Post to the Virtuoso Server awaiting reply before I continue and send off the next one.
Thus, with the more tags there are, the more Posts I'm making, the longer it takes, especially if it takes a while for the information to go across the wire and back. (What if someone's tagging in Africa!). I COULD spawn several threads to do a submission for me for the tags to avoid the "stop and wait" protocol I'm using right now...
OR
as Ben suggested. I can use Ajax!
Question is. How do I use Ajax? Well here's what I'm thinking right now...
Ajax let's me talk to the Server and tell it to do a function without having to reload a page.
When someone adds a new tag. I'll use Ajax to submit that tag (since a tag is independent of a user until you make a connection using the "associatedTag" property) to Virtuoso. I'll leave the associatedTag property for later when the user ACTUALLY hits submit.
If the tag already exists, *shrug... user doesn't know.
If the user deletes the tag... the tag will still be added, but it won't be associated with the actual tagging, since it won't be included in the submit.
Trouble: What if a post to the Virtuoso Server fails? I guess I'd have to check for that...
Here's the problem I'm running into with ED. When the user hits the submit button. The javascript calls a Servlet which composes the SPARQL/Update Insert statements and then submits them to the Virtuoso Server.
I have to break up the Insert statements into an Insert for Tagging information (taggedBy, taggedResource, taggedOn, etc) and an Insert for each Tag in case it doesn't already exist. The Tag Insert can be a small Insert statement or a big one depending on how many types it has. The more types it has, the bigger it is because I have to create the Type in case it doesn't already exist.
So for each insert I'm doing a Post to the Virtuoso Server awaiting reply before I continue and send off the next one.
Thus, with the more tags there are, the more Posts I'm making, the longer it takes, especially if it takes a while for the information to go across the wire and back. (What if someone's tagging in Africa!). I COULD spawn several threads to do a submission for me for the tags to avoid the "stop and wait" protocol I'm using right now...
OR
as Ben suggested. I can use Ajax!
Question is. How do I use Ajax? Well here's what I'm thinking right now...
Ajax let's me talk to the Server and tell it to do a function without having to reload a page.
When someone adds a new tag. I'll use Ajax to submit that tag (since a tag is independent of a user until you make a connection using the "associatedTag" property) to Virtuoso. I'll leave the associatedTag property for later when the user ACTUALLY hits submit.
If the tag already exists, *shrug... user doesn't know.
If the user deletes the tag... the tag will still be added, but it won't be associated with the actual tagging, since it won't be included in the submit.
Trouble: What if a post to the Virtuoso Server fails? I guess I'd have to check for that...
Emailing Errors!
I can see this being advantageous to ED in the long run.
I've gone and implemented an EDemailer class that uses Javamail to send off emails.
Whenever I get an error in either my SPARQLTagManager or SPARQLTaggingServlet, the EDemailer's send function is called and an email is fired off to an account I set up. "ed.developers@gmail.com"
The information I pass on is the GMT time it happenned (to conform with what is being recorded in the database), the xml that was passed into the SPARQLTaggingServlet, the response code (if it gets that far) and the SPARQL Insert statement (if it gets that far).
I'm using "smtp.gmail.com" as the SMTP host (Port 465). You have to authenticate with them with a gmail account in the code or else you can't use it. Since I'm using JavaMail I had to get the activation.jar and mail.jar. Supposedly J2EE comes with it, but that's a lie. So I had to get it from sun's site. On top of it. If you put activation.jar and mail.jar in your lib under Web-INF, it won't work! Those jars NEED to be in the Tomcat's lib folder. AND ONLY in Tomcat's lib folder. If you don't do this, you will make your mailer program sad!
If you're going to be using a smtp host that's running on your localhost. you'll need some other configuration for that, that involves Tomcat's server.xml and context.xml.
Haven't tried that out yet, so I won't make any claims.
But at least this way, when things go wrong. (and assuming I'm checking the ed.developers gmail account (forward it to my normal later)) I will be informed when things go wrong.
Still need to deploy this on arch.uwindsor of course.... Hopefully if I put the extra jars in it's lib it won't complain....
I've gone and implemented an EDemailer class that uses Javamail to send off emails.
Whenever I get an error in either my SPARQLTagManager or SPARQLTaggingServlet, the EDemailer's send function is called and an email is fired off to an account I set up. "ed.developers@gmail.com"
The information I pass on is the GMT time it happenned (to conform with what is being recorded in the database), the xml that was passed into the SPARQLTaggingServlet, the response code (if it gets that far) and the SPARQL Insert statement (if it gets that far).
I'm using "smtp.gmail.com" as the SMTP host (Port 465). You have to authenticate with them with a gmail account in the code or else you can't use it. Since I'm using JavaMail I had to get the activation.jar and mail.jar. Supposedly J2EE comes with it, but that's a lie. So I had to get it from sun's site. On top of it. If you put activation.jar and mail.jar in your lib under Web-INF, it won't work! Those jars NEED to be in the Tomcat's lib folder. AND ONLY in Tomcat's lib folder. If you don't do this, you will make your mailer program sad!
If you're going to be using a smtp host that's running on your localhost. you'll need some other configuration for that, that involves Tomcat's server.xml and context.xml.
Haven't tried that out yet, so I won't make any claims.
But at least this way, when things go wrong. (and assuming I'm checking the ed.developers gmail account (forward it to my normal later)) I will be informed when things go wrong.
Still need to deploy this on arch.uwindsor of course.... Hopefully if I put the extra jars in it's lib it won't complain....
Monday, July 7, 2008
Delay time in submitting to Connotea
Now that we've got ED submitting tagging information to the sandbox graph of the Vrituoso server, in addition to submitting it the ED Database, I've had to put in a delay to prevent the Form from submitting until all the information has been submitted to the sandbox and confirmed that it was successful.
Trouble is... this can take a while since I need to break up a submission into a SPARQL insert statement for every tag since the number types for a tag are variable. making an insert statement potentially very very long.
And if you have A LOT of tags. The wait for a response can get even longer.
I set it at 20 seconds before it times out and an error page is presented to the user.
Before I was able to add up to 6 or 7 tags between 2-4 ftypes each and it would be under 10 seconds. but just recently Ben showed me an error that he got on Entity Describer, that went past the 20 second mark.
I'll have to test the capacity of tags + ftypes I can submit before I have say it's taking too long, but if need be I can analyze how long a tag insert is going to be and start merging them together if they're short enough. Seems a waste to do a 1 tag 1 ftype insert for a whole hTTPPost.
Trouble is... this can take a while since I need to break up a submission into a SPARQL insert statement for every tag since the number types for a tag are variable. making an insert statement potentially very very long.
And if you have A LOT of tags. The wait for a response can get even longer.
I set it at 20 seconds before it times out and an error page is presented to the user.
Before I was able to add up to 6 or 7 tags between 2-4 ftypes each and it would be under 10 seconds. but just recently Ben showed me an error that he got on Entity Describer, that went past the 20 second mark.
I'll have to test the capacity of tags + ftypes I can submit before I have say it's taking too long, but if need be I can analyze how long a tag insert is going to be and start merging them together if they're short enough. Seems a waste to do a 1 tag 1 ftype insert for a whole hTTPPost.
Labels:
delay,
ED,
Entity Describer,
HTTPPost,
Insert Statements,
SPARQL,
SPARQL/Update
Thursday, June 26, 2008
ED SPARQL/Update
I've added in 1 new class and 1 new servlet to the org.icapture.ED.tag package.
-SPARQLTaggingServlet.java is a servlet that functions in the same way as TagManagerSaveTaggingServlet.java
-SPARQLTagManager.java is a java class that functions in the same way as the TagManager.java
When a user hits the submit button on ED - the javascript normally calls the TagManagerSaveTaggingServlet (passing into it all the tagging data in xml format as a parameter). SPARQLTaggingServlet will be used in the same way. Call it in the same way with the same xml. SPARQLTaggingServlet acts as Servlet wrapper for the main class which is SPARQLTagManager. It creates a Tagging object with that xml and passes it into SPARQLTagManager which processes it into SPARQL/Update (SPARUL) INSERT statements and posts them to a Virtuoso server via "http://biomoby.elmonline.ca/sparql" as parameters which are then executed.
If it is successful (determined inside SPARQLTagManager via response codes), all inserts were made successfully and it will return the ResponseCode from the Virtuoso Server (200 if successful, anything else otherwise) to the SPARQLTaggingServlet.
-SPARQLTaggingServlet.java is a servlet that functions in the same way as TagManagerSaveTaggingServlet.java
-SPARQLTagManager.java is a java class that functions in the same way as the TagManager.java
When a user hits the submit button on ED - the javascript normally calls the TagManagerSaveTaggingServlet (passing into it all the tagging data in xml format as a parameter). SPARQLTaggingServlet will be used in the same way. Call it in the same way with the same xml. SPARQLTaggingServlet acts as Servlet wrapper for the main class which is SPARQLTagManager. It creates a Tagging object with that xml and passes it into SPARQLTagManager which processes it into SPARQL/Update (SPARUL) INSERT statements and posts them to a Virtuoso server via "http://biomoby.elmonline.ca/sparql" as parameters which are then executed.
If it is successful (determined inside SPARQLTagManager via response codes), all inserts were made successfully and it will return the ResponseCode from the Virtuoso Server (200 if successful, anything else otherwise) to the SPARQLTaggingServlet.
Labels:
ED,
Entity Describer,
SPARQL,
SPARQL/Update,
SPARUL,
Virtuoso
Tuesday, June 24, 2008
Manual URI entry Form for ED!
Forgot to post about this earlier.
Did up a manual URI form for Entity Describer so that you can enter a URI manually.
URL being 'http://arch.uwindsor.ca:8080/ED/manualURI'
Posts the URI to Connotea and ED Database as well and requires that you enter a URI and Title.
Problems I ran into:
Not sure how to circumvent Connotea's fixsize() function which resizes your browser window. I can see that becoming really annoying in the future.
Any ideas?
Did up a manual URI form for Entity Describer so that you can enter a URI manually.
URL being 'http://arch.uwindsor.ca:8080/ED/manualURI'
Posts the URI to Connotea and ED Database as well and requires that you enter a URI and Title.
Problems I ran into:
Not sure how to circumvent Connotea's fixsize() function which resizes your browser window. I can see that becoming really annoying in the future.
Any ideas?
Tuesday, June 10, 2008
ED, Connotea, OpenID
I've added in a link to for the current ED to login with an OpenID.
Really all it's doing is submitting the OpenID to Connotea to handle the rest of the work.
But the trouble is, once I've passed it off to Connotea, it's out of my control, so I can't have the same window/tab redirect back to ED once it's done authenticating.
So what I've done is I have is the AddToED servlet opening in a new tab/window while the other one handles the authentication.
I imagine this will lead to confusion later if the authentication doesn't go through since people will simply continue on with ED and THEN find out they haven't actually logged into Connotea once they've submitted their bookmark and annotations.
Another issue I ran into with Connotea, was that it doesn't like all OpenID Providers. I've benn trying the more common providers: Yahoo, Vidoop and myOpenID, but so far the only one that has worked is myOpenID.
And yes... I did make sure to change the OpenID in the Advanced Setting of Connotea before trying each one.
Really all it's doing is submitting the OpenID to Connotea to handle the rest of the work.
But the trouble is, once I've passed it off to Connotea, it's out of my control, so I can't have the same window/tab redirect back to ED once it's done authenticating.
So what I've done is I have is the AddToED servlet opening in a new tab/window while the other one handles the authentication.
I imagine this will lead to confusion later if the authentication doesn't go through since people will simply continue on with ED and THEN find out they haven't actually logged into Connotea once they've submitted their bookmark and annotations.
Another issue I ran into with Connotea, was that it doesn't like all OpenID Providers. I've benn trying the more common providers: Yahoo, Vidoop and myOpenID, but so far the only one that has worked is myOpenID.
And yes... I did make sure to change the OpenID in the Advanced Setting of Connotea before trying each one.
Labels:
authentication,
Connotea,
ED,
Entity Describer,
OpenID
Monday, June 9, 2008
About FetchRequest of OpenID
With regards to an earlier post:
Using a FetchRequest:
This is how it's done in version 2.0 and this is what all OpenID Providers use. Currently I haven't got this working yet, but as I found out, it was because I don't have the lastest version of OpenID4Java and will have to get the latest from their SVN off of googleCode. (I'll update this as soon as I get it working) This googlegroup post explains it in more detail.
I checked out the latest Openid4java off of their SVN on GoogleCode at:
http://openid4java.googlecode.com/svn/trunk/ openid4java-read-only
Went into my console, went to the project I just checked out and typed in:
>ant jar
to build a new jar for java-openid-sxip. The jar will be located in the build folder as: java-openid-sxip. I replaced the existing java-openid-sxip jar in my referenced libraries and as a result, it has fixed the earlier problem I was having with the FetchRequest not working. This was because my parameters were showing up:
key: openid.ns.ext1
value: http://openid.net/srv/ax/1.0-draft7
when it should have been just
key: openid.ns.ext1
value: http://openid.net/srv/ax/1.0
The -draft7 that sxip left in there as a download prevents the FetchRequest from working. The only trouble I'm running into now is Yahoo! identifying my website as unsafe and not sending it user information. This is most likely because I'm running the webapp locally under localhost, which is not a valid url for openID to Yahoo! and thus considers it an unsafe website.
Using a FetchRequest:
This is how it's done in version 2.0 and this is what all OpenID Providers use. Currently I haven't got this working yet, but as I found out, it was because I don't have the lastest version of OpenID4Java and will have to get the latest from their SVN off of googleCode. (I'll update this as soon as I get it working) This googlegroup post explains it in more detail.
I checked out the latest Openid4java off of their SVN on GoogleCode at:
http://openid4java.googlecode.com/svn/trunk/ openid4java-read-only
Went into my console, went to the project I just checked out and typed in:
>ant jar
to build a new jar for java-openid-sxip. The jar will be located in the build folder as: java-openid-sxip. I replaced the existing java-openid-sxip jar in my referenced libraries and as a result, it has fixed the earlier problem I was having with the FetchRequest not working. This was because my parameters were showing up:
key: openid.ns.ext1
value: http://openid.net/srv/ax/1.0-draft7
when it should have been just
key: openid.ns.ext1
value: http://openid.net/srv/ax/1.0
The -draft7 that sxip left in there as a download prevents the FetchRequest from working. The only trouble I'm running into now is Yahoo! identifying my website as unsafe and not sending it user information. This is most likely because I'm running the webapp locally under localhost, which is not a valid url for openID to Yahoo! and thus considers it an unsafe website.
Labels:
ED,
Entity Describer,
fetchRequest,
OpenID,
Registration
Sunday, June 8, 2008
Entity Describer and GoogleCode
Ben suggested putting Entity Describer up on GoogleCode to make it a publicly available tool (which technically it is right now)... But on GoogleCode people will be able to contribute stuff to it! and as Ben put it, "It'll make sure we keep good coding style, since other people will be looking at and using it".
I've had previous projects on GoogleCode because it makes source control for school group projects so much easier, but I couldn't remember if there were any rules ED should be concerned about, so I had another quick look.
-Anything that goes on GoogleCode is Open Source.
-We can terminate the project whenever we wish to and take it off GoogleCode
-GoogleCode can terminate our project if they catch us doing something illegal
-When you create a project, you choose an open source license (GNU General Public License v3 , Apache License 2.0)
-On set up you establish the project owners and the project members who are both capable of contributing/making changes to the code
-Anyone may download a READ-ONLY copy of the code (ie. Can't commit changes to GoogleCode for this specific project)
Looks good to me.
Terms of Service
I've had previous projects on GoogleCode because it makes source control for school group projects so much easier, but I couldn't remember if there were any rules ED should be concerned about, so I had another quick look.
-Anything that goes on GoogleCode is Open Source.
-We can terminate the project whenever we wish to and take it off GoogleCode
-GoogleCode can terminate our project if they catch us doing something illegal
-When you create a project, you choose an open source license (GNU General Public License v3 , Apache License 2.0)
-On set up you establish the project owners and the project members who are both capable of contributing/making changes to the code
-Anyone may download a READ-ONLY copy of the code (ie. Can't commit changes to GoogleCode for this specific project)
Looks good to me.
Terms of Service
Labels:
ED,
Entity Describer,
GoogleCode,
License,
Open Source
Thursday, June 5, 2008
OpenID, Entity Describer and Security
Originally I wanted to publish restricted sites under the web.xml and take advantage of HTTP's existing authorization and authentication functions. This way 401 or 403 errors would be produced on trying to type in restricted URLs without authentication. However I have not found a way to use these basic authentication schemes (Basic, Form-based, digest and Client Certificate) without implementing a username and password and leaving all the authentication work to be done by these schemes even though authentication is already being done by OpenID.
The next method I looked at to restrict site access was using the SessionID. So as it stands, as soon as ED receives the the authentication from the OpenID Provider and ED has verified it, ED sets a sessionID cookie for the user. So long as that cookie exists, the user may access ED without re-logging in. On logging out, the sessionID cookie is destroyed and the session is invalidated. This method requires that at every restricted page there be a check to determine if cookie sessionID from the client and the sessionID from the server match. If the session is invalid or the cookie sessionID does not match, the user is redirected to the login page.
Cookie Theft
The major concern with keeping a cookie for the sessionID is that a person may determine the sessionID from packet sniffing, leading to possible impersonation of a user. One way around this is to use SSL or TLS which encrypts data going back and forth between the client and server, thus encrypting the cookie. This service is requested of the Web Server which hosts your website.
If anyone has any other thoughts on how to implement security, I would be more than happy to hear it.
The next method I looked at to restrict site access was using the SessionID. So as it stands, as soon as ED receives the the authentication from the OpenID Provider and ED has verified it, ED sets a sessionID cookie for the user. So long as that cookie exists, the user may access ED without re-logging in. On logging out, the sessionID cookie is destroyed and the session is invalidated. This method requires that at every restricted page there be a check to determine if cookie sessionID from the client and the sessionID from the server match. If the session is invalid or the cookie sessionID does not match, the user is redirected to the login page.
Cookie Theft
The major concern with keeping a cookie for the sessionID is that a person may determine the sessionID from packet sniffing, leading to possible impersonation of a user. One way around this is to use SSL or TLS which encrypts data going back and forth between the client and server, thus encrypting the cookie. This service is requested of the Web Server which hosts your website.
If anyone has any other thoughts on how to implement security, I would be more than happy to hear it.
Labels:
authentication,
authorization,
ED,
Entity Describer,
OpenID,
security
Subscribe to:
Posts (Atom)