2009/1/27 Yaron Koren <yaro...@gmail.com>: > 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.
Or queries. I like this idea. It reminds me of the proposal by Algorithmix to explicitly apply an 'object model' within the existing framework of SMW: http://semeb.com/dpldemo/index.php?title=Semantic_MediaWiki_with_Property_Clusters I'm still thinking to write a page describing 'data modeling in SMW' - other than the advice given on this list in previous discussions, can anyone point me at resources related to this topic? I have in mind things like the personal library example created by Yaron: http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Example Dan. > 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 >> > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
