Hi,
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?
-Yaron
On Mon, Feb 2, 2009 at 2:02 PM, Markus Krötzsch <
mar...@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
> objects".
>
> * 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
> work.
>
> * 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.
>
>
> Regards,
>
> Markus
>
>
> 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.chernys...@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 <yaro...@gmail.com>
> wrote:
> > >> I wouldn't know, but it sounds plausible.
> > >>
> > >> -Yaron
> > >>
> > >> On Tue, Jan 27, 2009 at 12:09 PM, Jeff Thompson <j...@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 mar...@semantic-mediawiki.org
>
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
