![]() For that reason, similarly to arrays, coordinates in Cargo have special handling for both storage and querying. Like arrays, coordinates are not well-supported overall by relational databases. File - holds the name of an uploaded file or image in the wiki (similar to Page, but does not require specifying the "File:" namespace).Searchtext - holds text that can be searched on, using the "MATCHES" command.Wikitext - holds longer text that is meant to be parsed by the MediaWiki parser.Wikitext string - holds a short text that is meant to be parsed by the MediaWiki parser.Coordinates - holds geographical coordinates.Boolean - holds a Boolean value, whose value should be 1 or 0, or 'yes' or 'no'.Start datetime, End datetime - work like Start date or End date, but include a time.A table can hold either no Start date and no End date field, or exactly one of both Start date, End date - Similar to Date, but are meant to Hold the beginning and end of some duration.Text - holds standard, non-wikitext text intended for longer values. ![]() String - holds standard, non-wikitext text.Page - holds the name of a page in the wiki.The following types are predefined in Cargo: The field description must start with the type of the field, and in many cases it will simply be the type. Should there be a "19th century" category for each city covered in the wiki, even those with only one or two sculptures to their name? And, conversely, should cities with many sculptures be further split up, say by the sculpture's art style? Or should the style be tagged with a separate category? These are hard questions, without necessarily any good answer. And if you're expecting users to do it, they need to be given precise instructions on how to add categories and what the categories should be named (should it be "Kaunas, Lithuania" or just "Kaunas"?), and in general, what the ideal data structure should be. In the second case, the list (on the category page) is generated automatically, but the category tags have to be added painstakingly to each page. However, they both have problems: the first option, manually compiling a list, takes a lot of work, and requires modifying the list each time a new page is added that belongs on that list (or when some error is discovered). For all the power of SMW, covering it in depth led to the first edition of this book getting into topics that seem out of scope for a MediaWiki reference book, like RDF and n-ary data.īoth types of actions are done on Wikipedia all the time, and on many other wikis as well. And to really understand SMW requires understanding the idea of semantic triples, a foreign concept to most, and one that's trickier than it first seems, especially when you get into multi-dimensional data. To use SMW requires learning a whole syntax for querying data, and requires creating and maintaining many (potentially thousands) of data structure wiki pages. To make full use of SMW requires installing about 15 (!) extensions: library-style extensions that SMW makes use of, as well as extensions that add necessary additional functionality, like Semantic Compound Queries. ![]() I created Cargo in large part because I felt that Semantic MediaWiki was too complicated to become the mass-market technology that it deserved to be. In truth, I believe that my interests as a programmer an as an author are aligned here.
0 Comments
Leave a Reply. |