On 16/04/11 02:37, Robert Murphy wrote: > OK, so then why are namespaces proliferating?
Robert, I think you have a valid point: one should not have extra namespaces if not really needed. There are good uses of namespaces, however, and we should not artificially avoid namespaces if these uses make sense. I don't think your point about "cluttering" is an SMW issue -- if namespaces impair the usability of some MediaWiki interface then this interface should be improved. For example, the "talk" namespace for all namespaces is an MW design issue that probably should get better UI integration (e.g. by making separate "Article search" and "Talk search" special pages with half the namespaces each). We have two kinds of uses for namespaces: * Layout: Template, Form, Filter specify how something should be formatted. * Content structure: Category, Property, Concept are part of the wiki's structure and provide useful (special) views on the data. Both kinds of pages are not primarily text content, and should thus not be searched by MW. For this they need to be separated somehow. The "structure" namespaces also look different from normal articles, and to achieve this we cannot rely on page content (a Property page can contain nothing but plain text and will still be a valid property that displays the browsing information). This explains why Property, Category, and Concept are separate. They cannot be merged into one without giving up functionality and clarity. The notion of a property is also very important from a user perspective. Renaming or collapsing this namespace would lead to major confusion. The only other namespace in SMW is Type. I think we could indeed remove the notion of types with pages entirely. Type articles display useful information but there is hardly a need to edit them. The only exception are custom unit conversions which currently have their own type -- this information could be moved to the property page (if conversions are used for many properties, then a template could be used). A new special page would be introduced to display the current additional information about types (lists of all properties). I do not see that SMW could remove any of its other two namespaces without causing confusion and needless hassle for upgrading users. Note that SMW has no further namespaces -- the others that you mention are related to extensions. The layout namespaces Form and Filter should also not be searched by default but they do not require special article display. When pages from these namespaces are used in the wiki, their (hoped for) content is always clear from the context -- the namespace does not add information there. But what should be done? Surely, Form and Filter should not be specified on any of the structural pages with special output, and they need to be separate from the main namespace (for not searching them). What remains is Template. But do you really think that it would be good to place form descriptions on template pages? I think this could confuse users. The only other option would be to combine Filter and Form into one namespace. Again, this could be confusing, and surely it makes it harder to update wikis that already have both namespaces. And it would only remove one namespace. So I don't see much of a realistic chance to make these things simpler without making them more difficult for users. Regards, Markus > > On Fri, Apr 15, 2011 at 4:48 PM, Smith, Tim <smith.t...@pg.com > <mailto:smith.t...@pg.com>> wrote: > > Being a member of a namespace does not imply that a resource is a > specific rdf:type (i.e. Property, Class, etc...). The rdf:type > property should be used to ascertain the type of a resource. > > Tim > > > -------------------------- > Sent using BlackBerry > > > *From*: Robert Murphy [mailto:mrandmrsmur...@gmail.com > <mailto:mrandmrsmur...@gmail.com>] > *Sent*: Friday, April 15, 2011 07:10 PM > *To*: Jeroen De Dauw <jeroended...@gmail.com > <mailto:jeroended...@gmail.com>> > *Cc*: Semantic MediaWiki Developers List > <semediawiki-devel@lists.sourceforge.net > <mailto:semediawiki-devel@lists.sourceforge.net>> > *Subject*: Re: [SMW-devel] Namespace Clutter > > OK, 2 namespaces: fundamentals and derived things. TYPE's are not > defined in terms of anything else. Property's, Form's, Filter's and > Concept's all have definitions written on them.. > > On Fri, Apr 15, 2011 at 4:02 PM, Jeroen De Dauw > <jeroended...@gmail.com <mailto:jeroended...@gmail.com>> wrote: > > Hey, > > You cannot put all the stuff in one namespace; how would you > then know what it actually is? For example properties show a > list of pages on which they are used (plus the value they have > there). This information would need to be represented in another > way if it all was in a single namespace. The current approach > makes it very obvious what the thing is, a property, type or > something else. Also, it avoids naming conflicts. I honestly > don't see why you'd put everything in a single ns, it seems it'd > only cause issues and not provide any benefits. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. > -- > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is > a top > priority.Virtualization can reduce costs, simplify management, > and improve > application availability and disaster protection. Learn more > about boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > <mailto:Semediawiki-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and > improve > application availability and disaster protection. Learn more about > boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > <mailto:Semediawiki-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > > > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
