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