...oops, substitute "example.com" for "smw.referata.com" there. :)
On Mon, Sep 7, 2009 at 10:23 AM, Yaron Koren <yaro...@gmail.com> wrote:
> Hi,
> Sure, let me explain internal objects: they're stored in the SMW database
> tables the same way that wiki pages are, and they hold their own properties
> the same way wiki pages do; the only difference is that they don't have a
> corresponding wiki page (and their naming structure, "Name#Number", makes it
> impossible for there to be a page, since MediaWiki doesn't allow pound signs
> in titles).
>
> So I'm imagining the RDF output for an internal object would look like
> this, for the first internal object in a page called "PageName":
>
> <swivt:Subject rdf:about="
> http://smw.referata.com/wiki/Special:URIResolver/PageName#1";>
> <rdfs:label>PageName#1</rdfs:label>
> <rdfs:isDefinedBy rdf:resource="
> http://smw.referata.com/wiki/Special:ExportRDF/PageName#1"/>
> <property:PropertyName1 rdf:datatype="...">Value1</property:PropertyName1>
> <property:PropertyName2 rdf:datatype="...">Value2</property:PropertyName2>
> ...
> </swivt:Subject>
>
> ...in other words, it would look like the current RDF for a wiki page,
> except that it wouldn't contain "swivt:page" or "rdf:type" tags.
>
> -Yaron
>
>
> On Mon, Sep 7, 2009 at 2:55 AM, Markus Krötzsch <
> mar...@semantic-mediawiki.org> wrote:
>
>> Hi Yaron,
>>
>> I also would like to do some changes to the RDF export in general:
>>
>> (1) I would like URI generation to be easier to control in extensions. The
>> main goal of this would be to make the current "vocabulary import" feature
>> of
>> SMW a separate extension, and to allow for other such extensions that
>> implement better solutions for using external URIs.
>>
>> (2) I would like it to become a result printer, so that there is an ask
>> format
>> "rdf" that uses the same code as the export Special page. The problem here
>> is
>> that RDF export does not export is based on SMWSemanticData objects (all
>> data
>> for some page) while query printers are based on SMWQueryResult objects
>> (tabular data based on a fixed set of print requests).
>>
>> I guess your changes could go into that re-factoring of the export code as
>> well. One thing to consider is that the current RDF export is largely
>> controlled by the data value implementations: every datatype can provide
>> its
>> own way for encoding its contents in RDF (triples, which are then
>> serialized
>> to RDF/XML during printout). This is also important to allow SMW to be
>> used
>> with RDF stores (they get the generated RDF for storing it). So care must
>> be
>> taken when extending the RDF: it is not enough to insert some string into
>> the
>> RDF/XML generation, but rather the corresponding RDF triples should be
>> generated at an earlier stage already so that they are available for other
>> uses (such as connecting RDF stores) as well.
>>
>> So how do internal objects relate to datatypes? In fact, maybe you could
>> send
>> a short email to explain how internal objects work at the moment.
>>
>> Markus
>>
>>
>> On Sonntag, 6. September 2009, Yaron Koren wrote:
>> > Hi,
>> > 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?
>> >
>> > -Yaron
>>
>>
>> --
>> Markus Krötzsch <mar...@semantic-mediawiki.org>
>> * Personal page: http://korrekt.org
>> * Semantic MediaWiki: http://semantic-mediawiki.org
>> * Semantic Web textbook: http://semantic-web-book.org
>> --
>>
>>
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
