Thanks for the explanation. As I see it, we could actually merge internal objects into the current SMW code for multi-valued properties. Below is a somewhat lengthy description of a possible design.
First of all, the way multi-valued properties work internally is very similar
to your internal objects. The main differences is that we use internal
properties "_1", "_2", ... to store the data, so the properties have no name
and cannot be addressed from the outside (and they have no fixed datatype
either).
But other than this, the whole thing is really almost the same. In particular,
the multiple parts of multi-valued properties are stored using the same
property tables as if the internal object was a real page. Also, SMW already
has a method for managing truly "internal objects".
I don't think much would need to be changed in the store to support your
internal objects using mostly the same code. Then the RDF export, but also
querying etc. would all work as expected without further extensions. Of
course, the code for multi-valued properties itself could use some
improvement, and many things don't work yet as expected (e.g. printing one
property of one internal object in a query -- do you have a solution for
this?).
The first thing to do then, however, would be to have a datatype for storing
one internal object and its properties. This would mostly be an "adaptor" type
of class, since the code for storing an internal object could actually be
reused from SMWSemanticData (the class that stores the data for one page now).
After this, one would have to update the store to handle those things
properly.
If we *really* want to go there, we should briefly reconsider the design of
the whole thing. In particular: do we really want internal objects to be
unnamed? This makes them truly internal, but it also makes it very hard to
display them in queries or browsing. As an alternative, one could also have a
function where the internal name is also given by the editor (i.e. instead of
an automatic internal name "USA#1" you would have something like
"USA#presidency_of_Adams" -- in this way, internal objects also would
naturally lead to HTML anchors). Two other changes I would make are:
* Change the direction of the property. Now that we have inverse properties,
it is no longer important to have it in that direction, and a "forward" style
of writing is more in line with the other annotations in SMW.
* Change the name of the parser function. "internal" sounds very technical.
Now that I think of it: I think we should go for a solution that does not need
any special parser function. We could have some datatype "compound object" (or
any better name) that accepts inputs of the form, say:
"name; property1=value1; property2=value2; ...; propertyN=valueN"
Then your example could be written as:
[[has presidency::presidency of Adams; Name=John Adams; Start year=1789; End
year=1797]]
but just as well one could use the #set parser function. The syntax here is of
course just an example; anything could be done as long as it does not conflict
with template, link or annotation syntax.
Anyway, this would obviously need some integration work, and my current main
goal is to reduce code complexity of SMW. If someone could help with this so
that we get done with it sooner, then I can have a look at the internal
objects' integration with the multi-valued property code.
Markus
On Mittwoch, 9. September 2009, Yaron Koren 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
> > --
--
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
--
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
