On 15/02/2011 12:35, graham wrote:

On 02/15/11 11:10, Daniel Friesen wrote:

...

...

Graham

If you don't mind parsing RDF you could use Semantic MediaWiki to annotate the information you want. You could even use Semantic Forms to make entry easy.

I wondered about that but dressing configuration file data up in triples seemed like a really uneccessary complication, and also rather fragile. Unless you have any arguments for going down this route? (other than 'Semantic MediaWiki already exists' ;-)

Maybe I am missing something here, but why would you need RDF when using Semantic MediaWiki? RDF only appears in Semantic MediaWiki as one (out of several) export formats for data, and is used neither by users nor by administrators of SMW sites for entering data. SMW also provides data in other formats such as CSV and JSON.

Not sure if this simplifies anything for you, though. In the end, you will need *some* format for your data, and it seems unlikely that your native format will be directly supported in MediaWiki (or its extensions). So you will probably need some form of syntactic adaptation to get data into the wiki, whatever extension you use.

What is your preferred data format, i.e. data model and (optionally) syntax?

Regards,

Markus

On 16/02/2011 10:18, graham wrote:

On 02/15/11 14:10, Markus Krötzsch wrote:

...

Not sure if this simplifies anything for you, though. In the end, you will need *some* format for your data, and it seems unlikely that your native format will be directly supported in MediaWiki (or its extensions). So you will probably need some form of syntactic adaptation to get data into the wiki, whatever extension you use.

What is your preferred data format, i.e. data model and (optionally) syntax?

I still have a feeling Semantic MediaWiki is overkill for my limited needs.

That might well be, though there is no harm done if you use only a few functions (other than the general harm of installing another extension that you need to update in the future, of course).

I would be happy with treating the data as unstructured 'blobs' which can be:

• entered using the normal wiki editor, and follow normal wiki rules for

display

• be hidden or exposed to users depending on their group
• be returned in response to a query (just returning a string for

parsing at the receiving end would be fine)

I would like to be able to make queries such as 'return all blobs of type x from pages in category y', with the querier responsible for parsing the data.

This still sounds very much like SMW to me (but then again, when you have a hammer, everything looks like a nail ...). What SMW would provide is:

* SMW supports text blobs as a possible type of input data (Type:Text and Type:Code, depending on the desired formatting). * In order for SMW to find this data on a wiki page, the text blobs need to be somewhat restricted in the MediaWiki markup that they can use. There are particular problems if your text contains characters that MediaWiki uses, e.g. { or |. Some other problems may occur for data that MediaWiki escapes automatically, e.g. < and &. These are probably issues in any case, whatever solution you go for. * One page can have one or more blobs of data associated (each blob is a property value), and they can be of different kind (i.e. be assigned to different properties, e.g. if there are distinct types of configurations to store for one page). * Stored data can be retrieved in various ways and formats, e.g. based on membership of a page in one or more categories. It should not be hard to find a format that is easy to parse in an external tool to retrieve the individual text blobs (e.g. JSON is easy to parse in JavaScript, and CSV is not hard to parse with simple text manipulation).

I think this is not so far from what you need.

Read/write protection is a different topic. There are some things that you could do:

* Data can be visually hidden but will remain accessible to all users, in particular it is close to impossible to read-restrict it. * One can have form-based editing that uses a special field for the special data, and one can make it so that only some user groups will be able to edit this field (Semantic Forms extension). This is just a usage hint and no real write restriction since users can always edit the text. * Having some parts of the page write-protected for some user groups could be enabled by (a) protecting the page (with protection or namespace write restriction), and (b) transcluding the world-writable parts from a second page that is not protected. Not pretty but probably the best one can hope for in MediaWiki for this specific feature (which might not be needed in your case).

Only the input forms are specific to SMW (since they use the Semantic Forms extension). The rest of the tips is generic.

Here is another idea for a non-SMW solution: store the blobs on separate pages that are only transcluded to the right place for display (the names of the blob pages should be systematically constructed from the names of the page where they appear, of course). Then use the MediaWiki API to retrieve the data (or even bypass this and directly get the raw text from the wiki). Doing searches by category would need some other solution, and there will not be much support for combined criteria ("blobs of type x in category y"). If you know in advance that your data will always be restricted to one type of configuration file, then this might be a good solution. It would probably become messy if you also wanted to encode the "type" of the configuration, or have multiple configurations associated to one page. And of course the people would always edit the blobs on separate pages. This causes some inconvenience but also makes it simple for you to write such pages with an external script (you would not need to make any effort to find the right place within a long wiki page).

I think this is all I can say on this topic. If you have further SMW-related questions, feel free to ask on the SMW user list.

And I would also like to be able to have a script which does 'overwrite any blob of type x on page y with the following string'.

This is unrelated to any feature of SMW and would need another solution.

Markus

Hello,

Many pages in our mediawiki instance are generated by a shell script.

The generated text contains standard mediawiki syntax and dot graphs between <graphviz> </graphviz> tags.

Up to now we've been copying/pasting the generated text files into the mediawiki editor, but we are now looking for a way tell mediawiki to render those files as if they were stored as a regular page, calling other extensions as needed.

The include extensions we've tried so far cannot cope with graphviz tags; they simply include them as wikitext without calling others extension parsers.

Is there a way to simply tell mediawiki to load a text file and render it as if it were stored in the database

Regards, Cédric OLIVIER ********************************************************************************

IMPORTANT. Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi. Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message électronique est susceptible d'altération. A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié ; de même, il appartient au destinataire de s'assurer de l'absence de tout virus.    IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure of this message is prohibited.  Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified; additionally the recipient should ensure they are actually virus free.

********************************************************************************

colivier.ext@orange-ftgroup.com wrote:

Hello,

Many pages in our mediawiki instance are generated by a shell script.

The generated text contains standard mediawiki syntax and dot graphs between <graphviz> </graphviz> tags.

Up to now we've been copying/pasting the generated text files into the mediawiki editor, but we are now looking for a way tell mediawiki to render those files as if they were stored as a regular page, calling other extensions as needed.

The include extensions we've tried so far cannot cope with graphviz tags; they simply include them as wikitext without calling others extension parsers.

Is there a way to simply tell mediawiki to load a text file and render it as if it were stored in the database

Regards, Cédric OLIVIER

What about making the script *actually storing it* in the database? (ie. maintenance/importTextFile.php )

Could we please not quote an entire message just to make a two-line reply, *especially* when the reply is bottom-posted?

----- Original Message -----

If you don't mind parsing RDF....

It is an issue either way. Only diffeference is that top posting allows me to read the response without having to go hunt for it. The point is that the majority of a message should be new content.

----- Original Message -----

On Tue, Feb 15, 2011 at 8:33 AM, Steve VanSlyck s.vanslyck@spamcop.net

wrote:

...

Could we please not quote an entire message just to make a two-line

reply,

...

*especially* when the reply is bottom-posted?

---

One could say the same about top-posting ;)