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

Reply via email to