Re: [Semediawiki-user] Going enterprise-grade

[Laurent A. <la...@al...>]

In an attempt to bridge both points of view (since I went through both
exercises of using SMW as a semantic wiki and a request/project tracking
system), let me add this :

If you want to capture encyclopedic knowledge, with the whole complexity of
relationships, context and rarely seen content management tools, SMW is
quite possibly the best solution out there (although I can see some
solutions catching up, they are not there yet).

If you need a robust agile development system, or a forum system, or a
project management system - you are better off setting up a separate tool
specialized in these areas.

SMW provides ways to approximate a simple version of these tools, and yes,
it does require jumping through hoops to handle pages names that are not
user friendly (generated automatically using the 'one step process'
described in Semantic Forms). If you are going to track tasks or requests,
you will want to have them named as 'REQ-123' or 'TASK-123' and it will
introduce issues when you query and display them for users.

But then again, I would advocate using SMW for what it does best (semantic
relationships between concepts) and develop bridges to specialized systems
(ticket tracking, request tracking, forums, etc).

There are plenty of ways to to that, such as using the MW API, exchanging
CSV or XML files using External Data extension to developing specialized
extensions (I saw a JIRA ticket extension for MW that anyone can use as a
base to develop similar bridges).

I don't think it is realistic to expect any system to perform well in any
type of application. In your examples with Ruby or Salesforces, I could
reverse the comment and say that these systems cannot easily be used to
create a full semantic solution as you can find with SMW. They can
approximate one, but they cannot match it.

There is a reason why toolboxes have more than just a hammer :)

- Laurent

On Wed, Aug 18, 2010 at 1:02 PM, Jan Schoonderbeek <ja...@sa...> wrote:

