Oops, I just realized I had the wrong years for John Adams - well,
thankfully, incorrect data is still data. :)
On Wed, Sep 9, 2009 at 9:54 AM, Yaron Koren <yaro...@gmail.com> wrote:
> Hi,
> Sure: internal objects are stored using the new parser function
> #set_internal, which is called in the following way to define a country's
> leader:
>
> {{#set_internal:Is president of|Name=John Adams|Start year=1789|End
> year=1797}}
>
> Semantic Internal Objects processes this function by manually adding rows
> to the SMW tables, using its own "SIOSQLStore" class:
> - a new row is added to the smw_ids2 table, where the object is given a
> name like "United States#1".
> - new rows are added to smw_atts2 and smw_rels2, for each of the properties
> of this object.
>
> Data for internal objects is retrieved by SMW itself; thankfully, the data
> in some sense "spoofs" SMW into thinking that it's dealing with wiki pages,
> even though they have no entry in the 'page' tables. (It would be better if
> SMW could have special handling for internal objects, but that's another
> story).
>
> You can read more about it here, of course:
>
> http://www.mediawiki.org/wiki/Extension:Semantic_Internal_Objects
>
> -Yaron
>
> On Wed, Sep 9, 2009 at 3:03 AM, Markus Krötzsch <
> mar...@semantic-mediawiki.org> wrote:
>
>> On Montag, 7. September 2009, Yaron Koren 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).
>>
>> Could you explain a little bit more on how you achieve this internally?
>> How
>> are the internal objects encoded during parsing? How are they passed to
>> the
>> store? How are they stored? How are they retrieved (e.g. when using
>> getSemanticData())? (I am still wondering where to best put the RDF
>> generation
>> within the overall flow of data.)
>>
>> Markus
>>
>> >
>> > 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
>> > > --
>>
>>
>> --
>> 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
