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 yaro...@gmail.com 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/semediawiki-devel@lists.sourceforge.net/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#174; 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
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