>  John, as I see it, you're approaching your problem with SMW from
> different angles, but not following any suitable one. I won't pretend to
> fully comprehend the problem, or having the "bestest" approach, but
> please allow me to make a few observations.
> 1) You have all sorts of data, and you've classified some of it, e.g.
> the document types. However I find no trace or hint of an information
> model: what data has what relation with what other piece of data, be
> they on the same page or not. SMW is about semantic relations; if you
> have no semantic relations between your bits of data, then you really
> have no use for SMW .
> 2) you talk about hundreds of little templates to manipulate data
> formats. That can't be right: SMW understands many data formats and can
> do the data formatting for you in most cases - including unit
> conversion. I'm almost tempted to believe you're not talking about data
> formats, but the lay-out and appearance of pieces of text. But even
> then, you could quite easily create a handful of templates that can do
> the presentation of data you feed it, depending on the semantic
> properties of said data, and call one of these general templates when
> you need data presentation. Thus, you could do this: call a template
> with parameters, the first of which contains the text to layout, e.g.
> the content of property "testplan-text" which is of type text. The
> second parameter could contain the content of another property, used to
> change the appearance of the text, e.g. property "testplan-status" - or
> simply one of a few predefined words that you'd test for within the
> template. Even more sophisticated layout tricks would probably mean more
> parameters to feed to the template.
> 3) your thinking on the pagename is very confusing. If you've determined
> that the pagename cannot depend on its content, why "should" it then be
> a number? and why would it need a prefix? Why cater for document type in
> the page name at all, if you could just put the page in a class of
> document types (with the additional bonus of reasoning capabilities on
> related document types)? On the other hand, a page represents an
> artefact in the wiki; I fail to see how you could not use some piece of
> human-readable text in them at page creation, that wouldn't prevent the
> transformations that that artefact could need in the future. But
> ofcourse I can't think too deeply about that without the information model.
> 4) you're talking about letting users make arbitrary relations between
> items. That's easy with SMW - on the page of item 1, insert [[relation
> xyz::item 2]]. It's only a bit inconvenient if you want to make that
> particular relation while you're in page of item 2 itself. However, if
> you'd check your information model, you'd probably already realize you'd
> need to create "relation zyx" that points the other way.
> 5) Then you say these relations need to be navigable - why? If I'm on a
> page representing item X, I can see all relations with all other items
> in the factbox, and/or you could show every relation wherever you want
> in the page in whatever fashion you want, and have it all clickable (to
> either the relation or the subject). Your navigable relations question
> hints at some other GUI or user requirement that you've not mentioned.
> And even then, it's easy creating a page that shows some set of
> relations, and allows you to drill down to the pages that are using (or
> used by) the relation. I've even created pages that update themselves
> whenever relations are added. And what management would users need to do
> on these relations, other than (un)assigning them to items? Semantic
> Forms can cater for most any of that work, with autocompletion helping
> users in their choices, and CategoryTree helping with assigning categories.
> 6) and then the most confusing bit. You start talking about web database
> applications and Rails-developed applications, as if they are equivalent
> to SMW. They are not. They may be used for the same purposes in some
> cases, but essentially you're comparing (more or less) generic
> development tools with a customizable application. This will work only
> if your requirements correlate strongly to those that the customizable
> application intended to fulfill. Would anyone be surprised if I said I
> cannot do large and complex spreadsheet calculations in Word because it
> lacks suitable functions and graphics representation? And that the
> calculation could much better be performed in programming language X?
>
> In an earlier mail, you took the SMW faq, promising flexible,
> collaborative data structures, and then started talking about competing
> with 'turnkey' applications, leaping without a word over the questions
> about fitnes-for-purpose, the use and usability of flexibility, and the
> disparity in costs and cost models between SMW and turnkey applications.
> This makes a skewed comparison. My take is: the MediaWiki plus SMW
> combination give you a semantic wiki, meaning you can do (limited)
> knowledge management within the realms of wikis; using extensions like
> Semantic Forms you can even go one step beyond wikis. However, I don't
> think people should be trying to use SMW way way further outside of this
> context, fail, and then somehow blame SMW or its developers for that
> failure.
>
> John, I would like to ask you: what are your requirements for your data
> management system; why did you believe SMW can fit the bill; and how
> have you checked that SMW can indeed fulfill your requirements?
>
> On 18/08/2010 16:03, John Arrowwood <John@Irie-Inc.com> wrote:
> > Now, allow me to describe a few requirements for such a system, and
> > you tell me how you would accomplish it using SMW:
> >
> > I need a number of different document types.
> > <snip>
> > Each document should have a page name that is not dependent on its
> > contents.  So, for example, if you have a defect, you should be able
> > to change the summary of the defect without effecting the page name.
> > This means that the page name should not be a string, it should be a
> > number.  But of course, you have over a dozen different document
> > types, so it can't JUST be a number, you need some kind of prefix.
> > Now, because the page name doesn't include anything human readable,
> > you can't just do basic queries, you need queries that actually
> > extract meaningful elements out of the pages.  But in order to display
> > something other than raw data, you can't just select properties, you
> > need to create a template to go with it.  With so many record types,
> > and with needing to display so many small pieces of data here, there,
> > and everywhere, you are going to have hundreds of templates that all
> > they do is manipulate the data format.  Something that the query
> > itself should be able to do.  Oh, and did I mention that you can't use
> > these templates to display data in tables or it breaks the Further
> > Results... functionality?
> >
> > For the most part, the system should allow any of those items to be
> > related to any other of those items, as the user sees fit.  Those
> > relationships should be navigable via a tree.  Those relationships
> > should be manageable in the most efficient user interface possible,
> > preferably by dragging and dropping to/from the tree.  How would you
> > do that with SMW?  If you can't do drag-and-drop, what kind of user
> > interface would you design to facilitate document relationships?
> >
> > Now, I would love to see SMW become the best thing since sliced
> > bread.  But I know it is not, currently.  SalesForce.com can build a
> > web database application in minutes what takes days to build in SMW.
> > An experienced Rails developer can build more feature-rich
> > applications in less time than it takes to build an equivalent in
> > SMW.  The one thing that SMW has that these others don't is the
> > integrated wiki.    That, by itself, will not be enough.
> >
> > In order to become a serious competitor, it is going to have to become
> > orders of magnitude faster and easier to develop applications in than
> > it already is.  Yes, it's pretty fast as-is, now.  But I've got a guy
> > who needs to be able to expand it, and he can't wrap his brain around
> > it.  I'm one of the best I know, and I struggle to make things work
> > because of all the quirks in the system.  And read through these lists
> > and count how many times the answer to a question is "you can't do
> > that."  Those are all signs that something has to be changed for the
> > better if SMW is ever to become a viable enterprise-level alternative,
> > and not just a really nifty toy.
> >
> > So that takes us back to Yaron's comment:  there needs to be funding!
> > If we could have one Scrum team working on this for a year, we could
> > likely go from zero to enterprise-grade.  But we aren't going to get
> > there based only on volunteer contributions working without standards,
> > working only on the parts they personally are most interested in.
> >
> > So, if we seriously want to accomplish what is written in the FAQ, we
> > need to start some kind of foundation, and start soliciting donations
> > to it.
> >
> > --
> > John Arrowwood
>
> --
> Jan "Saruman!" S.
> "I'm a stream of noughts and crosses in your R.A.M."
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Semediawiki-user mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>



-- 
- Laurent Alquier
http://www.linfa.net