On Mittwoch, 9. September 2009, Yaron Koren wrote: > 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?
Right, but my proposal would merely make the internal objects compatible with
that notation (like everything else is). But at the same time it would also
make them compatible with all other input methods that we have now or in the
future. So it would not be specific to [[ ]].
>
> - similarly, overloading #set is also a possiblity;
If a datatype takes care of the input, then it would not even be
"overloading".
> though it seems to me
> simpler, for both the code and for users, if internal objects are stored
> with a separate parser function.
If the usage is different from #set (real overloading) and does not just
require a different format for the property values in #set, then I would also
prefer a new function. I don't think overloading is very useful.
> 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?
No, and I don't think that it is as bad either. This is a minor issue, I
guess.
>
> - 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.
Well, I guess the preferred semantics for this situation would be that the two
uses of "#presidency of Admas" refer to the same internal object, and that all
the data that was given for this object is stored (union instead of
overwriting). If this is deemed problematic, one could also show a warning on
the second use.
> - 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.
I agree, this is difficult.
> - 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".
This could be bug or feature, depending on how you use it. It might be nice to
have an internal object that corresponds to an actual anchor, so clicking the
object brings you to the appropriate section.
> - it's unnecessary - just adding "mainlabel=-" to the query takes care of
> the whole problem.
Internal objects can appear in many places, including query results, other
query outputs, and all browsing pages. In most cases, you cannot do complex
formatting as in #ask to get a customised display, but you need to show some
reference to the internal object -- or hide internal objects in all such
places, which would make it hard to use them. I agree that it is hard to give
names to these objects, but it seems to be even harder to generate useful
labels for them automatically. Any ideas?
>
>
> - 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".)
Sure, this is not a problem.
>
> - 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.)
Counterexample:
{{#ask: [[has presidency.start date::<1800]] }}
shows all countries who had a president before 1800. I think this is a useful
query.
> So I'm happy with the
> #set_internal syntax making that explicit.
My main points against the inverted direction are:
(1) All annotations in SMW so far work the other way around. I guess people
are used to it.
(2) For managing the data in the store, SMW currently assumes that the subject
of an annotation is the same as the page that it was stated on. Since
#set_internal would change this, it would probably require more special
handling in the store.
>
> 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.
Well, as I already said, major parts of the required code coincide for both
approaches anyway: we need a datatype for storing the information about
internal objects and for exporting this data to RDF, and the store needs to
process this type properly. Based on this, one can either give the datatype a
parser method to read user input, making it available like all other
datatypes, or one could add new parser functions that uses this datatype
internally to store data.
Markus
>
> -Yaron
>
>
> On Wed, Sep 9, 2009 at 3:05 PM, Markus Krötzsch <
>
> mar...@semantic-mediawiki.org> 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 <
> > >
> > > 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
> > --
--
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.
------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
