Thank you, that's all extremely helpful. I agree, BTW, with the openness approach completely, and don't support the notion of, as you say, 'annointed ones'. However, patient confidentiality is an important exception.
On 10 July 2014 22:23, John McClure <jmccl...@hypergrove.com> wrote: > Peter, > Nothing I know of in SMW prevents defining annotation properties as a > subclass of category:Property. Though RDF's notion that so-called annotation > properties (with domains Class Property or Ontology) determines your level > of interchangeability with other RDF-compliant semantic models, nothing in > SMW prevents the domain of annotaiton properties from being Thing (or, > WikiPage or Topic). I'll note in this regard that SMW does not define > 'annotation properties' distinguished as ones that cannot be applied to > pages other than classes, properties or ontologies. > > You're wondering, if you define rules as properties of Properties, how to > apply them. My suggestion is to first implement the rules within > property-specific templates; then use those templates whenever the property > is to be set. When debugging is complete, convert these property templates > into PHP parser functions for far better performance, all easy to do with > MediaWiki!!!! > > If you'd like to preserve the capacity to set properties by, say, text > annotation (eg [[p::v]]) in addition to or rather than by call, then you'll > need to hook into SMW itself to monitor all properties being set. Not > terribly hard, but it would impose a processing penalty across the board. > I'm not aware of such an extension but it wouldnt be unreasonable to create > one. > > Lastly if a 'rule' that you'd like to impose concerns wiki operations such > as page-visiblity, not merely logical property requirements, then you have > more MW/SMW to hook than just property settings. "Visibility" is an > especially thorny problem, as it confronts basic operating assumptions of > wikis in general, i.e., they are meant to be open collaborative platforms > amongst all its users. One alternative is, instead of 'private areas' within > a wiki, create a separate 'private wiki' for the annointed group, using > interwiki links & transclusions &/or DSMW to maintain synchronization. > Another is to think about using the Project namespace which I've read is > 'private' to wiki-admins. A third alternative is a Project Halo extension > for ACLs that has its own sql tables, hooks the MW & SMW extensions, and so > on; however it is in an uncertain state of maintenance for latest MW & SMW > versions, so tread carefully there. > > best of luck/john > > > On 7/9/2014 9:56 AM, Peter Brooks wrote: > > I'm trying to think about this in a more semantic way. > > Surely, part of the point of semantics is to allow rules to be governed by > them. > > If I could create a property, say '[[page_visibility::group_X]]' then > it would make sense for the wiki to understand, from that, that the > rule for this property would be found on the property page > 'page_visibility' and it could apply those rules to group_X. Does that > make sense? > > If it did, then 'group_X' could be a page with the usernames that > constituted the group. So the page would be 'visible' - searchable, > editable - only to members of that group. > > It could be more general than that. The property page could have logic > one it, just like a template, that determined how the 'group_X' page > would be interpreted. > > Does this make sense? Is it already possible, but I've not understood > properly? Or would it, if not already possible, be difficult to > instantiate? > > I'm not sure how much would need to be changed to enable this, but, it > seems to me, that it's ans extension to the idea of parser functions. > Rather than simply parsing the rule to apply it to some text, the rule > is applied to the permissions matrix. So, rather than the > localsettings.php allocating permissions to a particular, named, > category, they would be applied to pages. > > If this isn't making sense, I can try to explain myself better. If it > is making sense, is this trivial, already there, impossible, or very > difficult? > > On 9 July 2014 18:18, Peter Brooks <peter.bro...@kchclinics.com> wrote: > > Thank you, it's a good idea, but wouldn't quite work. I've looked at > this alternative: > > http://www.mediawiki.org/wiki/Extension:CategoryPermissions > > It looks as if it would do the trick, but I'd need to have a category > per user, and update them when new users are added - unfortunately it > looks as if you can only set the categories in localsettings.php - if > there was a way of setting them in a form or template it would be > perfect. > > I was thinking that it might be possible to create a couple of dozen > categories and then take an unused one when I needed it, but the > coding would be much more complex than having one per user. > > I wonder if there'd be a way to link the username to a category and > have that recognised through a form... > > Alternatively, and it might be a bit bizarre, maybe the creation of a > new user could append these lines to localsettings.php: > > require_once("$IP/extensions/CategoryPermissions.php"); > $wgGroupDefaultAllow=true; //set to true to allow everyone access to > pages without a category > $wgCategoryExclusive=array("Category:cat_name","Category:cat2_name");//deny > access to these categories for anyone not in the group > $wgGroupPermissions['group_name']['Category:new_user_name_read']=true; > $wgGroupPermissions['group_name']['Category:new_user_name_edit']=true; > $wgGroupPermissions['group_name']['Category:new_user_name_move']=true; > $wgGroupPermissions['group_name']['Category:new_user_name_create']=true; > $wgGroupPermissions['group_name']['*_read']=true; //allow access to > all categories > > That wouldn't be quite enough, though, because the group would have to > be changed, as well, to include the new user. > > This has a bit of the feeling of self-modifying code that is not good, > so I'm hoping that there's an easier way. > > On 9 July 2014 10:02, Ad Strack van Schijndel > <ad.strackvanschijn...@gmail.com> wrote: > > Perhaps the Lockdown extension https://www.mediawiki.org/wiki/Lockdown is > something for you. > > Ad > > > Op 8 jul. 2014, om 17:55 heeft Peter Brooks <peter.bro...@kchclinics.com> > het volgende geschreven: > > I'd like a user to be able to create a page in a namespace with a form. > > I'd like that user to be able to access only pages in the namespace > that he has created. > > Unless other users have full access to the namespace, I'd like them > not to be able to view the pages directly. > > I've been looking at the various permission settings and add-ons and I > can't see a way to do this. > > The closest I can see is the {{PAGECREATOR}} extension. That would > allow me to restrict the listing of pages to people can only see pages > that they have created. I can't, though, see how I can allow people to > create the pages without having access to all the others. > > Any suggestions? > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ______________________________ > _________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
