From: don u. <don...@ya...> - 2009-05-27 19:29:21
|
Mostly a question for Yaron, but the broader issue may have more interest. I was checking out the External Data extension, as it seems it could be very useful to us. We've got data in other stores, that we want to be able to reference from within our wiki. Let's say, for example, I've got a page, Category:ArtObject, named 1992.45.34. And we've got an relational database (called MST), that tells me that art object was made by "Fabio Ficasso", Using the External Data extension, I see how I can load the data from our art database, using an API like http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it onto the page accordingly. What we're really after, however, is to go one step beyond that. I'd like to be able to write an ASK query on some other page, that queries, say, for pages of category:ArtObject, which were made by "Fabio Ficasso". So what would need to happen is for that external data to be queried as well. Put another way, we want to be able to use the wiki itself as our data integration point. Insane? You tell me. I'm also looking for any halfway measures that anyone can propose. The External Data extension is itself a huge step towards that halfway point; I'm wondering how much farther we can push it. If I imagined the SMW backend as a literal triple store (instead of a mysql database) supporting remote endpoint queries, I could sort of imagine how the backend to all this could look. Judging from this thread: http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com It seems people don't think much of the idea of replacing the MW backend with a full-fledged triplestore. Am I right? Performance issues (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a triplestore? Performance issues NOT aside, perhaps not so much? Are there some other approaches people have taken to encorporating non-wiki data into their wikis? thanks again, for all your time and hard work. |
From: Brian <Bri...@co...> - 2009-05-27 20:19:25
|
I haven't used this extension yet but I have plans to use it. I think you should consider SMW to be a "cache". If you want to query data in the cache you'll first have to cache it, e.g., load the pages that reference external data and then it will be available for queries. SMW can be considered a convenient, high level interface to your data. It comes with a lot of overhead and won't scale forever. If you plan to use it extensively you'll need to provide just as much, if not more, compute resources to it than to your external data store. Your external store needs memory, SMW needs cpu. On Wed, May 27, 2009 at 1:26 PM, don undeen <don...@ya...> wrote: > > Mostly a question for Yaron, but the broader issue may have more interest. > > I was checking out the External Data extension, as it seems it could be > very useful to us. We've got data in other stores, that we want to be able > to reference from within our wiki. > > Let's say, for example, I've got a page, Category:ArtObject, named > 1992.45.34. And we've got an relational database (called MST), that tells me > that art object was made by "Fabio Ficasso", > > Using the External Data extension, I see how I can load the data from our > art database, using an API like > http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it onto > the page accordingly. > > What we're really after, however, is to go one step beyond that. I'd like > to be able to write an ASK query on some other page, that queries, say, for > pages of category:ArtObject, which were made by "Fabio Ficasso". So what > would need to happen is for that external data to be queried as well. > > Put another way, we want to be able to use the wiki itself as our data > integration point. Insane? You tell me. > > I'm also looking for any halfway measures that anyone can propose. The > External Data extension is itself a huge step towards that halfway point; > I'm wondering how much farther we can push it. > > If I imagined the SMW backend as a literal triple store (instead of a mysql > database) supporting remote endpoint queries, I could sort of imagine how > the backend to all this could look. > Judging from this thread: > > http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com > > It seems people don't think much of the idea of replacing the MW backend > with a full-fledged triplestore. Am I right? Performance issues > (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a > triplestore? Performance issues NOT aside, perhaps not so much? > > Are there some other approaches people have taken to encorporating non-wiki > data into their wikis? > > > thanks again, for all your time and hard work. > > > > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Brian <Bri...@co...> - 2009-05-27 20:20:35
|
(That is just my WAG - I think we would all appreciate if you tested out various solns and let us know what you find!) On Wed, May 27, 2009 at 2:19 PM, Brian <Bri...@co...> wrote: > I haven't used this extension yet but I have plans to use it. > > I think you should consider SMW to be a "cache". If you want to query data > in the cache you'll first have to cache it, e.g., load the pages that > reference external data and then it will be available for queries. > > SMW can be considered a convenient, high level interface to your data. It > comes with a lot of overhead and won't scale forever. If you plan to use it > extensively you'll need to provide just as much, if not more, compute > resources to it than to your external data store. Your external store needs > memory, SMW needs cpu. > > On Wed, May 27, 2009 at 1:26 PM, don undeen <don...@ya...> wrote: > >> >> Mostly a question for Yaron, but the broader issue may have more interest. >> >> I was checking out the External Data extension, as it seems it could be >> very useful to us. We've got data in other stores, that we want to be able >> to reference from within our wiki. >> >> Let's say, for example, I've got a page, Category:ArtObject, named >> 1992.45.34. And we've got an relational database (called MST), that tells me >> that art object was made by "Fabio Ficasso", >> >> Using the External Data extension, I see how I can load the data from our >> art database, using an API like >> http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it >> onto the page accordingly. >> >> What we're really after, however, is to go one step beyond that. I'd like >> to be able to write an ASK query on some other page, that queries, say, for >> pages of category:ArtObject, which were made by "Fabio Ficasso". So what >> would need to happen is for that external data to be queried as well. >> >> Put another way, we want to be able to use the wiki itself as our data >> integration point. Insane? You tell me. >> >> I'm also looking for any halfway measures that anyone can propose. The >> External Data extension is itself a huge step towards that halfway point; >> I'm wondering how much farther we can push it. >> >> If I imagined the SMW backend as a literal triple store (instead of a >> mysql database) supporting remote endpoint queries, I could sort of imagine >> how the backend to all this could look. >> Judging from this thread: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com >> >> It seems people don't think much of the idea of replacing the MW backend >> with a full-fledged triplestore. Am I right? Performance issues >> (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a >> triplestore? Performance issues NOT aside, perhaps not so much? >> >> Are there some other approaches people have taken to encorporating >> non-wiki data into their wikis? >> >> >> thanks again, for all your time and hard work. >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity professionals. >> Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > > |
From: Yaron K. <ya...@gm...> - 2009-05-27 22:01:26
|
I don't think there's anything crazy about using a semantic wiki as a data-integration point; I just wrote a blog post on that topic a few weeks ago. [1] The basic concept is, as Brian suggests, to retrieve data using External Data, then store and query it using SMW. I've seen this done in several places by now, so I know it works; this page on the OpenCongress wiki, for instance, gets its data through such an approach. [2] Performance is, obviously, dependent on the amount of data involved. [1] http://yaronkoren.com/blog/?p=154 [2] http://www.opencongress.org/wiki/Ohio -Yaron On Wed, May 27, 2009 at 4:20 PM, Brian <Bri...@co...> wrote: > (That is just my WAG - I think we would all appreciate if you tested out > various solns and let us know what you find!) > > > On Wed, May 27, 2009 at 2:19 PM, Brian <Bri...@co...> wrote: > >> I haven't used this extension yet but I have plans to use it. >> >> I think you should consider SMW to be a "cache". If you want to query data >> in the cache you'll first have to cache it, e.g., load the pages that >> reference external data and then it will be available for queries. >> >> SMW can be considered a convenient, high level interface to your data. It >> comes with a lot of overhead and won't scale forever. If you plan to use it >> extensively you'll need to provide just as much, if not more, compute >> resources to it than to your external data store. Your external store needs >> memory, SMW needs cpu. >> >> On Wed, May 27, 2009 at 1:26 PM, don undeen <don...@ya...> wrote: >> >>> >>> Mostly a question for Yaron, but the broader issue may have more >>> interest. >>> >>> I was checking out the External Data extension, as it seems it could be >>> very useful to us. We've got data in other stores, that we want to be able >>> to reference from within our wiki. >>> >>> Let's say, for example, I've got a page, Category:ArtObject, named >>> 1992.45.34. And we've got an relational database (called MST), that tells me >>> that art object was made by "Fabio Ficasso", >>> >>> Using the External Data extension, I see how I can load the data from our >>> art database, using an API like >>> http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it >>> onto the page accordingly. >>> >>> What we're really after, however, is to go one step beyond that. I'd like >>> to be able to write an ASK query on some other page, that queries, say, for >>> pages of category:ArtObject, which were made by "Fabio Ficasso". So what >>> would need to happen is for that external data to be queried as well. >>> >>> Put another way, we want to be able to use the wiki itself as our data >>> integration point. Insane? You tell me. >>> >>> I'm also looking for any halfway measures that anyone can propose. The >>> External Data extension is itself a huge step towards that halfway point; >>> I'm wondering how much farther we can push it. >>> >>> If I imagined the SMW backend as a literal triple store (instead of a >>> mysql database) supporting remote endpoint queries, I could sort of imagine >>> how the backend to all this could look. >>> Judging from this thread: >>> >>> http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com >>> >>> It seems people don't think much of the idea of replacing the MW backend >>> with a full-fledged triplestore. Am I right? Performance issues >>> (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a >>> triplestore? Performance issues NOT aside, perhaps not so much? >>> >>> Are there some other approaches people have taken to encorporating >>> non-wiki data into their wikis? >>> >>> >>> thanks again, for all your time and hard work. >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>> is a gathering of tech-side developers & brand creativity professionals. >>> Meet >>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>> iPhoneDevCamp as they present alongside digital heavyweights like >>> Barbarian >>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >> >> > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > |
From: <zeh...@mo...> - 2009-05-28 08:01:38
|
I use in one of my experimental wikis only external data converted to semantic properties (at least at the beginning for seeding the wiki) and than loaded with the python wikipediabot program 'pagefromfile'. I need, however, to take some care that 'related' data bits from the external (XML) data files don't get separated into different properties but end up tied together in multi-value properties to avoid useless property collections. That needs 'domain specific knowledge' in the conversion program. As I use forms to query the semantic properties and store the returned page title lists in specific DB tables before actually displaying the results I can also have forms which query selected external online databases (they need to be able to return the same entities as result which I use as page titles in the wiki) and store the result as if it would have come from the wiki itself (that is used i.e. for data which can be queried online but not downloaded to be integrated into the wiki). For the further steps of combining or displaying results it doesn't matter if a page title list was originally generated by internal or external queries. Gu Quoting don undeen <don...@ya...>: > > Mostly a question for Yaron, but the broader issue may have more interest. > > I was checking out the External Data extension, as it seems it could be very > useful to us. We've got data in other stores, that we want to be able to > reference from within our wiki. > > Let's say, for example, I've got a page, Category:ArtObject, named > 1992.45.34. And we've got an relational database (called MST), that tells me > that art object was made by "Fabio Ficasso", > > Using the External Data extension, I see how I can load the data from our art > database, using an API like > http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it onto > the page accordingly. > > What we're really after, however, is to go one step beyond that. I'd like to > be able to write an ASK query on some other page, that queries, say, for > pages of category:ArtObject, which were made by "Fabio Ficasso". So what > would need to happen is for that external data to be queried as well. > > Put another way, we want to be able to use the wiki itself as our data > integration point. Insane? You tell me. > > I'm also looking for any halfway measures that anyone can propose. The > External Data extension is itself a huge step towards that halfway point; I'm > wondering how much farther we can push it. > > If I imagined the SMW backend as a literal triple store (instead of a mysql > database) supporting remote endpoint queries, I could sort of imagine how the > backend to all this could look. > Judging from this thread: > http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com > > It seems people don't think much of the idea of replacing the MW backend with > a full-fledged triplestore. Am I right? Performance issues (temporarily) > aside, doesn't it seem like a better fit for SMW to sit on a triplestore? > Performance issues NOT aside, perhaps not so much? > > Are there some other approaches people have taken to encorporating non-wiki > data into their wikis? > > > thanks again, for all your time and hard work. > > > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Philipp Z. <zal...@on...> - 2009-05-28 08:59:00
|
Hi Don, I would say using a triple-store as backend instead of the conventional database backend depends on your scenario. At ontoprise, we definitely need a triple-store, since it provides advanced reasoning, e.g. for inverse, transitive and symmetric properties or even complex rules. We use rules e.g. in our internal software development wiki for triggering certain actions upon status changes. Remote querying is also a big plus of a triple store backend, because it allows you to integrate "live data" from SMW into other applications. We provide two triple-store connectors. One for Jena (for free) and one for Ontobroker (commercial). The manual for the Jena triple-store connector can be found at http://smwforum.ontoprise.com/smwforum/index.php/Help:Basic_Triplestore_1.1 The difference between Ontobroker and Jena is that Ontobroker supports rules and scales much better. You can also integrate other data-sources via Ontobroker. Best regards, Philipp don undeen schrieb: > Mostly a question for Yaron, but the broader issue may have more interest. > > I was checking out the External Data extension, as it seems it could be very useful to us. We've got data in other stores, that we want to be able to reference from within our wiki. > > Let's say, for example, I've got a page, Category:ArtObject, named 1992.45.34. And we've got an relational database (called MST), that tells me that art object was made by "Fabio Ficasso", > > Using the External Data extension, I see how I can load the data from our art database, using an API like > http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it onto the page accordingly. > > What we're really after, however, is to go one step beyond that. I'd like to be able to write an ASK query on some other page, that queries, say, for pages of category:ArtObject, which were made by "Fabio Ficasso". So what would need to happen is for that external data to be queried as well. > > Put another way, we want to be able to use the wiki itself as our data integration point. Insane? You tell me. > > I'm also looking for any halfway measures that anyone can propose. The External Data extension is itself a huge step towards that halfway point; I'm wondering how much farther we can push it. > > If I imagined the SMW backend as a literal triple store (instead of a mysql database) supporting remote endpoint queries, I could sort of imagine how the backend to all this could look. > Judging from this thread: > http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com > > It seems people don't think much of the idea of replacing the MW backend with a full-fledged triplestore. Am I right? Performance issues (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a triplestore? Performance issues NOT aside, perhaps not so much? > > Are there some other approaches people have taken to encorporating non-wiki data into their wikis? > > > thanks again, for all your time and hard work. > > > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- Philipp Zaltenbach Professional Services ontoprise GmbH – know how to use Know-how - - - ontoprise presents the new SemanticMiner for SharePoint: http://www.ontoprise.de/en/home/news/news-en/cebit-2009-ontoprise-presents-the-new-semanticminer-for-sharepoint/ - - - An der RaumFabrik 29; 76227 Karlsruhe; Germany phone: +49 721 509809-0; Fax: +49 721 509809-11 mailto:zal...@on..., www: http://www.ontoprise.de Registered office: Karlsruhe, Germany; Register court: Mannheim, HRB 109540 Managing directors: Prof. Dr. Jürgen Angele, Dipl.Wi.-Ing. Hans-Peter Schnurr - - - |
From: Yaron K. <ya...@gm...> - 2009-05-28 14:57:34
|
Don - to clarify, the information retrieved is not stored automatically; instead, you need to store it using an SMW tag. An example might be: [[Created by artist::{{#external_value:Artist}}]] Then you would query on "Created by artist". Caching is an issue - if the value from the API changes, the value stored semantically won't change until it's refreshed manually, either by calling the refreshData script, or resaving that wiki page, or (if you're using a template) resaving the template. -Yaron On Thu, May 28, 2009 at 4:56 AM, Philipp Zaltenbach <zal...@on... > wrote: > Hi Don, > > I would say using a triple-store as backend instead of the conventional > database backend depends on your scenario. > At ontoprise, we definitely need a triple-store, since it provides > advanced reasoning, e.g. for inverse, transitive and symmetric > properties or even complex rules. We use rules e.g. in our internal > software development wiki for triggering certain actions upon status > changes. Remote querying is also a big plus of a triple store backend, > because it allows you to integrate "live data" from SMW into other > applications. > > We provide two triple-store connectors. One for Jena (for free) and one > for Ontobroker (commercial). The manual for the Jena triple-store > connector can be found at > http://smwforum.ontoprise.com/smwforum/index.php/Help:Basic_Triplestore_1.1 > The difference between Ontobroker and Jena is that Ontobroker supports > rules and scales much better. You can also integrate other data-sources > via Ontobroker. > > Best regards, > Philipp > > > don undeen schrieb: > > Mostly a question for Yaron, but the broader issue may have more > interest. > > > > I was checking out the External Data extension, as it seems it could be > very useful to us. We've got data in other stores, that we want to be able > to reference from within our wiki. > > > > Let's say, for example, I've got a page, Category:ArtObject, named > 1992.45.34. And we've got an relational database (called MST), that tells me > that art object was made by "Fabio Ficasso", > > > > Using the External Data extension, I see how I can load the data from our > art database, using an API like > > http://ourmuseum.org/api/getObjectData/1992.45.34 , and then parse it > onto the page accordingly. > > > > What we're really after, however, is to go one step beyond that. I'd like > to be able to write an ASK query on some other page, that queries, say, for > pages of category:ArtObject, which were made by "Fabio Ficasso". So what > would need to happen is for that external data to be queried as well. > > > > Put another way, we want to be able to use the wiki itself as our data > integration point. Insane? You tell me. > > > > I'm also looking for any halfway measures that anyone can propose. The > External Data extension is itself a huge step towards that halfway point; > I'm wondering how much farther we can push it. > > > > If I imagined the SMW backend as a literal triple store (instead of a > mysql database) supporting remote endpoint queries, I could sort of imagine > how the backend to all this could look. > > Judging from this thread: > > > http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com > > > > It seems people don't think much of the idea of replacing the MW backend > with a full-fledged triplestore. Am I right? Performance issues > (temporarily) aside, doesn't it seem like a better fit for SMW to sit on a > triplestore? Performance issues NOT aside, perhaps not so much? > > > > Are there some other approaches people have taken to encorporating > non-wiki data into their wikis? > > > > > > thanks again, for all your time and hard work. > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers & brand creativity professionals. > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing, & > > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > -- > Philipp Zaltenbach > Professional Services > ontoprise GmbH – know how to use Know-how > - - - > ontoprise presents the new SemanticMiner for SharePoint: > > http://www.ontoprise.de/en/home/news/news-en/cebit-2009-ontoprise-presents-the-new-semanticminer-for-sharepoint/ > - - - > An der RaumFabrik 29; 76227 Karlsruhe; Germany > phone: +49 721 509809-0; Fax: +49 721 509809-11 > mailto:zal...@on..., www: http://www.ontoprise.de > Registered office: Karlsruhe, Germany; Register court: Mannheim, HRB > 109540 > Managing directors: Prof. Dr. Jürgen Angele, Dipl.Wi.-Ing. Hans-Peter > Schnurr > - - - > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Ingo S. <ste...@on...> - 2009-05-28 16:40:27
|
Hi, maybe it is a bit too early to announce it here but I think this will fit into your discussion: We are working on a demo Wiki with the purpose to demonstrate some features of our Data Import extension. The demo is far away from being complete and a lot of further work has to be done. But you can already get a feeling of some of the rich features that the Data Import extension provides: * Import data from the Linked Data Cloud as new Wiki articles (i.e. DBPedia and the Semantic CrunchBase SPARQL endpoint) * Enrich your articles with content and features from various web services (i.e. OpenCalais or Amazon AWS) http://diedemo.ontoprise.com/index.php/Main_Page#Introduction kind regards, Ingo Yaron Koren schrieb: > Don - to clarify, the information retrieved is not stored > automatically; instead, you need to store it using an SMW tag. An > example might be: > > [[Created by artist::{{#external_value:Artist}}]] > > Then you would query on "Created by artist". > > Caching is an issue - if the value from the API changes, the value > stored semantically won't change until it's refreshed manually, either > by calling the refreshData script, or resaving that wiki page, or (if > you're using a template) resaving the template. > > -Yaron > > > On Thu, May 28, 2009 at 4:56 AM, Philipp Zaltenbach > <zal...@on... <mailto:zal...@on...>> wrote: > > Hi Don, > > I would say using a triple-store as backend instead of the > conventional > database backend depends on your scenario. > At ontoprise, we definitely need a triple-store, since it provides > advanced reasoning, e.g. for inverse, transitive and symmetric > properties or even complex rules. We use rules e.g. in our internal > software development wiki for triggering certain actions upon status > changes. Remote querying is also a big plus of a triple store backend, > because it allows you to integrate "live data" from SMW into other > applications. > > We provide two triple-store connectors. One for Jena (for free) > and one > for Ontobroker (commercial). The manual for the Jena triple-store > connector can be found at > http://smwforum.ontoprise.com/smwforum/index.php/Help:Basic_Triplestore_1.1 > The difference between Ontobroker and Jena is that Ontobroker supports > rules and scales much better. You can also integrate other > data-sources > via Ontobroker. > > Best regards, > Philipp > > > don undeen schrieb: > > Mostly a question for Yaron, but the broader issue may have more > interest. > > > > I was checking out the External Data extension, as it seems it > could be very useful to us. We've got data in other stores, that > we want to be able to reference from within our wiki. > > > > Let's say, for example, I've got a page, Category:ArtObject, > named 1992.45.34. And we've got an relational database (called > MST), that tells me that art object was made by "Fabio Ficasso", > > > > Using the External Data extension, I see how I can load the data > from our art database, using an API like > > http://ourmuseum.org/api/getObjectData/1992.45.34 , and then > parse it onto the page accordingly. > > > > What we're really after, however, is to go one step beyond that. > I'd like to be able to write an ASK query on some other page, that > queries, say, for pages of category:ArtObject, which were made by > "Fabio Ficasso". So what would need to happen is for that external > data to be queried as well. > > > > Put another way, we want to be able to use the wiki itself as > our data integration point. Insane? You tell me. > > > > I'm also looking for any halfway measures that anyone can > propose. The External Data extension is itself a huge step towards > that halfway point; I'm wondering how much farther we can push it. > > > > If I imagined the SMW backend as a literal triple store (instead > of a mysql database) supporting remote endpoint queries, I could > sort of imagine how the backend to all this could look. > > Judging from this thread: > > > http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com > > > > It seems people don't think much of the idea of replacing the MW > backend with a full-fledged triplestore. Am I right? Performance > issues (temporarily) aside, doesn't it seem like a better fit for > SMW to sit on a triplestore? Performance issues NOT aside, perhaps > not so much? > > > > Are there some other approaches people have taken to > encorporating non-wiki data into their wikis? > > > > > > thanks again, for all your time and hard work. > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers & brand creativity > professionals. Meet > > the minds behind Google Creative Lab, Visual Complexity, > Processing, & > > iPhoneDevCamp as they present alongside digital heavyweights > like Barbarian > > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > > _______________________________________________ > > Semediawiki-user mailing list > > Sem...@li... > <mailto:Sem...@li...> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > -- > Philipp Zaltenbach > Professional Services > ontoprise GmbH – know how to use Know-how > - - - > ontoprise presents the new SemanticMiner for SharePoint: > http://www.ontoprise.de/en/home/news/news-en/cebit-2009-ontoprise-presents-the-new-semanticminer-for-sharepoint/ > - - - > An der RaumFabrik 29; 76227 Karlsruhe; Germany > phone: +49 721 509809-0; Fax: +49 721 509809-11 > mailto:zal...@on... <mailto:zal...@on...>, > www: http://www.ontoprise.de > Registered office: Karlsruhe, Germany; Register court: Mannheim, > HRB 109540 > Managing directors: Prof. Dr. Jürgen Angele, Dipl.Wi.-Ing. > Hans-Peter Schnurr > - - - > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > ------------------------------------------------------------------------ > > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Laurent A. <la...@al...> - 2009-05-29 02:34:20
|
Very nice demo. I was wondering about how to link up to other data sources in this way. Can SMW+ Data Import extension be used independently of SMW+ ? or is it an intricate part of the whole system ? - Laurent On May 28, 2009, at 12:40 PM, Ingo Steinbauer wrote: > Hi, > > maybe it is a bit too early to announce it here but I think this will > fit into your discussion: > > We are working on a demo Wiki with the purpose to demonstrate some > features of our Data Import extension. The demo is far away from being > complete and a lot of further work has to be done. But you can already > get a feeling of some of the rich features that the Data Import > extension provides: > > * Import data from the Linked Data Cloud as new Wiki articles (i.e. > DBPedia and the Semantic CrunchBase SPARQL endpoint) > * Enrich your articles with content and features from various web > services (i.e. OpenCalais or Amazon AWS) > > http://diedemo.ontoprise.com/index.php/Main_Page#Introduction > > kind regards, > Ingo > > Yaron Koren schrieb: >> Don - to clarify, the information retrieved is not stored >> automatically; instead, you need to store it using an SMW tag. An >> example might be: >> >> [[Created by artist::{{#external_value:Artist}}]] >> >> Then you would query on "Created by artist". >> >> Caching is an issue - if the value from the API changes, the value >> stored semantically won't change until it's refreshed manually, >> either >> by calling the refreshData script, or resaving that wiki page, or (if >> you're using a template) resaving the template. >> >> -Yaron >> >> >> On Thu, May 28, 2009 at 4:56 AM, Philipp Zaltenbach >> <zal...@on... <mailto:zal...@on...>> wrote: >> >> Hi Don, >> >> I would say using a triple-store as backend instead of the >> conventional >> database backend depends on your scenario. >> At ontoprise, we definitely need a triple-store, since it provides >> advanced reasoning, e.g. for inverse, transitive and symmetric >> properties or even complex rules. We use rules e.g. in our >> internal >> software development wiki for triggering certain actions upon >> status >> changes. Remote querying is also a big plus of a triple store >> backend, >> because it allows you to integrate "live data" from SMW into other >> applications. >> >> We provide two triple-store connectors. One for Jena (for free) >> and one >> for Ontobroker (commercial). The manual for the Jena triple-store >> connector can be found at >> http://smwforum.ontoprise.com/smwforum/index.php/Help:Basic_Triplestore_1.1 >> The difference between Ontobroker and Jena is that Ontobroker >> supports >> rules and scales much better. You can also integrate other >> data-sources >> via Ontobroker. >> >> Best regards, >> Philipp >> >> >> don undeen schrieb: >>> Mostly a question for Yaron, but the broader issue may have more >> interest. >>> >>> I was checking out the External Data extension, as it seems it >> could be very useful to us. We've got data in other stores, that >> we want to be able to reference from within our wiki. >>> >>> Let's say, for example, I've got a page, Category:ArtObject, >> named 1992.45.34. And we've got an relational database (called >> MST), that tells me that art object was made by "Fabio Ficasso", >>> >>> Using the External Data extension, I see how I can load the data >> from our art database, using an API like >>> http://ourmuseum.org/api/getObjectData/1992.45.34 , and then >> parse it onto the page accordingly. >>> >>> What we're really after, however, is to go one step beyond that. >> I'd like to be able to write an ASK query on some other page, that >> queries, say, for pages of category:ArtObject, which were made by >> "Fabio Ficasso". So what would need to happen is for that external >> data to be queried as well. >>> >>> Put another way, we want to be able to use the wiki itself as >> our data integration point. Insane? You tell me. >>> >>> I'm also looking for any halfway measures that anyone can >> propose. The External Data extension is itself a huge step towards >> that halfway point; I'm wondering how much farther we can push it. >>> >>> If I imagined the SMW backend as a literal triple store (instead >> of a mysql database) supporting remote endpoint queries, I could >> sort of imagine how the backend to all this could look. >>> Judging from this thread: >>> >> http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com >>> >>> It seems people don't think much of the idea of replacing the MW >> backend with a full-fledged triplestore. Am I right? Performance >> issues (temporarily) aside, doesn't it seem like a better fit for >> SMW to sit on a triplestore? Performance issues NOT aside, perhaps >> not so much? >>> >>> Are there some other approaches people have taken to >> encorporating non-wiki data into their wikis? >>> >>> >>> thanks again, for all your time and hard work. >>> >>> >>> >>> >>> >>> >>> >> >> ------------------------------------------------------------------------------ >>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>> is a gathering of tech-side developers & brand creativity >> professionals. Meet >>> the minds behind Google Creative Lab, Visual Complexity, >> Processing, & >>> iPhoneDevCamp as they present alongside digital heavyweights >> like Barbarian >>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >> <mailto:Sem...@li...> >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >> >> -- >> Philipp Zaltenbach >> Professional Services >> ontoprise GmbH – know how to use Know-how >> - - - >> ontoprise presents the new SemanticMiner for SharePoint: >> http://www.ontoprise.de/en/home/news/news-en/cebit-2009-ontoprise-presents-the-new-semanticminer-for-sharepoint/ >> - - - >> An der RaumFabrik 29; 76227 Karlsruhe; Germany >> phone: +49 721 509809-0; Fax: +49 721 509809-11 >> mailto:zal...@on... <mailto:zal...@on...>, >> www: http://www.ontoprise.de >> Registered office: Karlsruhe, Germany; Register court: Mannheim, >> HRB 109540 >> Managing directors: Prof. Dr. Jürgen Angele, Dipl.Wi.-Ing. >> Hans-Peter Schnurr >> - - - >> >> >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. >> CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, >> Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat- >> com >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> <mailto:Sem...@li...> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, >> Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user |
From: Ingo S. <ste...@on...> - 2009-05-29 05:55:20
|
I am very happy that you find it interesting! You can get the the Data Import extension as part of SMW+ with its nice installer and other features. But you can also get it independent of SMW+. The only prerequisites are that you also install the Halo and the Semantic Gardening extensions which both are also available as standalone extensions. This is necessary because the web service update bot (for frequently updating web service results) and the web service cache cleanup bot (for cleaning up outdated cached web service results) of the Data Import extension make use of the Semantic Gardening bot framework. Laurent Alquier schrieb: > Very nice demo. > > I was wondering about how to link up to other data sources in this way. > > Can SMW+ Data Import extension be used independently of SMW+ ? or is > it an intricate part of the whole system ? > > - Laurent > > On May 28, 2009, at 12:40 PM, Ingo Steinbauer wrote: > > >> Hi, >> >> maybe it is a bit too early to announce it here but I think this will >> fit into your discussion: >> >> We are working on a demo Wiki with the purpose to demonstrate some >> features of our Data Import extension. The demo is far away from being >> complete and a lot of further work has to be done. But you can already >> get a feeling of some of the rich features that the Data Import >> extension provides: >> >> * Import data from the Linked Data Cloud as new Wiki articles (i.e. >> DBPedia and the Semantic CrunchBase SPARQL endpoint) >> * Enrich your articles with content and features from various web >> services (i.e. OpenCalais or Amazon AWS) >> >> http://diedemo.ontoprise.com/index.php/Main_Page#Introduction >> >> kind regards, >> Ingo >> >> Yaron Koren schrieb: >> >>> Don - to clarify, the information retrieved is not stored >>> automatically; instead, you need to store it using an SMW tag. An >>> example might be: >>> >>> [[Created by artist::{{#external_value:Artist}}]] >>> >>> Then you would query on "Created by artist". >>> >>> Caching is an issue - if the value from the API changes, the value >>> stored semantically won't change until it's refreshed manually, >>> either >>> by calling the refreshData script, or resaving that wiki page, or (if >>> you're using a template) resaving the template. >>> >>> -Yaron >>> >>> >>> On Thu, May 28, 2009 at 4:56 AM, Philipp Zaltenbach >>> <zal...@on... <mailto:zal...@on...>> wrote: >>> >>> Hi Don, >>> >>> I would say using a triple-store as backend instead of the >>> conventional >>> database backend depends on your scenario. >>> At ontoprise, we definitely need a triple-store, since it provides >>> advanced reasoning, e.g. for inverse, transitive and symmetric >>> properties or even complex rules. We use rules e.g. in our >>> internal >>> software development wiki for triggering certain actions upon >>> status >>> changes. Remote querying is also a big plus of a triple store >>> backend, >>> because it allows you to integrate "live data" from SMW into other >>> applications. >>> >>> We provide two triple-store connectors. One for Jena (for free) >>> and one >>> for Ontobroker (commercial). The manual for the Jena triple-store >>> connector can be found at >>> http://smwforum.ontoprise.com/smwforum/index.php/Help:Basic_Triplestore_1.1 >>> The difference between Ontobroker and Jena is that Ontobroker >>> supports >>> rules and scales much better. You can also integrate other >>> data-sources >>> via Ontobroker. >>> >>> Best regards, >>> Philipp >>> >>> >>> don undeen schrieb: >>> >>>> Mostly a question for Yaron, but the broader issue may have more >>>> >>> interest. >>> >>>> I was checking out the External Data extension, as it seems it >>>> >>> could be very useful to us. We've got data in other stores, that >>> we want to be able to reference from within our wiki. >>> >>>> Let's say, for example, I've got a page, Category:ArtObject, >>>> >>> named 1992.45.34. And we've got an relational database (called >>> MST), that tells me that art object was made by "Fabio Ficasso", >>> >>>> Using the External Data extension, I see how I can load the data >>>> >>> from our art database, using an API like >>> >>>> http://ourmuseum.org/api/getObjectData/1992.45.34 , and then >>>> >>> parse it onto the page accordingly. >>> >>>> What we're really after, however, is to go one step beyond that. >>>> >>> I'd like to be able to write an ASK query on some other page, that >>> queries, say, for pages of category:ArtObject, which were made by >>> "Fabio Ficasso". So what would need to happen is for that external >>> data to be queried as well. >>> >>>> Put another way, we want to be able to use the wiki itself as >>>> >>> our data integration point. Insane? You tell me. >>> >>>> I'm also looking for any halfway measures that anyone can >>>> >>> propose. The External Data extension is itself a huge step towards >>> that halfway point; I'm wondering how much farther we can push it. >>> >>>> If I imagined the SMW backend as a literal triple store (instead >>>> >>> of a mysql database) supporting remote endpoint queries, I could >>> sort of imagine how the backend to all this could look. >>> >>>> Judging from this thread: >>>> >>>> >>> http://sourceforge.net/mailarchive/message.php?msg_id=9984a7a70709231041s16e90db9r7a5cfd2848347e85%40mail.gmail.com >>> >>>> It seems people don't think much of the idea of replacing the MW >>>> >>> backend with a full-fledged triplestore. Am I right? Performance >>> issues (temporarily) aside, doesn't it seem like a better fit for >>> SMW to sit on a triplestore? Performance issues NOT aside, perhaps >>> not so much? >>> >>>> Are there some other approaches people have taken to >>>> >>> encorporating non-wiki data into their wikis? >>> >>>> thanks again, for all your time and hard work. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>> is a gathering of tech-side developers & brand creativity >>>> >>> professionals. Meet >>> >>>> the minds behind Google Creative Lab, Visual Complexity, >>>> >>> Processing, & >>> >>>> iPhoneDevCamp as they present alongside digital heavyweights >>>> >>> like Barbarian >>> >>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >>>> _______________________________________________ >>>> Semediawiki-user mailing list >>>> Sem...@li... >>>> >>> <mailto:Sem...@li...> >>> >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>>> >>>> >>> -- >>> Philipp Zaltenbach >>> Professional Services >>> ontoprise GmbH – know how to use Know-how >>> - - - >>> ontoprise presents the new SemanticMiner for SharePoint: >>> http://www.ontoprise.de/en/home/news/news-en/cebit-2009-ontoprise-presents-the-new-semanticminer-for-sharepoint/ >>> - - - >>> An der RaumFabrik 29; 76227 Karlsruhe; Germany >>> phone: +49 721 509809-0; Fax: +49 721 509809-11 >>> mailto:zal...@on... <mailto:zal...@on...>, >>> www: http://www.ontoprise.de >>> Registered office: Karlsruhe, Germany; Register court: Mannheim, >>> HRB 109540 >>> Managing directors: Prof. Dr. Jürgen Angele, Dipl.Wi.-Ing. >>> Hans-Peter Schnurr >>> - - - >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. >>> CaT >>> is a gathering of tech-side developers & brand creativity >>> professionals. Meet >>> the minds behind Google Creative Lab, Visual Complexity, >>> Processing, & >>> iPhoneDevCamp as they present alongside digital heavyweights like >>> Barbarian >>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat- >>> com >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >>> <mailto:Sem...@li...> >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------------ >>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>> is a gathering of tech-side developers & brand creativity >>> professionals. Meet >>> the minds behind Google Creative Lab, Visual Complexity, >>> Processing, & >>> iPhoneDevCamp as they present alongside digital heavyweights like >>> Barbarian >>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >>> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity >> professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp as they present alongside digital heavyweights like >> Barbarian >> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > |