I've thought more about this implementation. Given that (a) I still think a parser function like "#internal_set" is the best approach to take, (b) no one has brought up any major problems with the scheme, and (c) there's still an effort to keep SMW to a minimum size, I'm considering creating a separate extension, possibly called "Semantic Internal Objects", that would just handle an "#internal_set" function and, possibly, any special querying (hopefully none) needed to display the data it would store. Are there any objections to that idea?


On Mon, Feb 2, 2009 at 2:02 PM, Markus Krötzsch <markus@semantic-mediawiki.org> wrote:
Some brief comments from my side:

* What Yaron proposes is possible and makes sense.

* The reason that this was not implemented already was that we initially went
for multi-valued properties as one way of allowing "complex subobjects". I
acknowledge that the use-cases for both approaches are slightly different.

* There is no major technical challenge in implementing the idea Yaron
proposes. In particular, multi-valued properties are already implemented in a
way that is very similar to what you would do for the proposed "internal

* The reason why multi-valued properties are not used a lot is, I think, the
restricted way in which they can be used in queries, especially in printouts:
you cannot display their components individually. The internal object proposal
addresses this by allowing queries to return internal objects. I note that the
same could be done for the values of multi-valued properties.

* The previous change has many consequences on the API-level, and might affect
a great amount of code in SMW and in extension. Currently, any property has
one datatype, where "Relations" point to wiki pages. The new proposal would
allow some properties to point to either a wiki page or to an internal object.
So one would need a unified API and processing for both. This is the main

* I have another input syntax proposal: one could have a parser function
#smwsection (the name is immaterial) that simply encloses normal wiki text,
but that associates all annotations that are contained therein with an
internal sub-object instead of with the page. The advantage is: minimal syntax
to memorize, usage of displayable or hidden properties just like anywhere
else. The disadvantage is: I have no idea how to achieve this behaviour.

* Maybe most importantly: the proposal requires changes in the very core of
SMW, with good coordination with some extensions. I cannot take up such a
large extension project at the moment, since SMW needs to reduce the size and
complexity of its code (to support code review by WikiMedia).

* Regarding Blank Nodes: No, this has nothing to do with blank nodes (bnodes).
A bnode in RDF is syntactic object that is not referred to with a URI. This is
independent of the particular usage of that object in modelling: as long as
you have only a single document, you may exchange URI-referenced objects with
blank nodes without changing the semantics of the document a lot (at least as
long as the document is used as a knowledge base that is "asserted", as
opposed to "queried for"). The advantage of using bnodes to represent
"internal objects" is that is saves the cost of coining new URIs. The
disadvantage is that internal objects then could not be identified across
documents (e.g. when comparing partial ontology exports) and that it reduces
compatibility with OWL DL. I think if we manage to come up with a name for
displaing the internal objects to the user, it won't be too hard to get them
some proper URIs, too.



