While I don't have any technical input on this, I do want to speak up in support of this being important functionality. The "invisibility" of SIO information in RDF exports is a significant issue for our Wiki (http://en.openei.org). I've also seen others mention its important in previous threads here and elsewhere.
Finding some resolution to this issue would make a lot of SMW users happy. Thanks, Jamey On 3/24/10 9:39 AM, "Yaron Koren" <[email protected]> wrote: Hi, About six months ago, I sent an email to this list, asking about changing some of the SMW code to allow other extensions, specifically Semantic Internal Objects, to modify the RDF. You can see the discussion here: http://www.mail-archive.com/[email protected]/msg01730.html Basically, it turned into a discussion about the possible ways of changing SMW's RDF-export code, and about the design and usefulness of SIO. Well, SMW 1.5 has now been released, and the RDF code wasn't substantially modified (not that I think there's anything wrong with the current basic setup), and it looks like there's some sort of consensus now that SIO works fine for what it's intended to do. So, given that, I'd like to re-ask this question - the original text of the email is included below. Thanks, Yaron ------------------------------------------- I want the new extension Semantic Internal Objects to be able to add data about internal objects to the RDF export. Normally this wouldn't seem too hard: the function that prints RDF data about a specific wiki page is OWLExport::printObject(), in the file SMW_SpecialOWLExport.php (it's a little odd that the class is contained directly in the file for a special page, but that's another story). Anyway, it seems like the solution would be to just add a call to end of that function that looks something like: wfRunHooks('smwPrintObjectRDF', array($this)); That way, Semantic Internal Objects could register a function with the 'smwPrintObjectRDF' hook, so that every time the RDF for a specific page was created, SIO could add on the RDF for all the internal objects in that page. Unfortunately, the problem is that nearly all of the variables and methods in the OWLExport class are either protected or private; that means there's no way for outside code to add to the RDF. This looks to me like overly-protective code; could one or more of the functions be made public instead? Or maybe the simplest solution is to create a new public function, maybe called addToRDF(), that just adds a passed-in string to the RDF being generated. Any thoughts on this? ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Semediawiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
