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