From: Yaron K. <ya...@gm...> - 2009-10-09 20:08:03
|
Hi, Can you clarify what it is that you're trying to do? You said that you wanted to turn SMW into a CMS (it already is one, of course, but it certainly could be a nicer one), but then you mentioned using "images from our CMS". Where are these images coming from? And what features, if any, do you want to add besides external-image integration? -Yaron On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L < Kar...@pn...> wrote: > Hi, > > We are interested in augmenting SMW/MW to have a more sophisticated content > management capability so that it can act as a Content Management System > (CMS) with great wiki features. Our approach so far has been to generate a > façade page for every document/collection that gets loaded into the CMS. > These façade pages are essentially metadata pages that contain semantic > markup about the contents of the files. They also support normal directory > navigation. I’m trying to get a handle on the best way to change the > existing SMW code and extensions so that they “know” about our files. I > hope you can offer some advice. > > As a first example, I’m looking at modifying the semantic gallery so that > it can display images from our CMS. The semantic markup that we add to each > file facade includes properties for mimetype and a reference to the actual > file. But I don’t want the ask query writer to think about such things so I > would expect a normal image gallery query to be supplied. That implies that > in my output formatter, I would get hits on the image façade pages and have > to do two things: > > 1. for a page hit, ask for more data about the page (additional > properties we have added (mimetype,fileuri)) > 2. somehow replace some of the filerepo code to be able to locate files > > > The latter is more of a MW issue I believe. But for the 1st item, the > documentation says to use the SMW Store api. However I notice that most > extension code uses direct DB calls. Is it still the case that I should be > using the Store API? I have started down this path as it seems like the > correct thing to do. > > I have tried to use the Store API like this: > $data = smwfGetStore()->getSemanticData($title); > $properties = $data->getProperties(); > foreach ($properties as $property) { > $rv = $property->getWikiValue(); > //$proptext = $property->getLongHTMLText($skin); > $values = $data->getPropertyValues($property); > $count = count($values); > foreach ($values as $value) { > $valu = $value->getShortWikiText(); > } > > What I’m getting back is the modification time and an initial category I > used for the page. I added more properties and another category and they > don’t show up in the query result but they do show up in an ask query. I > tried to update the cache with a action=purge > > Am I approaching this wrong or using the wrong method? We are using the > HaloStore2 I believe but the method is implemented in sqlstore2. I have not > sifted through all that code but at first glance, it looks like its looking > for a well-defined set of properties. Is that correct? > > Any pointers greatly appreciated. > > Karen > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Schuchardt, K. L <Kar...@pn...> - 2009-10-09 20:26:54
|
Hi Yaron, We want a CMS that versions file sets (not just individual files), provides the normal hierarchical file structure people are familiar with (not just namespaces), and then we want to make views of the content based on both the collection hierarchy and semantic queries for metadata we extract from files. Ideally, we want the best of something like MW and Plone which provides flexible views of content. In addition to the image gallery, we plan to integrate different types of custom viewers along the lines of the gnu plot extension, statistical operations on data etc. Basically we want to be able to plug in a range of data operations on the server side. The number of files will be large and some of the files will be large. We also plan on providing provenance information between files or collections of files. The data is scientific data. Some ascii, some binary. Lots of different formats. The images and other data will effectively be located on the server in a normal file structure so that MW/SMW can easily access it though it might be deposited through other means than the wiki. We currently have a wiki upload extension that takes a zip file, unzips it, add the data to the CMS, and generates the façade pages. Command lines tools for doing this same thing will also exist. Now we are investigating how to integrate it more deeply in the wiki presentation. Does that answer your question? We really think this could be a powerful capability for collaborative science but are in the infancy of figuring out what it would really take to do it well. Any suggestions or information will be very helpful to us. Karen On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm...> wrote: > Hi, > > Can you clarify what it is that you're trying to do? You said that you wanted > to turn SMW into a CMS (it already is one, of course, but it certainly could > be a nicer one), but then you mentioned using "images from our CMS". Where are > these images coming from? And what features, if any, do you want to add > besides external-image integration? > > -Yaron > > > On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L <Kar...@pn...> > wrote: >> Hi, >> >> We are interested in augmenting SMW/MW to have a more sophisticated content >> management capability so that it can act as a Content Management System (CMS) >> with great wiki features. Our approach so far has been to generate a façade >> page for every document/collection that gets loaded into the CMS. These >> façade pages are essentially metadata pages that contain semantic markup >> about the contents of the files. They also support normal directory >> navigation. I¹m trying to get a handle on the best way to change the >> existing SMW code and extensions so that they ³know² about our files. I hope >> you can offer some advice. >> >> As a first example, I¹m looking at modifying the semantic gallery so that it >> can display images from our CMS. The semantic markup that we add to each >> file facade includes properties for mimetype and a reference to the actual >> file. But I don¹t want the ask query writer to think about such things so I >> would expect a normal image gallery query to be supplied. That implies that >> in my output formatter, I would get hits on the image façade pages and have >> to do two things: >> 1. for a page hit, ask for more data about the page (additional properties we >> have added (mimetype,fileuri)) >> 2. somehow replace some of the filerepo code to be able to locate files >> >> The latter is more of a MW issue I believe. But for the 1st item, the >> documentation says to use the SMW Store api. However I notice that most >> extension code uses direct DB calls. Is it still the case that I should be >> using the Store API? I have started down this path as it seems like the >> correct thing to do. >> >> I have tried to use the Store API like this: >> $data = smwfGetStore()->getSemanticData($title); >> $properties = $data->getProperties(); >> foreach ($properties as $property) { >> $rv = $property->getWikiValue(); >> //$proptext = $property->getLongHTMLText($skin); >> $values = $data->getPropertyValues($property); >> $count = count($values); >> foreach ($values as $value) { >> $valu = $value->getShortWikiText(); >> } >> >> What I¹m getting back is the modification time and an initial category I used >> for the page. I added more properties and another category and they don¹t >> show up in the query result but they do show up in an ask query. I tried to >> update the cache with a action=purge >> >> Am I approaching this wrong or using the wrong method? We are using the >> HaloStore2 I believe but the method is implemented in sqlstore2. I have not >> sifted through all that code but at first glance, it looks like its looking >> for a well-defined set of properties. Is that correct? >> >> Any pointers greatly appreciated. >> >> Karen >> >> >> ----------------------------------------------------------------------------->> - >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > |
From: Yaron K. <ya...@gm...> - 2009-10-09 21:16:16
|
Hi, The concept of MediaWiki supporting a hierarchical file structure, although it (a) seems like it might be a rather dramatic change to MW, requiring a lot of low-level changes, and (b) seems only tangentially related to SMW. Sure, you might want to have a new special property or two, along the lines of "Modification date", but that's not really the core issue. With that said, maybe there are less dramatic, more lightweight solutions to get at the same issue. For instance, if a CMS like Plone already supports file versioning of the kind that you require, maybe it's possible to have a lightweight extension, akin to External Data, that can (a) display an image/file from that CMS, (b) retrieve other data about that file, that can then be stored via SMW, and (c) link the user to the CMS's interface for dealing with that file. It could be called "External Files", perhaps... any thoughts? -Yaron On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L < Kar...@pn...> wrote: > Hi Yaron, > > We want a CMS that versions file sets (not just individual files), provides > the normal hierarchical file structure people are familiar with (not just > namespaces), and then we want to make views of the content based on both the > collection hierarchy and semantic queries for metadata we extract from > files. Ideally, we want the best of something like MW and Plone which > provides flexible views of content. > > In addition to the image gallery, we plan to integrate different types of > custom viewers along the lines of the gnu plot extension, statistical > operations on data etc. Basically we want to be able to plug in a range of > data operations on the server side. > > The number of files will be large and some of the files will be large. We > also plan on providing provenance information between files or collections > of files. The data is scientific data. Some ascii, some binary. Lots of > different formats. > > The images and other data will effectively be located on the server in a > normal file structure so that MW/SMW can easily access it though it might be > deposited through other means than the wiki. We currently have a wiki > upload extension that takes a zip file, unzips it, add the data to the CMS, > and generates the façade pages. Command lines tools for doing this same > thing will also exist. Now we are investigating how to integrate it more > deeply in the wiki presentation. > > Does that answer your question? We really think this could be a powerful > capability for collaborative science but are in the infancy of figuring out > what it would really take to do it well. Any suggestions or information > will be very helpful to us. > > Karen > > > > On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm...> wrote: > > Hi, > > Can you clarify what it is that you're trying to do? You said that you > wanted to turn SMW into a CMS (it already is one, of course, but it > certainly could be a nicer one), but then you mentioned using "images from > our CMS". Where are these images coming from? And what features, if any, do > you want to add besides external-image integration? > > -Yaron > > > On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L < > Kar...@pn...> wrote: > > Hi, > > We are interested in augmenting SMW/MW to have a more sophisticated content > management capability so that it can act as a Content Management System > (CMS) with great wiki features. Our approach so far has been to generate a > façade page for every document/collection that gets loaded into the CMS. > These façade pages are essentially metadata pages that contain semantic > markup about the contents of the files. They also support normal directory > navigation. I’m trying to get a handle on the best way to change the > existing SMW code and extensions so that they “know” about our files. I > hope you can offer some advice. > > As a first example, I’m looking at modifying the semantic gallery so that > it can display images from our CMS. The semantic markup that we add to each > file facade includes properties for mimetype and a reference to the actual > file. But I don’t want the ask query writer to think about such things so I > would expect a normal image gallery query to be supplied. That implies that > in my output formatter, I would get hits on the image façade pages and have > to do two things: > > 1. for a page hit, ask for more data about the page (additional > properties we have added (mimetype,fileuri)) > 2. somehow replace some of the filerepo code to be able to locate files > > > The latter is more of a MW issue I believe. But for the 1st item, the > documentation says to use the SMW Store api. However I notice that most > extension code uses direct DB calls. Is it still the case that I should be > using the Store API? I have started down this path as it seems like the > correct thing to do. > > I have tried to use the Store API like this: > $data = smwfGetStore()->getSemanticData($title); > $properties = $data->getProperties(); > foreach ($properties as $property) { > $rv = $property->getWikiValue(); > //$proptext = $property->getLongHTMLText($skin); > $values = $data->getPropertyValues($property); > $count = count($values); > foreach ($values as $value) { > $valu = $value->getShortWikiText(); > } > > What I’m getting back is the modification time and an initial category I > used for the page. I added more properties and another category and they > don’t show up in the query result but they do show up in an ask query. I > tried to update the cache with a action=purge > > Am I approaching this wrong or using the wrong method? We are using the > HaloStore2 I believe but the method is implemented in sqlstore2. I have not > sifted through all that code but at first glance, it looks like its looking > for a well-defined set of properties. Is that correct? > > Any pointers greatly appreciated. > > Karen > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > |
From: Yaron K. <ya...@gm...> - 2009-10-09 21:17:07
|
Oops, I meant to write "the concept of MediaWiki supporting a hierarchical file structure is interesting". On Fri, Oct 9, 2009 at 5:16 PM, Yaron Koren <ya...@gm...> wrote: > Hi, > The concept of MediaWiki supporting a hierarchical file structure, although > it (a) seems like it might be a rather dramatic change to MW, requiring a > lot of low-level changes, and (b) seems only tangentially related to SMW. > Sure, you might want to have a new special property or two, along the lines > of "Modification date", but that's not really the core issue. > > With that said, maybe there are less dramatic, more lightweight solutions > to get at the same issue. For instance, if a CMS like Plone already supports > file versioning of the kind that you require, maybe it's possible to have a > lightweight extension, akin to External Data, that can (a) display an > image/file from that CMS, (b) retrieve other data about that file, that can > then be stored via SMW, and (c) link the user to the CMS's interface for > dealing with that file. It could be called "External Files", perhaps... any > thoughts? > > -Yaron > > > On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L < > Kar...@pn...> wrote: > >> Hi Yaron, >> >> We want a CMS that versions file sets (not just individual files), >> provides the normal hierarchical file structure people are familiar with >> (not just namespaces), and then we want to make views of the content based >> on both the collection hierarchy and semantic queries for metadata we >> extract from files. Ideally, we want the best of something like MW and >> Plone which provides flexible views of content. >> >> In addition to the image gallery, we plan to integrate different types of >> custom viewers along the lines of the gnu plot extension, statistical >> operations on data etc. Basically we want to be able to plug in a range of >> data operations on the server side. >> >> The number of files will be large and some of the files will be large. We >> also plan on providing provenance information between files or collections >> of files. The data is scientific data. Some ascii, some binary. Lots of >> different formats. >> >> The images and other data will effectively be located on the server in a >> normal file structure so that MW/SMW can easily access it though it might be >> deposited through other means than the wiki. We currently have a wiki >> upload extension that takes a zip file, unzips it, add the data to the CMS, >> and generates the façade pages. Command lines tools for doing this same >> thing will also exist. Now we are investigating how to integrate it more >> deeply in the wiki presentation. >> >> Does that answer your question? We really think this could be a powerful >> capability for collaborative science but are in the infancy of figuring out >> what it would really take to do it well. Any suggestions or information >> will be very helpful to us. >> >> Karen >> >> >> >> On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm...> wrote: >> >> Hi, >> >> Can you clarify what it is that you're trying to do? You said that you >> wanted to turn SMW into a CMS (it already is one, of course, but it >> certainly could be a nicer one), but then you mentioned using "images from >> our CMS". Where are these images coming from? And what features, if any, do >> you want to add besides external-image integration? >> >> -Yaron >> >> >> On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L < >> Kar...@pn...> wrote: >> >> Hi, >> >> We are interested in augmenting SMW/MW to have a more sophisticated >> content management capability so that it can act as a Content Management >> System (CMS) with great wiki features. Our approach so far has been to >> generate a façade page for every document/collection that gets loaded into >> the CMS. These façade pages are essentially metadata pages that contain >> semantic markup about the contents of the files. They also support normal >> directory navigation. I’m trying to get a handle on the best way to change >> the existing SMW code and extensions so that they “know” about our files. I >> hope you can offer some advice. >> >> As a first example, I’m looking at modifying the semantic gallery so that >> it can display images from our CMS. The semantic markup that we add to each >> file facade includes properties for mimetype and a reference to the actual >> file. But I don’t want the ask query writer to think about such things so I >> would expect a normal image gallery query to be supplied. That implies that >> in my output formatter, I would get hits on the image façade pages and have >> to do two things: >> >> 1. for a page hit, ask for more data about the page (additional >> properties we have added (mimetype,fileuri)) >> 2. somehow replace some of the filerepo code to be able to locate >> files >> >> >> The latter is more of a MW issue I believe. But for the 1st item, the >> documentation says to use the SMW Store api. However I notice that most >> extension code uses direct DB calls. Is it still the case that I should be >> using the Store API? I have started down this path as it seems like the >> correct thing to do. >> >> I have tried to use the Store API like this: >> $data = smwfGetStore()->getSemanticData($title); >> $properties = $data->getProperties(); >> foreach ($properties as $property) { >> $rv = $property->getWikiValue(); >> //$proptext = $property->getLongHTMLText($skin); >> $values = $data->getPropertyValues($property); >> $count = count($values); >> foreach ($values as $value) { >> $valu = $value->getShortWikiText(); >> } >> >> What I’m getting back is the modification time and an initial category I >> used for the page. I added more properties and another category and they >> don’t show up in the query result but they do show up in an ask query. I >> tried to update the cache with a action=purge >> >> Am I approaching this wrong or using the wrong method? We are using the >> HaloStore2 I believe but the method is implemented in sqlstore2. I have not >> sifted through all that code but at first glance, it looks like its looking >> for a well-defined set of properties. Is that correct? >> >> Any pointers greatly appreciated. >> >> Karen >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> >> >> > |
From: Schuchardt, K. L <Kar...@pn...> - 2009-10-09 21:40:37
|
We are looking for a lightweight solution to prove the concept. Right now the CMS back end we have doesn¹t have a user interface. By the way, we looked at Plone initially and liked it for several reasons but there were some hurdles that we just didn¹t want to try to take on. MW/SMW have lots of nice displays too, just not anything revolving around collections. I¹m not familiar with External Store but am now looking at the code. I¹ll have to look and see how its used. I assume that ³data² in this case refers to files/content since there is an http implementation. Can this be used in conjunction with the filerep classes? If so, it sounds promising. I too am concerned that it might require a lot of low level changes but am hoping to find a good/clean way. In looking at the semantic image gallery, it uses the ImageGallery class. Image pages are added to to the image gallery based on hits from the query and these are represented as File objects with methods to get thumbnails and so forth. So a mechanism to generate File objects that can point to our data and provide all the normal behavior would seem to be one way to minimize the amount of code that has to be modified. Perhaps we could have a special File subclass that knows about our repository but I¹m not sure how/where to hook something like that in. It might become more clear if I look at how ExternalStore is used. Does that make sense? Any overview documentation on filerep and the various storage dirs/classes would be helpful if you are aware of any. Revisiting my original question, is the Store API the right thing to use for my queries and if so, any idea why I was not getting all the data I was expecting. Karen On 10/9/09 2:16 PM, "Yaron Koren" <ya...@gm...> wrote: > Hi, > > The concept of MediaWiki supporting a hierarchical file structure, although it > (a) seems like it might be a rather dramatic change to MW, requiring a lot of > low-level changes, and (b) seems only tangentially related to SMW. Sure, you > might want to have a new special property or two, along the lines of > "Modification date", but that's not really the core issue. > > With that said, maybe there are less dramatic, more lightweight solutions to > get at the same issue. For instance, if a CMS like Plone already supports file > versioning of the kind that you require, maybe it's possible to have a > lightweight extension, akin to External Data, that can (a) display an > image/file from that CMS, (b) retrieve other data about that file, that can > then be stored via SMW, and (c) link the user to the CMS's interface for > dealing with that file. It could be called "External Files", perhaps... any > thoughts? > > -Yaron > > > On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L <Kar...@pn...> > wrote: >> Hi Yaron, >> >> We want a CMS that versions file sets (not just individual files), provides >> the normal hierarchical file structure people are familiar with (not just >> namespaces), and then we want to make views of the content based on both the >> collection hierarchy and semantic queries for metadata we extract from files. >> Ideally, we want the best of something like MW and Plone which provides >> flexible views of content. >> >> In addition to the image gallery, we plan to integrate different types of >> custom viewers along the lines of the gnu plot extension, statistical >> operations on data etc. Basically we want to be able to plug in a range of >> data operations on the server side. >> >> The number of files will be large and some of the files will be large. We >> also plan on providing provenance information between files or collections of >> files. The data is scientific data. Some ascii, some binary. Lots of >> different formats. >> >> The images and other data will effectively be located on the server in a >> normal file structure so that MW/SMW can easily access it though it might be >> deposited through other means than the wiki. We currently have a wiki upload >> extension that takes a zip file, unzips it, add the data to the CMS, and >> generates the façade pages. Command lines tools for doing this same thing >> will also exist. Now we are investigating how to integrate it more deeply in >> the wiki presentation. >> >> Does that answer your question? We really think this could be a powerful >> capability for collaborative science but are in the infancy of figuring out >> what it would really take to do it well. Any suggestions or information will >> be very helpful to us. >> >> Karen >> >> >> >> On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm... >> <http://ya...@gm...> > wrote: >> >>> Hi, >>> >>> Can you clarify what it is that you're trying to do? You said that you >>> wanted to turn SMW into a CMS (it already is one, of course, but it >>> certainly could be a nicer one), but then you mentioned using "images from >>> our CMS". Where are these images coming from? And what features, if any, do >>> you want to add besides external-image integration? >>> >>> -Yaron >>> >>> >>> On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L >>> <Kar...@pn... <http://Kar...@pn...> > wrote: >>>> Hi, >>>> >>>> We are interested in augmenting SMW/MW to have a more sophisticated content >>>> management capability so that it can act as a Content Management System >>>> (CMS) with great wiki features. Our approach so far has been to generate a >>>> façade page for every document/collection that gets loaded into the CMS. >>>> These façade pages are essentially metadata pages that contain semantic >>>> markup about the contents of the files. They also support normal directory >>>> navigation. I¹m trying to get a handle on the best way to change the >>>> existing SMW code and extensions so that they ³know² about our files. I >>>> hope you can offer some advice. >>>> >>>> As a first example, I¹m looking at modifying the semantic gallery so that >>>> it can display images from our CMS. The semantic markup that we add to >>>> each file facade includes properties for mimetype and a reference to the >>>> actual file. But I don¹t want the ask query writer to think about such >>>> things so I would expect a normal image gallery query to be supplied. That >>>> implies that in my output formatter, I would get hits on the image façade >>>> pages and have to do two things: >>>> 1. for a page hit, ask for more data about the page (additional properties >>>> we have added (mimetype,fileuri)) >>>> 2. somehow replace some of the filerepo code to be able to locate files >>>> >>>> The latter is more of a MW issue I believe. But for the 1st item, the >>>> documentation says to use the SMW Store api. However I notice that most >>>> extension code uses direct DB calls. Is it still the case that I should be >>>> using the Store API? I have started down this path as it seems like the >>>> correct thing to do. >>>> >>>> I have tried to use the Store API like this: >>>> $data = smwfGetStore()->getSemanticData($title); >>>> $properties = $data->getProperties(); >>>> foreach ($properties as $property) { >>>> $rv = $property->getWikiValue(); >>>> //$proptext = $property->getLongHTMLText($skin); >>>> $values = $data->getPropertyValues($property); >>>> $count = count($values); >>>> foreach ($values as $value) { >>>> $valu = $value->getShortWikiText(); >>>> } >>>> >>>> What I¹m getting back is the modification time and an initial category I >>>> used for the page. I added more properties and another category and they >>>> don¹t show up in the query result but they do show up in an ask query. I >>>> tried to update the cache with a action=purge >>>> >>>> Am I approaching this wrong or using the wrong method? We are using the >>>> HaloStore2 I believe but the method is implemented in sqlstore2. I have >>>> not sifted through all that code but at first glance, it looks like its >>>> looking for a well-defined set of properties. Is that correct? >>>> >>>> Any pointers greatly appreciated. >>>> >>>> Karen >>>> >>>> >>>> --------------------------------------------------------------------------- >>>> --- >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and stay >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>> http://p.sf.net/sfu/devconference >>>> _______________________________________________ >>>> Semediawiki-devel mailing list >>>> Sem...@li... >>>> <http://Sem...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>>> >>> >>> > > |
From: Yaron K. <ya...@gm...> - 2009-10-09 22:03:16
|
Hi, By "External Store", I assume you mean "External Data"? It may be possible to use it to get internal file information, by querying the database via #get_db_data, but I'm not sure about that. I think these questions about using the code, like ImageGallery or the SMW API, are premature at the moment - it seems to me that your major decision is how to get MediaWiki to know about hierarchical file structures. Once you decide that, the display and SMW stuff will, I think, be a relatively minor part. I'd suggest writing the mediawiki-l mailing list about it - it could be that extensions already exist for dealing with the issue of files in directories, or that other people have already thought about it. -Yaron On Fri, Oct 9, 2009 at 5:37 PM, Schuchardt, Karen L < Kar...@pn...> wrote: > We are looking for a lightweight solution to prove the concept. Right > now the CMS back end we have doesn’t have a user interface. By the way, we > looked at Plone initially and liked it for several reasons but there were > some hurdles that we just didn’t want to try to take on. MW/SMW have lots > of nice displays too, just not anything revolving around collections. I’m > not familiar with External Store but am now looking at the code. I’ll have > to look and see how its used. I assume that “data” in this case refers to > files/content since there is an http implementation. Can this be used in > conjunction with the filerep classes? If so, it sounds promising. I too am > concerned that it might require a lot of low level changes but am hoping to > find a good/clean way. > > In looking at the semantic image gallery, it uses the ImageGallery class. > Image pages are added to to the image gallery based on hits from the query > and these are represented as File objects with methods to get thumbnails and > so forth. So a mechanism to generate File objects that can point to our > data and provide all the normal behavior would seem to be one way to > minimize the amount of code that has to be modified. Perhaps we could have > a special File subclass that knows about our repository but I’m not sure > how/where to hook something like that in. It might become more clear if I > look at how ExternalStore is used. Does that make sense? > > Any overview documentation on filerep and the various storage dirs/classes > would be helpful if you are aware of any. > > Revisiting my original question, is the Store API the right thing to use > for my queries and if so, any idea why I was not getting all the data I was > expecting. > > Karen > > > On 10/9/09 2:16 PM, "Yaron Koren" <ya...@gm...> wrote: > > Hi, > > The concept of MediaWiki supporting a hierarchical file structure, although > it (a) seems like it might be a rather dramatic change to MW, requiring a > lot of low-level changes, and (b) seems only tangentially related to SMW. > Sure, you might want to have a new special property or two, along the lines > of "Modification date", but that's not really the core issue. > > With that said, maybe there are less dramatic, more lightweight solutions > to get at the same issue. For instance, if a CMS like Plone already supports > file versioning of the kind that you require, maybe it's possible to have a > lightweight extension, akin to External Data, that can (a) display an > image/file from that CMS, (b) retrieve other data about that file, that can > then be stored via SMW, and (c) link the user to the CMS's interface for > dealing with that file. It could be called "External Files", perhaps... any > thoughts? > > -Yaron > > > On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L < > Kar...@pn...> wrote: > > Hi Yaron, > > We want a CMS that versions file sets (not just individual files), provides > the normal hierarchical file structure people are familiar with (not just > namespaces), and then we want to make views of the content based on both the > collection hierarchy and semantic queries for metadata we extract from > files. Ideally, we want the best of something like MW and Plone which > provides flexible views of content. > > In addition to the image gallery, we plan to integrate different types of > custom viewers along the lines of the gnu plot extension, statistical > operations on data etc. Basically we want to be able to plug in a range of > data operations on the server side. > > The number of files will be large and some of the files will be large. We > also plan on providing provenance information between files or collections > of files. The data is scientific data. Some ascii, some binary. Lots of > different formats. > > The images and other data will effectively be located on the server in a > normal file structure so that MW/SMW can easily access it though it might be > deposited through other means than the wiki. We currently have a wiki > upload extension that takes a zip file, unzips it, add the data to the CMS, > and generates the façade pages. Command lines tools for doing this same > thing will also exist. Now we are investigating how to integrate it more > deeply in the wiki presentation. > > Does that answer your question? We really think this could be a powerful > capability for collaborative science but are in the infancy of figuring out > what it would really take to do it well. Any suggestions or information > will be very helpful to us. > > Karen > > > > On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm... < > http://ya...@gm...> > wrote: > > Hi, > > Can you clarify what it is that you're trying to do? You said that you > wanted to turn SMW into a CMS (it already is one, of course, but it > certainly could be a nicer one), but then you mentioned using "images from > our CMS". Where are these images coming from? And what features, if any, do > you want to add besides external-image integration? > > -Yaron > > > On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L < > Kar...@pn... <http://Kar...@pn...> > wrote: > > Hi, > > We are interested in augmenting SMW/MW to have a more sophisticated content > management capability so that it can act as a Content Management System > (CMS) with great wiki features. Our approach so far has been to generate a > façade page for every document/collection that gets loaded into the CMS. > These façade pages are essentially metadata pages that contain semantic > markup about the contents of the files. They also support normal directory > navigation. I’m trying to get a handle on the best way to change the > existing SMW code and extensions so that they “know” about our files. I > hope you can offer some advice. > > As a first example, I’m looking at modifying the semantic gallery so that > it can display images from our CMS. The semantic markup that we add to each > file facade includes properties for mimetype and a reference to the actual > file. But I don’t want the ask query writer to think about such things so I > would expect a normal image gallery query to be supplied. That implies that > in my output formatter, I would get hits on the image façade pages and have > to do two things: > > 1. for a page hit, ask for more data about the page (additional > properties we have added (mimetype,fileuri)) > 2. somehow replace some of the filerepo code to be able to locate files > > > The latter is more of a MW issue I believe. But for the 1st item, the > documentation says to use the SMW Store api. However I notice that most > extension code uses direct DB calls. Is it still the case that I should be > using the Store API? I have started down this path as it seems like the > correct thing to do. > > I have tried to use the Store API like this: > $data = smwfGetStore()->getSemanticData($title); > $properties = $data->getProperties(); > foreach ($properties as $property) { > $rv = $property->getWikiValue(); > //$proptext = $property->getLongHTMLText($skin); > $values = $data->getPropertyValues($property); > $count = count($values); > foreach ($values as $value) { > $valu = $value->getShortWikiText(); > } > > What I’m getting back is the modification time and an initial category I > used for the page. I added more properties and another category and they > don’t show up in the query result but they do show up in an ask query. I > tried to update the cache with a action=purge > > Am I approaching this wrong or using the wrong method? We are using the > HaloStore2 I believe but the method is implemented in sqlstore2. I have not > sifted through all that code but at first glance, it looks like its looking > for a well-defined set of properties. Is that correct? > > Any pointers greatly appreciated. > > Karen > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... < > http://Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > |
From: Schuchardt, K. L <Kar...@pn...> - 2009-10-09 22:08:13
|
Ok I will do that. It may be premature but we have to have a demo in a couple of weeks so temporary hacking is part the plan. Plus it helps to have a specific example to work with to understand the existing code and what it might take to do it the correct way. I was referring to the class ExternalStore. I¹m not sure how it fits in. On 10/9/09 3:02 PM, "Yaron Koren" <ya...@gm...> wrote: > Hi, > > By "External Store", I assume you mean "External Data"? It may be possible to > use it to get internal file information, by querying the database via > #get_db_data, but I'm not sure about that. > > I think these questions about using the code, like ImageGallery or the SMW > API, are premature at the moment - it seems to me that your major decision is > how to get MediaWiki to know about hierarchical file structures. Once you > decide that, the display and SMW stuff will, I think, be a relatively minor > part. I'd suggest writing the mediawiki-l mailing list about it - it could be > that extensions already exist for dealing with the issue of files in > directories, or that other people have already thought about it. > > -Yaron > > > On Fri, Oct 9, 2009 at 5:37 PM, Schuchardt, Karen L <Kar...@pn...> > wrote: >> We are looking for a lightweight solution to prove the concept. Right now >> the CMS back end we have doesn¹t have a user interface. By the way, we >> looked at Plone initially and liked it for several reasons but there were >> some hurdles that we just didn¹t want to try to take on. MW/SMW have lots of >> nice displays too, just not anything revolving around collections. I¹m not >> familiar with External Store but am now looking at the code. I¹ll have to >> look and see how its used. I assume that ³data² in this case refers to >> files/content since there is an http implementation. Can this be used in >> conjunction with the filerep classes? If so, it sounds promising. I too am >> concerned that it might require a lot of low level changes but am hoping to >> find a good/clean way. >> >> In looking at the semantic image gallery, it uses the ImageGallery class. >> Image pages are added to to the image gallery based on hits from the query >> and these are represented as File objects with methods to get thumbnails and >> so forth. So a mechanism to generate File objects that can point to our data >> and provide all the normal behavior would seem to be one way to minimize the >> amount of code that has to be modified. Perhaps we could have a special File >> subclass that knows about our repository but I¹m not sure how/where to hook >> something like that in. It might become more clear if I look at how >> ExternalStore is used. Does that make sense? >> >> Any overview documentation on filerep and the various storage dirs/classes >> would be helpful if you are aware of any. >> >> Revisiting my original question, is the Store API the right thing to use for >> my queries and if so, any idea why I was not getting all the data I was >> expecting. >> >> Karen >> >> >> >> On 10/9/09 2:16 PM, "Yaron Koren" <ya...@gm... >> <http://ya...@gm...> > wrote: >> >>> Hi, >>> >>> The concept of MediaWiki supporting a hierarchical file structure, although >>> it (a) seems like it might be a rather dramatic change to MW, requiring a >>> lot of low-level changes, and (b) seems only tangentially related to SMW. >>> Sure, you might want to have a new special property or two, along the lines >>> of "Modification date", but that's not really the core issue. >>> >>> With that said, maybe there are less dramatic, more lightweight solutions to >>> get at the same issue. For instance, if a CMS like Plone already supports >>> file versioning of the kind that you require, maybe it's possible to have a >>> lightweight extension, akin to External Data, that can (a) display an >>> image/file from that CMS, (b) retrieve other data about that file, that can >>> then be stored via SMW, and (c) link the user to the CMS's interface for >>> dealing with that file. It could be called "External Files", perhaps... any >>> thoughts? >>> >>> -Yaron >>> >>> >>> On Fri, Oct 9, 2009 at 4:23 PM, Schuchardt, Karen L >>> <Kar...@pn... <http://Kar...@pn...> > wrote: >>>> Hi Yaron, >>>> >>>> We want a CMS that versions file sets (not just individual files), provides >>>> the normal hierarchical file structure people are familiar with (not just >>>> namespaces), and then we want to make views of the content based on both >>>> the collection hierarchy and semantic queries for metadata we extract from >>>> files. Ideally, we want the best of something like MW and Plone which >>>> provides flexible views of content. >>>> >>>> In addition to the image gallery, we plan to integrate different types of >>>> custom viewers along the lines of the gnu plot extension, statistical >>>> operations on data etc. Basically we want to be able to plug in a range of >>>> data operations on the server side. >>>> >>>> The number of files will be large and some of the files will be large. We >>>> also plan on providing provenance information between files or collections >>>> of files. The data is scientific data. Some ascii, some binary. Lots of >>>> different formats. >>>> >>>> The images and other data will effectively be located on the server in a >>>> normal file structure so that MW/SMW can easily access it though it might >>>> be deposited through other means than the wiki. We currently have a wiki >>>> upload extension that takes a zip file, unzips it, add the data to the CMS, >>>> and generates the façade pages. Command lines tools for doing this same >>>> thing will also exist. Now we are investigating how to integrate it more >>>> deeply in the wiki presentation. >>>> >>>> Does that answer your question? We really think this could be a powerful >>>> capability for collaborative science but are in the infancy of figuring out >>>> what it would really take to do it well. Any suggestions or information >>>> will be very helpful to us. >>>> >>>> Karen >>>> >>>> >>>> >>>> On 10/9/09 1:07 PM, "Yaron Koren" <ya...@gm... >>>> <http://ya...@gm...> <http://ya...@gm...> > wrote: >>>> >>>>> Hi, >>>>> >>>>> Can you clarify what it is that you're trying to do? You said that you >>>>> wanted to turn SMW into a CMS (it already is one, of course, but it >>>>> certainly could be a nicer one), but then you mentioned using "images from >>>>> our CMS". Where are these images coming from? And what features, if any, >>>>> do you want to add besides external-image integration? >>>>> >>>>> -Yaron >>>>> >>>>> >>>>> On Fri, Oct 9, 2009 at 2:35 PM, Schuchardt, Karen L >>>>> <Kar...@pn... <http://Kar...@pn...> >>>>> <http://Kar...@pn...> > wrote: >>>>>> Hi, >>>>>> >>>>>> We are interested in augmenting SMW/MW to have a more sophisticated >>>>>> content management capability so that it can act as a Content Management >>>>>> System (CMS) with great wiki features. Our approach so far has been to >>>>>> generate a façade page for every document/collection that gets loaded >>>>>> into the CMS. These façade pages are essentially metadata pages that >>>>>> contain semantic markup about the contents of the files. They also >>>>>> support normal directory navigation. I¹m trying to get a handle on the >>>>>> best way to change the existing SMW code and extensions so that they >>>>>> ³know² about our files. I hope you can offer some advice. >>>>>> >>>>>> As a first example, I¹m looking at modifying the semantic gallery so that >>>>>> it can display images from our CMS. The semantic markup that we add to >>>>>> each file facade includes properties for mimetype and a reference to the >>>>>> actual file. But I don¹t want the ask query writer to think about such >>>>>> things so I would expect a normal image gallery query to be supplied. >>>>>> That implies that in my output formatter, I would get hits on the image >>>>>> façade pages and have to do two things: >>>>>> 1. for a page hit, ask for more data about the page (additional >>>>>> properties we have added (mimetype,fileuri)) >>>>>> 2. somehow replace some of the filerepo code to be able to locate files >>>>>> >>>>>> The latter is more of a MW issue I believe. But for the 1st item, the >>>>>> documentation says to use the SMW Store api. However I notice that most >>>>>> extension code uses direct DB calls. Is it still the case that I should >>>>>> be using the Store API? I have started down this path as it seems like >>>>>> the correct thing to do. >>>>>> >>>>>> I have tried to use the Store API like this: >>>>>> $data = smwfGetStore()->getSemanticData($title); >>>>>> $properties = $data->getProperties(); >>>>>> foreach ($properties as $property) { >>>>>> $rv = $property->getWikiValue(); >>>>>> //$proptext = $property->getLongHTMLText($skin); >>>>>> $values = $data->getPropertyValues($property); >>>>>> $count = count($values); >>>>>> foreach ($values as $value) { >>>>>> $valu = $value->getShortWikiText(); >>>>>> } >>>>>> >>>>>> What I¹m getting back is the modification time and an initial category I >>>>>> used for the page. I added more properties and another category and they >>>>>> don¹t show up in the query result but they do show up in an ask query. I >>>>>> tried to update the cache with a action=purge >>>>>> >>>>>> Am I approaching this wrong or using the wrong method? We are using the >>>>>> HaloStore2 I believe but the method is implemented in sqlstore2. I have >>>>>> not sifted through all that code but at first glance, it looks like its >>>>>> looking for a well-defined set of properties. Is that correct? >>>>>> >>>>>> Any pointers greatly appreciated. >>>>>> >>>>>> Karen >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> ----- >>>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>>>> is the only developer event you need to attend this year. Jumpstart your >>>>>> developing skills, take BlackBerry mobile applications to market and stay >>>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>>>> http://p.sf.net/sfu/devconference >>>>>> _______________________________________________ >>>>>> Semediawiki-devel mailing list >>>>>> Sem...@li... >>>>>> <http://Sem...@li...> >>>>>> <http://Sem...@li...> >>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>>>>> >>>>> >>>>> >>> >>> > > |