Hi,
A few thoughts:
- using the standard "[[...]]" notation is certainly interesting; although
isn't there a long-term effort to get rid of the double-bracket notation,
since it's difficult to parse?
- similarly, overloading #set is also a possiblity; though it seems to me
simpler, for both the code and for users, if internal objects are stored
with a separate parser function. Is the issue just the "set_internal" sounds
too complex? I don't think it's that bad, but if it is, maybe there's
another name that could be used?
- there were a variety of reasons why I wanted internal objects to go
unnamed (except for the cryptic "Page name#1" label):
- to avoid naming conflicts: if you had two or more "presidency of Adams"
objects on a page (and there have, coincidentally, been two U.S. presidents
named Adams), then you'd have lost data, which ideally shouldn't happen in
SMW.
- internal objects often correspond to concepts that aren't usually given a
name to begin with. For leaders, most people don't refer to a "presidency",
"governorship", "prime ministerhood", etc. - they just say "this person was
president from this year to this year". For other concepts (like ingredients
in recipes), names like "Row #1" are pretty much the only thing that makes
sense.
- it makes object names look like links - as you note,
"USA#Presidency_of_Adams" looks like an anchor; but it's not an anchor,
which could be confusing, especially if the page also contains a section
called "Presidency of Adams".
- it's unnecessary - just adding "mainlabel=-" to the query takes care of
the whole problem.
- printing one property of one internal object - this isn't hard at all; if
you wanted to know the year John Adams took office, you could just call
"{{#ask:[[Name::John Adams]]|? Start year}}". (Note that "Name" is a defined
property, not the object's actual name, which would be something like
"USA#2".)
- changing the direction of the property - I agree that it seems odd to
define an object by the page's relation to it, and not the other way around,
but (a) this is actually my preferred way of always defining properties -
having children pointing to parents (e.g., "Is region in" instead of "Has
region"), and (b) a property pointing from a page to an object would in fact
never be useful in queries (it takes a little bit of working with internal
objects to realize this.) So I'm happy with the #set_internal syntax making
that explicit.
With all that said, it would be great if SMW could handle internal objects
directly in some way; I think of the Semantic Internal Objects extension as
just an intermediate step toward that goal.
-Yaron
On Wed, Sep 9, 2009 at 3:05 PM, Markus Krötzsch <
[email protected]> wrote:
> 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 <
> >
> > [email protected]> 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 <
> > > >
> > > > [email protected]> 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 <[email protected]>
> > > > > * Personal page: http://korrekt.org
> > > > > * Semantic MediaWiki: http://semantic-mediawiki.org
> > > > > * Semantic Web textbook: http://semantic-web-book.org
> > > > > --
> > >
> > > --
> > > Markus Krötzsch <[email protected]>
> > > * Personal page: http://korrekt.org
> > > * Semantic MediaWiki: http://semantic-mediawiki.org
> > > * Semantic Web textbook: http://semantic-web-book.org
> > > --
>
>
> --
> Markus Krötzsch <[email protected]>
> * 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