On Mittwoch, 28. Januar 2009, Yaron Koren wrote:
> Well, the basic idea is that, as Markus and Denny have said, the plan is to
> eventually replace the double-brackets notation in SMW with calls to parser
> functions like #set and #declare, due to the double brackets being
> difficult to parse because of how MediaWiki parsing works.  With that in
> mind, I figured any new type of syntax should just use parser functions
> from the start. I think a parser function is also better because it
> enforces the rule that an internal object should always link to the page
> it's on, which, the more I think about it, the more I think is the only way
> to go.
> As to how n-aries can be defined anywhere in free text - well, parser
> functions separate out the data declarations from the text, so it becomes a
> non-issue: the text looks however you want it to look, since it's not
> setting any data. It does mean, unfortunately, that the same data needs to
> be typed twice, unless of course you're using templates.
> And naming internal objects: I don't think it's necessary, because I don't
> think anything should link to an internal object, either semantically or
> otherwise. Maybe a convention like "France#1" is bad, because that pound
> sign looks like part of a URL - something like "France:1" might be better.
> -Yaron
> On Tue, Jan 27, 2009 at 6:18 PM, Sergey Chernyshev <
> sergey.chernyshev@gmail.com> wrote:
> > Speaking of blank nodes - I think it should be possible to explicitly
> > name them so we will have not only "France#1", "France#2", but also
> > "France#Military" and "France#Transportation".
> >
> > This is important from hash reference and linking perspective, plus it'll
> > give default title to the object.
> >
> > This will also align more closely with MediaWiki sections idea when pages
> > are merged together and one page describes multiple objects.
> >
> > I'm not 100% sure how parser function fits with the idea that n-aries can
> > be defined anywhere within a paragraph of free-text - we might need
> > bigger discussion regarding this - maybe we should use something like:
> >
> >      Some text that is about France
> >      {{#subject_change_start:Military}}
> >      Some text that is about France#Military with some properties defined
> >      as before like  [[Prop name::prop value]]
> >      {{#subject_change_end}}
> >      This text is again about France
> >
> > Where {{#subject_change_end:}} is optional. This might allow more
> > flexibility and allow nested subject changes, but might be harder to
> > parse.
> >
> > Does it make sense?
> >
> >                Sergey
> >
> > On Tue, Jan 27, 2009 at 4:34 PM, Yaron Koren <yaron57@gmail.com> wrote:
> >> I wouldn't know, but it sounds plausible.
> >>
> >> -Yaron
> >>
> >> On Tue, Jan 27, 2009 at 12:09 PM, Jeff Thompson <jeff@thefirst.org>wrote:
> >>> Is an "internal object" similar to an RDF blank node?
> >>>
> >>> Yaron Koren wrote:
> >>>> Hi,
> >>>>
> >>>> The long recent discussion(s) on the SMW users list about n-ary
> >>>> relations, many-typed properties and the like got me thinking about
> >>>> what it would actually take to add support to SMW for what I call
> >>>> n-ary relations and some people call internal properties: properties
> >>>> that can be associated together in a free-form way. Having thought
> >>>> about it some more, I now believe it can be done fairly
> >>>> straightforwardly.
> >>>>
> >>>> I'm going on the assumption that double-brackets and the like are on
> >>>> the way out, to be replaced by parser functions, and so I'm imagining
> >>>> a parser function called, say, #internal_set, that would be called in
> >>>> the following way:
> >>>>
> >>>> {{#internal_set:main_property|prop1=val1|prop2=val2|...}}
> >>>>
> >>>> An example would be:
> >>>>
> >>>> {{#internal_set:Is leader of|Has name=Charles de Gaulle|Has start
> >>>> date=1 June 1958|Has end date=8 January 1959}}
> >>>>
> >>>> This parser function would create an "internal object" for the page
> >>>> from which it was called. The first property would link between the
> >>>> main page and that internal object, but - and this is important to
> >>>> note - it would link *from* the internal object, *to* the main page;
> >>>> which seems less logical than the other way around, but makes querying
> >>>> easier (and fits in with my general philosophy that children should
> >>>> link to parents). The other arguments would be all the other
> >>>> properties of the internal object, and their values.
> >>>>
> >>>> I believe that what's really needed to get all this working is a new
> >>>> SMW type for "internal objects", which might be called
> >>>> "SMWInternalValue". Like SMWWikiPageValue, it would allow properties
> >>>> pointing out from it, but unlike SMWWikiPageValue, it wouldn't
> >>>> represent an actual URI in the wiki; its printed value would just be a
> >>>> string that might look like "France#1" or "France#2". And its name
> >>>> would never show up in queries - a query like:
> >>>>
> >>>> {{#ask:[[Is leader of.Has continent::Europe]]|? Has name|? Has start
> >>>> date|? Has end date}}
> >>>>
> >>>> ...would show the "leader" information for all countries in Europe,
> >>>> but it wouldn't show the "main" column - just the three for the actual
> >>>> values.
> >>>>
> >>>> (Or maybe the internal-object column should show up as well, by
> >>>> default - I don't know.)
> >>>>
> >>>> The "SMWInternalValue" would also be unique in that no properties
> >>>> would point to it - it would only have its own properties, linking it
> >>>> to the page it's on as well as to its other values.
> >>>>
> >>>> So the work needed would be to create this parser function, and the
> >>>> corresponding new type, and make sure that all the usual functionality
> >>>> - adding, deleting, querying - worked with it.
> >>>>
> >>>> In any case, that's my idea. Any thoughts?
> >>>>
> >>>> -Yaron
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>-------- This SF.net email is sponsored by:
> >>>> SourcForge Community
> >>>> SourceForge wants to tell your story.
> >>>> http://p.sf.net/sfu/sf-spreadtheword
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--
> >>>>
> >>>> _______________________________________________
> >>>> Semediawiki-devel mailing list
> >>>> Semediawiki-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >>
> >> ------------------------------------------------------------------------
> >>------ This SF.net email is sponsored by:
> >> SourcForge Community
> >> SourceForge wants to tell your story.
> >> http://p.sf.net/sfu/sf-spreadtheword
> >> _______________________________________________
> >> Semediawiki-devel mailing list
> >> Semediawiki-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> > --
> > Sergey Chernyshev
> > http://www.sergeychernyshev.com/
> >
> >
> > -------------------------------------------------------------------------
> >----- This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Markus Krötzsch
Semantic MediaWiki    http://semantic-mediawiki.org
http://korrekt.org    markus@semantic-mediawiki.org