[[Category:MyCategory|DisplayThisInstead]] Is rendered as Categories: MyCategory instead of Categories: DisplayThisInstead
i.e. the syntax is the same as piped link but is in fact a category sort key.
It'd be more consistent to use [[Category:MyCategory|DisplayThisInstead|MySortKey]]
Has this issue been discussed before? Would there be any problems introducing this change?
Cheers,
On 4/6/06, HumanCell .org humancell@gmail.com wrote:
[[Category:MyCategory|DisplayThisInstead]]Is rendered as Categories: MyCategory instead of Categories: DisplayThisInstead
i.e. the syntax is the same as piped link but is in fact a category sort key.
It'd be more consistent to use [[Category:MyCategory|DisplayThisInstead|MySortKey]]
Off the top of my head, and after only a few sips of coffee this morning, I think that it would be more consistent to use:
[[Category:MyCategory|MySortKey|DisplayThisInstead]]
which would be consistent with the way pipes are used to parameterize Image links e.g. [[Image:MyImage|thumb|Cool caption]]
It would also have the benefit of not breaking existing pages which don't use this new syntax.
On the other hand allowing alternate presentations of category links raises some consistency issues that might make it inadvisable.
-- Rick DeNatale
Visit the Project Mercury Wiki Site http://www.mercuryspacecraft.com/
On Thursday 06 April 2006 14:05, Rick DeNatale wrote:
On 4/6/06, HumanCell .org humancell@gmail.com wrote:
[[Category:MyCategory|DisplayThisInstead]]Is rendered as Categories: MyCategory instead of Categories: DisplayThisInstead
i.e. the syntax is the same as piped link but is in fact a category sort key.
It'd be more consistent to use [[Category:MyCategory|DisplayThisInstead|MySortKey]]
Off the top of my head, and after only a few sips of coffee this morning, I think that it would be more consistent to use:
[[Category:MyCategory|MySortKey|DisplayThisInstead]]which would be consistent with the way pipes are used to parameterize Image links e.g. [[Image:MyImage|thumb|Cool caption]]
It would also have the benefit of not breaking existing pages which don't use this new syntax.
On the other hand allowing alternate presentations of category links raises some consistency issues that might make it inadvisable.
Yes, I agree with this point. The inline version [[:Category:MyCategory| DisplayThisInstead]] works, and this is where you need alternative labels. The alternative label is meant to facilitate inserting links into the article text, not to obscure/rename the target. Why change the category name as displayed at the page bottom? If there are really multiple senses for some category, then it might be better to make two categories, possibly related in a meaningful way in the category hierarchy.
On Thu, Apr 06, 2006 at 02:56:21PM +0200, Markus Kr?tzsch wrote:
Yes, I agree with this point. The inline version [[:Category:MyCategory| DisplayThisInstead]] works, and this is where you need alternative labels. The alternative label is meant to facilitate inserting links into the article text, not to obscure/rename the target. Why change the category name as displayed at the page bottom? If there are really multiple senses for some category, then it might be better to make two categories, possibly related in a meaningful way in the category hierarchy.
I would prefer a way to be able to change how the link back to the article appears on the Category page itself - not just how it is sorted in that list...
Tony
On 06/04/06, Rick DeNatale rick.denatale@gmail.com wrote:
[[Category:MyCategory|MySortKey|DisplayThisInstead]]which would be consistent with the way pipes are used to parameterize Image links e.g. [[Image:MyImage|thumb|Cool caption]]
It would also have the benefit of not breaking existing pages which don't use this new syntax.
Yes, I agree that is a clear advantage - don't want to go breaking existing pages.
On the other hand allowing alternate presentations of category links raises some consistency issues that might make it inadvisable.
Well I'd rather not, but here's why I think it is necessary... and if anyone can think of a better way of doing the following I'd be grateful if you could let me know.
- I have a database of 10,000+ chemical compounds and would like one article per compound. - Compounds are related hierarchically e.g. "methane" is an "organic compound" which in turn is a "molecular entitity" (cf taxonomy/ontology) - Compounds can have ugly names like "(+)-cis-3,4-dihydrophenanthrene-3,4-diol"
Current approach: - each compound is a category with three parts: 1) a definition of the compound and its properties 2) a list of sub-categories 3) links to super-categories - make the article title a unique identifier (e.g. CHEBI15386) to avoid the ugly punctuation - make category links meaningful to users [[Category:CHEBI15836|Organic aromatic compounds]] replaces the ID with more meaningful text
Any thoughts? Are the issues just specific to my case or are there more general issues at stake?
Cheers.
PS. Just found Semantic MediaWiki which looks very interesting.
On Thursday 06 April 2006 20:47, HumanCell .org wrote:
On 06/04/06, Rick DeNatale rick.denatale@gmail.com wrote:
[[Category:MyCategory|MySortKey|DisplayThisInstead]]which would be consistent with the way pipes are used to parameterize Image links e.g. [[Image:MyImage|thumb|Cool caption]]
It would also have the benefit of not breaking existing pages which don't use this new syntax.
Yes, I agree that is a clear advantage - don't want to go breaking existing pages.
On the other hand allowing alternate presentations of category links raises some consistency issues that might make it inadvisable.
Well I'd rather not, but here's why I think it is necessary... and if anyone can think of a better way of doing the following I'd be grateful if you could let me know.
- I have a database of 10,000+ chemical compounds and would like one
article per compound.
- Compounds are related hierarchically e.g. "methane" is an "organic
compound" which in turn is a "molecular entitity" (cf taxonomy/ontology)
- Compounds can have ugly names like
"(+)-cis-3,4-dihydrophenanthrene-3,4-diol"
Current approach:
- each compound is a category with three parts:
- a definition of the compound and its properties
- a list of sub-categories
- links to super-categories
- make the article title a unique identifier (e.g. CHEBI15386) to
avoid the ugly punctuation
- make category links meaningful to users
[[Category:CHEBI15836|Organic aromatic compounds]] replaces the ID with more meaningful text
Any thoughts? Are the issues just specific to my case or are there more general issues at stake?
Cheers.
PS. Just found Semantic MediaWiki which looks very interesting.
Yes, this could indeed be a nice use case for this extension. It gives you some more freedom for describing relationships between your articles, and maybe there are also other properties that one could associate with some compounds (e.g. molecular mass).
If the taxonomy is all that you need, categories could also be a sufficient solution -- the displayed article names really seem to be your only problem here. Would it help to create redirects between articles with nice names and articles with ugly names (note that you would also have to use "plus" for "+" etc.)? If the category mechanism is used only for browsing, then this might already suffice.
PS. Just found Semantic MediaWiki which looks very interesting.
Yes, this could indeed be a nice use case for this extension. It gives you some more freedom for describing relationships between your articles, and maybe there are also other properties that one could associate with some compounds (e.g. molecular mass).
Easy export of RDF is one obvious advange, but I'm not sure what other benefits there are of using the extension. Here is an example of any entry (no taxonomic information is shown): http://www.humancell.org/index.php/CHEBI15334
If the taxonomy is all that you need, categories could also be a sufficient solution -- the displayed article names really seem to be your only problem here. Would it help to create redirects between articles with nice names and articles with ugly names (note that you would also have to use "plus" for "+" etc.)? If the category mechanism is used only for browsing, then this might already suffice.
I agree, I had thought of using redirects too and I think this is the way to go.
On Monday 10 April 2006 04:33, HumanCell .org wrote:
PS. Just found Semantic MediaWiki which looks very interesting.
Yes, this could indeed be a nice use case for this extension. It gives you some more freedom for describing relationships between your articles, and maybe there are also other properties that one could associate with some compounds (e.g. molecular mass).
Easy export of RDF is one obvious advange, but I'm not sure what other benefits there are of using the extension.
As you have seen, the extension currently is in development. Right now it is mostly useful if you have external software to work on (parts of) your data. In this case, you could use the RDF export to reuse wiki-data elsewhere, e.g. in some search or statistics service. For instance we have an (experimental) external service set up where you can ask advanced queries over the data, but this part is Java at the moment. Improved non-Java internal search functions are planned, but not included in the current version yet.
Here is an example of any entry (no taxonomic information is shown): http://www.humancell.org/index.php/CHEBI15334
The data I see there is of course highly specific, and I am not sure how a search engine for such structures should even look like. So the bottleneck for processing this data might not be the task of getting it into a standard format like RDF, but to find a usable application that allows you to do thing like to search for certain (implicit) chemical/structural features in your compound base. Since you work with templates, annotation can actually be done without too much effort by just evaluating the template (as in the German "Personendaten" project). Semantic MediaWiki can also be used to annotate templates, so you need not bother with annotating the articles themselves.
If the taxonomy is all that you need, categories could also be a sufficient solution -- the displayed article names really seem to be your only problem here. Would it help to create redirects between articles with nice names and articles with ugly names (note that you would also have to use "plus" for "+" etc.)? If the category mechanism is used only for browsing, then this might already suffice.
I agree, I had thought of using redirects too and I think this is the way to go.
mediawiki-l@lists.wikimedia.org