Re: mind mapping tools for linguistics, semantic web, ICT and KM combined
Maybe you could talk to Kristof, from Pronovix. They're doing interesting stuff (GraphMind) with Drupal + mindmapping for KM. Best, François On Wed, Jun 29, 2011 at 12:33 AM, ProjectParadigm-ICT-Program < metadataport...@yahoo.com> wrote: > I am frantically looking for mind mapping tools which are usable in > linguistics, for semantic web applications, ICT and Knowledge Management in > a combined fashion. > > There is a dizzying array of commercial and freeware products out there. > > Any suggestions which ones best to use? The main objective is development > of open source software for knowledge management and ICT4SD (ICT for > Sustainable Development). > > Milton Ponson > GSM: +297 747 8280 > PO Box 1154, Oranjestad > Aruba, Dutch Caribbean > Project Paradigm: A structured approach to bringing the tools for > sustainable development to all stakeholders worldwide by creating ICT > tools for NGOs worldwide and: providing online access to web sites and > repositories of data and information for sustainable development > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. >
mind mapping tools for linguistics, semantic web, ICT and KM combined
I am frantically looking for mind mapping tools which are usable in linguistics, for semantic web applications, ICT and Knowledge Management in a combined fashion. There is a dizzying array of commercial and freeware products out there. Any suggestions which ones best to use? The main objective is development of open source software for knowledge management and ICT4SD (ICT for Sustainable Development). Milton Ponson GSM: +297 747 8280 PO Box 1154, Oranjestad Aruba, Dutch Caribbean Project Paradigm: A structured approach to bringing the tools for sustainable development to all stakeholders worldwide by creating ICT tools for NGOs worldwide and: providing online access to web sites and repositories of data and information for sustainable development This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
survey about provenance
<> The W3C Provenance Working Group [1] is working on defining a standard for provenance. The group is conducting a survey [2] to identify and connect with potential implementation stakeholders and coordinate test case development and implementation activities. If you or your organisation is developing software that might be interested in implementing (ie. generating, reading or querying) the W3C Provenance standard, the group would be grateful if you could complete this survey: http://goo.gl/rHxAg [1] http://www.w3.org/2011/prov/ [2] http://goo.gl/rHxAg Best Regards, Helena F. Deus Post-doctoral Researcher Digital Enterprise Research Institute National University of Ireland, Galway http://lenadeus.info
Re: HTTP status for timed-out SPARQL query
Thanks everyone for the advice. We'll go with 503. On 28 Jun 2011, at 11:28, Michael Hausenblas wrote: > > >> Seriously, I think that >> 413 Request Entity Too Large >> >> would be a good solution: > > > I disagree. Just checked back w/ colleagues on the #rest IRC channel, they > also agree with 503. > > Cheers, > Michael > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 28 Jun 2011, at 11:10, Martin Hepp wrote: > >>> >>> Looking for some advice from the community. If we time out a slow-running >>> SPARQL query, what is the most appropriate HTTP status code to return to >>> the client? We had been trying 408, but the problem with that is that some >>> clients (notably Firefox) take it on themselves to keep retrying the >>> request, which isn't really what we want. >>> >>> Should we be returning 500 instead? >> >> What about >> 402 Payment Required? >> >> ;-) >> >> Seriously, I think that >> 413 Request Entity Too Large >> >> would be a good solution: >> >> "The server is refusing to process a request because the request entity is >> larger than the server is willing or able to process. The server MAY close >> the connection to prevent the client from continuing the request. >> >> If the condition is temporary, the server SHOULD include a Retry- After >> header field to indicate that it is temporary and after what time the client >> MAY try again." >> >> 500 Internal Server Error was also my first guess, but this may not stop >> clients from trying again. >> >> Martin >> >> On Jun 28, 2011, at 8:21 AM, Bill Roberts wrote: >> >>> Looking for some advice from the community. If we time out a slow-running >>> SPARQL query, what is the most appropriate HTTP status code to return to >>> the client? We had been trying 408, but the problem with that is that some >>> clients (notably Firefox) take it on themselves to keep retrying the >>> request, which isn't really what we want. >>> >>> Should we be returning 500 instead? >>> >>> Thanks >>> >>> Bill >>> >>> >> >> >
Re: HTTP status for timed-out SPARQL query
Seriously, I think that 413 Request Entity Too Large would be a good solution: I disagree. Just checked back w/ colleagues on the #rest IRC channel, they also agree with 503. Cheers, Michael -- Dr. Michael Hausenblas, Research Fellow LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html On 28 Jun 2011, at 11:10, Martin Hepp wrote: Looking for some advice from the community. If we time out a slow- running SPARQL query, what is the most appropriate HTTP status code to return to the client? We had been trying 408, but the problem with that is that some clients (notably Firefox) take it on themselves to keep retrying the request, which isn't really what we want. Should we be returning 500 instead? What about 402 Payment Required? ;-) Seriously, I think that 413 Request Entity Too Large would be a good solution: "The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again." 500 Internal Server Error was also my first guess, but this may not stop clients from trying again. Martin On Jun 28, 2011, at 8:21 AM, Bill Roberts wrote: Looking for some advice from the community. If we time out a slow- running SPARQL query, what is the most appropriate HTTP status code to return to the client? We had been trying 408, but the problem with that is that some clients (notably Firefox) take it on themselves to keep retrying the request, which isn't really what we want. Should we be returning 500 instead? Thanks Bill
Re: HTTP status for timed-out SPARQL query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/06/11 11:10, Martin Hepp wrote: > Seriously, I think that >413 Request Entity Too Large > > would be a good solution: AIUI, 413 is when the request entity (i.e. headers and body) is too large (e.g. when uploading a massive file), not that the request conveyed by the request entity is too onerous. Yours, Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4JqvYACgkQS0pRIabRbjDXUwCeLUa0YoMEu0+g2P8S+DWDMeoD +1wAn1jq/RvnQq0bSk8QVPiH/DpaIwwI =6cbo -END PGP SIGNATURE-
Re: HTTP status for timed-out SPARQL query
> > Looking for some advice from the community. If we time out a slow-running > SPARQL query, what is the most appropriate HTTP status code to return to the > client? We had been trying 408, but the problem with that is that some > clients (notably Firefox) take it on themselves to keep retrying the request, > which isn't really what we want. > > Should we be returning 500 instead? What about 402 Payment Required? ;-) Seriously, I think that 413 Request Entity Too Large would be a good solution: "The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again." 500 Internal Server Error was also my first guess, but this may not stop clients from trying again. Martin On Jun 28, 2011, at 8:21 AM, Bill Roberts wrote: > Looking for some advice from the community. If we time out a slow-running > SPARQL query, what is the most appropriate HTTP status code to return to the > client? We had been trying 408, but the problem with that is that some > clients (notably Firefox) take it on themselves to keep retrying the request, > which isn't really what we want. > > Should we be returning 500 instead? > > Thanks > > Bill > >
Re: HTTP status for timed-out SPARQL query
I suck ... On 28 Jun 2011, at 10:38, Mischa Tuffield wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > On 28 Jun 2011, at 07:46, Michael Hausenblas wrote: > >> >>> Should we be returning 500 instead? >> >> Yes. To be more concise, I'd think that 503 [1] is appropriate. A 4xx is not >> appropriate IMHO, because [2]: >> >> [[ >> The 4xx class of status code is intended for cases in which the client seems >> to have erred. >> ]] > > Indeed 503 seems like the right thing™ to use, Yahoo's response codes may be > a good place to look at an implementation of a webservice. And here is the link to the BOSS documentation : http://developer.yahoo.com/search/boss/boss_api_guide/BOSSv2_FAQ.html Mischa > > Mischa > >> Cheers, >> Michael >> >> [1] http://tools.ietf.org/html/rfc2616#section-10.5.4 >> [2] http://tools.ietf.org/html/rfc2616#section-10.4 >> -- >> Dr. Michael Hausenblas, Research Fellow >> LiDRC - Linked Data Research Centre >> DERI - Digital Enterprise Research Institute >> NUIG - National University of Ireland, Galway >> Ireland, Europe >> Tel. +353 91 495730 >> http://linkeddata.deri.ie/ >> http://sw-app.org/about.html >> >> On 28 Jun 2011, at 07:21, Bill Roberts wrote: >> >>> Looking for some advice from the community. If we time out a slow-running >>> SPARQL query, what is the most appropriate HTTP status code to return to >>> the client? We had been trying 408, but the problem with that is that some >>> clients (notably Firefox) take it on themselves to keep retrying the >>> request, which isn't really what we want. >>> >>> Should we be returning 500 instead? >>> >>> Thanks >>> >>> Bill >>> >>> >> >> > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.12 (Darwin) > > iQIcBAEBAgAGBQJOCaEcAAoJEJ7QsE5R8vfvFwMP/0sC4MItGAXaGEfr6FvDuauo > WcvPTmZPVkaZQqjCaHGrk5h1nLotuV0/yirAN5wEaibUdKDBbQbmOqSqjvspvIGS > YXuH6wvB7jze4odwxl5M7Vae6/9MBODYeRiHGh46LZreSzGw0km50SQltozNZ93D > O6VAIq/bfOpGdYB4FpRqNhhNr120pd6HRx+zzUTL/naLkYek/BI6Tj23jwrBiiSd > DxQNOEeAA4VzvAhWU5hBloDtU3b5aSMgXr0k3Spkorj0/3ayZg2Zk+P00POMHHiz > W1fh5puV16SNSPQZtA9yD4gJxjrjSJoKgzdNq2MPcveurYrCosm4mRrLcBy4AV76 > FLVOy7NLax274Poptsvix9uRcdYnTnhpfTZv0sdT8hTNQmhJtvdBO4PLtUPIvyOA > 7XP1Oe6JleZ+I8e4KOakuzLjosmeeiNY/ZdOVSWyzRzKowlrG5ftn5hNMt7csDp+ > mHt87587vqMuIzyc7TfEdUUM1d3hwQI1uI2oBgWzNZ1PjpEyjLxgFq1UXtLwM0PC > 1PVNA8dRjqwmywdMzsIF0DE2EiSCUjNcnNxMBHH7W7+dLPDzSq6+egcwuO9KMqP8 > nZMnB5vaTGFydvuMb5jaWkuTUCjuuSRFr/du1gSmiEmRjnMKe70uyhJ0SWljVz67 > mP3Lft5SnUQPmcK+GKXS > =vPwh > -END PGP SIGNATURE- > PGP.sig Description: This is a digitally signed message part
Re: HTTP status for timed-out SPARQL query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 28 Jun 2011, at 07:46, Michael Hausenblas wrote: > >> Should we be returning 500 instead? > > Yes. To be more concise, I'd think that 503 [1] is appropriate. A 4xx is not > appropriate IMHO, because [2]: > > [[ > The 4xx class of status code is intended for cases in which the client seems > to have erred. > ]] Indeed 503 seems like the right thing™ to use, Yahoo's response codes may be a good place to look at an implementation of a webservice. Mischa > Cheers, > Michael > > [1] http://tools.ietf.org/html/rfc2616#section-10.5.4 > [2] http://tools.ietf.org/html/rfc2616#section-10.4 > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 28 Jun 2011, at 07:21, Bill Roberts wrote: > >> Looking for some advice from the community. If we time out a slow-running >> SPARQL query, what is the most appropriate HTTP status code to return to the >> client? We had been trying 408, but the problem with that is that some >> clients (notably Firefox) take it on themselves to keep retrying the >> request, which isn't really what we want. >> >> Should we be returning 500 instead? >> >> Thanks >> >> Bill >> >> > > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) iQIcBAEBAgAGBQJOCaEcAAoJEJ7QsE5R8vfvFwMP/0sC4MItGAXaGEfr6FvDuauo WcvPTmZPVkaZQqjCaHGrk5h1nLotuV0/yirAN5wEaibUdKDBbQbmOqSqjvspvIGS YXuH6wvB7jze4odwxl5M7Vae6/9MBODYeRiHGh46LZreSzGw0km50SQltozNZ93D O6VAIq/bfOpGdYB4FpRqNhhNr120pd6HRx+zzUTL/naLkYek/BI6Tj23jwrBiiSd DxQNOEeAA4VzvAhWU5hBloDtU3b5aSMgXr0k3Spkorj0/3ayZg2Zk+P00POMHHiz W1fh5puV16SNSPQZtA9yD4gJxjrjSJoKgzdNq2MPcveurYrCosm4mRrLcBy4AV76 FLVOy7NLax274Poptsvix9uRcdYnTnhpfTZv0sdT8hTNQmhJtvdBO4PLtUPIvyOA 7XP1Oe6JleZ+I8e4KOakuzLjosmeeiNY/ZdOVSWyzRzKowlrG5ftn5hNMt7csDp+ mHt87587vqMuIzyc7TfEdUUM1d3hwQI1uI2oBgWzNZ1PjpEyjLxgFq1UXtLwM0PC 1PVNA8dRjqwmywdMzsIF0DE2EiSCUjNcnNxMBHH7W7+dLPDzSq6+egcwuO9KMqP8 nZMnB5vaTGFydvuMb5jaWkuTUCjuuSRFr/du1gSmiEmRjnMKe70uyhJ0SWljVz67 mP3Lft5SnUQPmcK+GKXS =vPwh -END PGP SIGNATURE-
Re: Another prosecution-for-linking case
On 6/28/11 8:31 AM, Henry S. Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's the misleading part of the Guardian article [1]: "The (computer) server was not based in the US at all," O'Dwyer's barrister, Ben Cooper, who has also been heavily involved in the McKinnon case, told Tuesday's hearing at Westminster magistrates court. "Mr O'Dwyer did not have copyrighted material on his website; _he simply provided a link_. The essential contention is that the correct forum for this trial is in fact here in Britain, where he was at all times." Some experts on digital law question whether _providing links to illegal downloads rather than directly hosting them_ would even constitute an offence in the UK. In February last year charges involving fraud and copyright against a similar site, TV-Links, were dismissed after a judge ruled that linking alone was not illegal. (emphasis added) So the _three_-way distinction, between linking/embedding/hosting, is just not understood. . . ht [1] http://www.guardian.co.uk/law/2011/jun/17/student-file-sharing-tvshack-extradition - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFOCYNOkjnJixAXWBoRAhTSAJ4/Efjv3raW4CKEn9yWJQS1ZmBCPQCfa2SJ H/pNIQQIKNJqw5BdgfaPEvI= =Fl2a -END PGP SIGNATURE- Henry, I am copying in the LOD mailing list as this is quite important and ultimately bring clarity to a confusing matter, even in the Linked Data realm. Links are Links i.e, reference. The Name and Address matter continues to charge on. Referring to something by Name is not the same thing as making a New Address for a Resource. When you make New Resource Addresses (or Locators) where the "authority" part is changed, you open up vulnerabilities of the kind expressed in the misledaing Guardian article. -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
