Difference between revisions of "Template talk:Document"
(→Date issues: new section) |
|||
Line 68: | Line 68: | ||
== Date issues == | == Date issues == | ||
− | The new categories of <code>yyyy Publications</code> currently depend on the <code>DocProv</code> parameter <code>DateYear</code>. But both this and the related parameters of <code>DateDay, DateMonth</code> are not supported | + | The new categories of <code>yyyy Publications</code> currently depend on the <code>DocProv</code> parameter <code>DateYear</code>. But both this and the related parameters of <code>DateDay, DateMonth</code> are not supported by <Code>Form:Document</code> and in any case return an error unless all 3 parameters are completed. See [[Property:Has improper value for|here]] for the list of 58 pages currently affected. I was going to pitch in and start editing this list but it may be better to modify the template/form combination to take account of both cases. As things stand, any date entered using the form is not placed in any of the new categories - and I do agree the new categories are useful and involve no processing overhead. Thoughts please --[[User:Peter|Peter P]] ([[User talk:Peter|talk]]) 08:07, 7 December 2013 (GMT) |
+ | |||
+ | :Hmmm, missing data items are probably not going to go away. I've been leaving dates alone as I'm still undecided about them. If SMW can really deal gracefully with missing data items, e.g. "Nov 2013", then just |Date is good enough. However, I'm not sure it can, hence the 3 separate parameters. That is the safest method, since given 3 parameters, it's a cinch to make the full date, but not vice versa. It entails more programming but at least we have a chance to explicitly decide how to handle missing data items. Conclusion: | ||
+ | #I think I favor the 3 parameter solution unless SMW is proved effective at dealing with missing dates/months | ||
+ | #Providing missing data items is always good - some of the Document:s are randomly missing sources and/or dates | ||
+ | #Don't do any long and boring conversion jobs by hand. I'm coding a bot at the moment. [[User:Robin|Robin]] ([[User talk:Robin|talk]]) 08:26, 7 December 2013 (GMT) |
Revision as of 08:26, 7 December 2013
Contents
Mandatory
Would it be a good idea to use this on all items in the document: namespace?
Robin (talk) 05:22, 29 October 2013 (GMT)
- Yep. I think it would. Not sure how to force it though, bearing in mind there a lot of documents that pre-exist the template and don't currently incorporate it. A form for the template would be very useful though --Peter P (talk) 08:34, 29 October 2013 (GMT)
Processing Semantic Dates
Semantic wiki does seem to be able to parse dates for its own purposes. Is there a way to use it to convert a randomly formatted date into an ISO-formatted date, so this can be used, e.g. to assign a document to a "YYYY Publications" category?
Robin (talk) 09:08, 11 November 2013 (GMT)
- I'm impressed!!. There must be a way to use SMW parsing for precisely that purpose and the 'isdate' property is the logical one to do it since it simply identifies any old format as a semantically readable date. I do think it would be better to have a new property property:Publication date for the documents publication date field though. I'll create it anyway and it can be used if you agree. SMW has a LOT of potential methinks --Peter P (talk) 09:15, 11 November 2013 (GMT)
- In fact, thinking about it, it would probably be better to have a property Property:Has publication date because it would then be a simple matter to search on the year of the publication date, making a separate category for each publication year redundant --Peter P (talk) 12:24, 11 November 2013 (GMT)
SMW properties problem
Robin - have a look at Special:Properties
I knew by certain performance issues concerning the Jobs queue and the SMW factobox behaving irratically that a problem was building. I think I can understand why Wikipedia does not use SMW. I still think it is worth developing its use here, but I want to sort out those rogue properties and understand the irratic factbox issue before creating and using any additional ones --Peter P (talk) 18:23, 12 November 2013 (GMT)
DocProv use of the 'RED' Broken template is broken on Iframe pages
Have a looks at Document:Getting Access to the Secrets of the Osama Bin Ladin Kill and Document:During 1917 for examples --Peter P (talk) 09:55, 21 November 2013 (GMT)
Publication date fails
The Construction of ISO8601 dates fails when any of its 3 date components is missing. There are a lot of pages with 'Day' missing and their displayed 'publication date therefore shows an error. This is especially applies to pages with templates which themselves have been changed to include 'DocProv' - The 200YT template pages are an example. There may be others. --Peter P (talk) 07:45, 23 November 2013 (GMT)
Author - conditional statement
I've removed the #Ifexist statement from the author variable because it inhibits the Property:Is author. This way all documents will be browseable semantically by 'Author'. The downside is that Author 'Unknown' gets page-linked --Peter P (talk) 12:00, 27 November 2013 (GMT)
Author notes
I wonder whether these are needed in light of assigning all authors to a property of type "page". We could of course change it to type "text" and revert the template edits to include the "#Ifexist" conditions again. My feeling just now is that it is probably best to leave it as I just modified it (ie "Is author" has type page. It is then easy to create the right page and put any bio and other info in it. It would resolve a perennial dilemma I've wrestled with, namely when and if to assign as author to a category and if so whether or not to create a separate page. The way it is now seems much cleaner and intuitive to me. What do you think? --Peter P (talk) 15:30, 27 November 2013 (GMT)
AORAN + Subject
Good stuff Robin. Makes for a much better set of DocType properties.
Also I think it would be a good idea to declare up to 3 subjects (to begin with anyway) per document too - and make each a page link even if the page does not exist yet. This all has the makings of an impressive browsing and useful-info-finding syste. Will need to apply it to Files of category 'Doc' too. Next thing needs to be a form to enforce all this :-)) --Peter P (talk) 14:22, 28 November 2013 (GMT)
TODO List
I'm happy with how it's working out. No formatting in the pages themselves, do it all in templates - much cleaner. I suggest we keep tinkering with DocProv and see what other improvements we can find, then make a list of them and go through the Documents and do all the changes at once. Some topics to think about are
- Standardising doctypes
- Fixing "source" which combines 2 bits of info. Maybe add |SourceURL and use |Source as a name
- Something about original languages and translations
- A parameter |Occasion = |ImmediateCause = |WhatPromptedThis for why these documents came about. e.g. A death certificate tied to a death event
- |Location for speeches
- Publication date as distinct from creation date -- important for leaked documents etc.
There will still be some (rough) edge cases we can flag up and use to mull over any other work than needs doing. Robin (talk) 14:55, 28 November 2013 (GMT)
ToDo + General
There's not much I can add to what you've done and said already. Great piece of work. I agree all of the ToDo list. Also I notice you've started on the form. With so many parameters and consequent scope for doing something disruptive - for example, accidentally creating lists of properties, a good working form will be a major improvement too. Also, when near done, similar work on the FileProv template would be good. I've added a couple of properties to include much of the existing parameter content in the Sematic properties set up but there is scope for considerably more. It should apply to all files of category 'Doc' --Peter P (talk) 08:23, 2 December 2013 (GMT)
Date issues
The new categories of yyyy Publications
currently depend on the DocProv
parameter DateYear
. But both this and the related parameters of DateDay, DateMonth
are not supported by Form:Document
and in any case return an error unless all 3 parameters are completed. See here for the list of 58 pages currently affected. I was going to pitch in and start editing this list but it may be better to modify the template/form combination to take account of both cases. As things stand, any date entered using the form is not placed in any of the new categories - and I do agree the new categories are useful and involve no processing overhead. Thoughts please --Peter P (talk) 08:07, 7 December 2013 (GMT)
- Hmmm, missing data items are probably not going to go away. I've been leaving dates alone as I'm still undecided about them. If SMW can really deal gracefully with missing data items, e.g. "Nov 2013", then just |Date is good enough. However, I'm not sure it can, hence the 3 separate parameters. That is the safest method, since given 3 parameters, it's a cinch to make the full date, but not vice versa. It entails more programming but at least we have a chance to explicitly decide how to handle missing data items. Conclusion:
- I think I favor the 3 parameter solution unless SMW is proved effective at dealing with missing dates/months
- Providing missing data items is always good - some of the Document:s are randomly missing sources and/or dates
- Don't do any long and boring conversion jobs by hand. I'm coding a bot at the moment. Robin (talk) 08:26, 7 December 2013 (GMT)