MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "TouW-dag_juni_2013_workshop",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "64": {
                "pageid": 64,
                "ns": 0,
                "title": "Rule Style 2019",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "This page holds the data sets and research results from the paper ''\"Rule Style: patterns of and extensions to semantic browser style specification for business rule violations\"'', which is now submitted for publication. \n\n'''Compressed source materials: ''[http://is.cs.ou.nl/OWF/files/RuleStyle2019/RuleStyle2019.zip RuleStyle2019.zip]'''''"
                    }
                ]
            },
            "4": {
                "pageid": 4,
                "ns": 0,
                "title": "Semantic Friendly Forms",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "= Description =\n\nSemantic Friendly Forms is an extension on top of Semantic Forms and Semantic MediaWiki. If offers two categories of functions:\n\n* Form-based editing of existing properties, templates and forms (before forms interfaces could only create these).\n* Additional properties from the Semantic Web, which here influence the generation of Semantic Forms interfaces.\n\nSemantic Friendly Forms is the result of a [http://www.studieaanbod.ou.nl/is-bin/INTERSHOP.enfinity/eCS/Store/nl/-/EUR/DisplayProductInformation-Start;?ProductSKU=T61327 Bachelors student group project] at the [http://www.ou.nl Open Universiteit]. Its creators are Rens te Kloese, Henri Gerrits and Mark Rotteveel.\n\nMore information about Semantic Friendly Forms and its use is available in the [http://is.cs.ou.nl/OWF/files/Presentatie_SFF.ppt Semantic Friendly Forms student project final slides (in Dutch)].\n\n= Code and download =\n\nYou can download the Semantic Friendly Forms code in this compressed files:\n\n* http://is.cs.ou.nl/OWF/files/SemanticFriendlyFormsV0.5.zip\n\n= Installation =\n\n== Requirements ==\n\nSemantic Friendly Forms (SFF) requires the following:\n\n* [http://www.mediawiki.org/wiki/MediaWiki MediaWiki], versions 1.14.0 to 1.15.1\n* [http://semantic-mediawiki.org/wiki/Semantic_MediaWiki Semantic MediaWiki], versions 1.4.2 to 1.4.3\n* [http://www.mediawiki.org/wiki/Extension:Semantic_Forms Semantic Forms], version 1.8.5\n* [http://www.mediawiki.org/wiki/Extension:ParserFunctions ParserFunctions], version 1.1.1\n\nThese include the latest versions as of the date of publication of SFF.  Please refer to the installation/update documentations provided by MediaWiki and these extensions.  SFF has not been tested with newer or older versions and therefore may not work as expected.\n\n== Installation process ==\n\nInstallation is as follows:\n\n# Unzip the file [http://icommas.ou.nl/lru/OWLwikiForms/SemanticFriendlyFormsV0.5.zip SemanticFriendlyFormsV0.5.zip] into the 'extensions' of your MediaWiki installation.\n# Add the following line to MediaWiki\u008f\u00b2s LocalSettings.php file (found in the MediaWiki installation directory):<br/><code>require_once('extensions/SemanticFriendlyForms/SFF_Settings.php');</code>\n# Check the SFF version number on the 'Version' special page to verify that the installation was successful.\n\n= Create or edit properties =\n\n==Introduction==\n\nIn the Semantic Forms extension (SF), users can use a form based interface to create the article for semantic properties.  It lets the user enter the values for the meta properties ''has type'' and ''allows value''.  When creating the article, SF generates a default wikitext containing these meta properties as annotated wiki links.  The user can then freely change the wikitext using the regular editing functions.\n\nHowever, if the user wishes to make changes to the meta properties'' values, he or she will have to do this in the raw links in the wikitext as well; there is no friendly form to assist in the editing process.  If the user uses the creation process to ''edit'' the meta properties, the existing article is overridden by the newly generated article, so that all user edits to the existing wikitext will be lost.\n\nThe Semantic Friendly Forms extension (SFF) augments SF by adding such a facility. When the user requests to edit an existing property article, SFF displays a form for the meta properties.  The current (saved) values are already inserted in the appropriate entry fields.  After the user edits the values and presses ''Save page'', SFF updates the article text to reflect these changes, while maintaining any (manual) changes to the wikitext itself, including meta properties that could have been added by other extensions.\n\nSFF also adds some meta properties of its own; see below for further information.\n\nThe following meta properties can be edited:\n\n* The ''Has type'' meta property ([http://semantic-mediawiki.org/wiki/Property:Has_type-http://semantic-mediawiki.org/wiki/Property:Has_type])\n* The ''Has default form'' meta property ([http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Pointing_red_links_to_.27add_data.27_form-http://www.mediawiki.org/wiki/Extension:Semantic_Forms])\n* The ''Allows value'' meta property ([http://semantic-mediawiki.org/wiki/Property:Allows_value-http://semantic-mediawiki.org/wiki/Property:Allows_value])\n* The ''Has range'' meta property (SFF)\n* The ''Has domain'' meta property (SFF)\n* The ''Is inverse of'' meta property (SFF)\n* The ''Is symmetric'' meta property (SFF)\n* The ''Has label'' meta property (SFF)\n* The ''Has comment'' meta property (SFF)\n\nBecause of a different implementation of the ''Allows value'' meta property, new property articles should be created with the new ''Create a property'' special page added by SFF instead of the ''Create a property'' special page defined by SF.  Similarly, the new meta properties added by SFF are not available in the SF special page.  See paragraph 2.9 for an explanation of the differences in the ''Allows value'' implementation, and paragraph 3.2 for a guide how to create a new property.\n\nSemantic properties used in a wiki are not required to have a property article (''used but not defined'').  Conversely, not all semantic properties that have an article are used in the wiki (''defined but not used'').  SFF is able to work with these situations as well.\n\n==Supported meta properties==\n\nSFF supports a number of meta properties.  The following paragraphs provide further specific details for each.  To avoid confusion as much as possible, the meta properties are always denoted as ''meta property'', while the ''regular'', user-defined semantic properties are simply denoted as ''property''.\n\n===''Has type''===\n\nAs in SF, the user selects the type from a pull-down menu.  Variations such as alternate text and multiple values are not supported by the edit form.\n\nIn case the ''Has type'' meta property is used more than once in a property article, only the first occurrence will be available for editing by form.\n\nCustom data types are presently not supported.\n\n===''Has range''===\n\nThis meta property is predefined by SFF, and is largely based on rdfs:range<sup> </sup>.  The multi-valued ''Range'' field on the special page is used to enter values for this meta property.  Use commas to separate the individual values (category names).\n\nThe semantics of the ''Has range'' meta property is as follows: if a property p has one or more ''Has range'' meta properties, each referring to a category, then each value assigned to property p in an article is assumed to refer to an article that is a member of at least one of those categories.\n\nMore precisely:\n\nhttp://is.cs.ou.nl/OWF/files/RangeFormula.png\n \nWhere:\n\nA<sub>U</sub> =\tSet of all articles in the wiki\n<br/>P<sub>U</sub> =\tSet of all properties defined (i.e., there is an article with that name in the ''Property'' namespace, or it has been predefined by a wiki extension, or both) or used (i.e., there is at least one article that has a (possibly empty) value explicitly assigned to a property with that name)\n<br/>p.range =\tThe set of categories in the ''Has range'' meta property of property p.\n<br/>a.memberOf(c) =\tTrue if and only if article a is a member of category c, i.e., it contains a link of the form <nowiki>[[</nowiki>Category:''c''<nowiki>]]</nowiki>.\n\nIf a property''s ''Has range'' is not defined explicitly, it is assumed to be equal to the imaginary universal category of which all articles within the wiki are a member.\n\nNote that rdfs:range has different semantics in case of multiple values.\n\nThe additional semantics provided by ''Has range'' can be used elsewhere in SFF (for example, in autocompletion where an article with the property is being edited by form), and should be available for export in RDF(S) format (the conversion to the rdfs:range counterpart has not yet been implemented).\n\nThe field supports autocompletion on the first value, providing suggestions from the category names currently defined in the wiki.\n\nInternally, SFF wraps these values in a ''#range'' parser function call.  Upon displaying the property article, the parser function expands to a list of ''Has range'' annotated links.\n\nThe values are assumed to be members of the ''Category'' namespace.  However, SFF automatically adds the ''Category:'' prefixes to the values upon expansion of the parser function, so they should not be entered by the user.  The categories entered here are not required to actually exist.  This allows for a flexible semantic wiki development sequence for the user, while moving the responsibility for making sure that the wiki is semantically correct to the user as well.\n\nIn case the ''#range'' parser function call is used more than once in an article, only the first occurrence will be available for editing by form.  Likewise, individual ''Has range'' annotated links that may appear in the article text will not be available for editing by form.  Nevertheless, all ''#range'' parser function calls and ''Has range'' annotated links are used semantically.\n\n===''Has domain''===\n\nThis meta property is predefined by SFF, and is largely based on rdfs:domain<sup> </sup>.  The multi-valued ''Domain'' field on the special page is used to enter values for this meta property.  Use commas to separate the individual values (category names).\n\nThe semantics of the ''Has domain'' meta property is as follows: if a property p has one or more  ''Has domain'' meta properties, each referring to a category, then each article that is a member of at least one of those categories is expected to have property p.  If such an article does not have an explicit value for that property, then the default value, if any, may be assumed.\n\nMore precisely:\n\nhttp://is.cs.ou.nl/OWF/files/DomainFormula.png\n \nWhere:\n\nA<sub>U</sub> =\tSet of all articles in the wiki\n<br/>P<sub>U</sub> =\tSet of all properties defined (i.e., there is an article with that name in the ''Property'' namespace, or it has been predefined by a wiki extension, or both) or used (i.e., there is at least one article that has a (possibly empty) value explicitly assigned to a property with that name)\n<br/>p.domain = \tThe set of categories in the ''Has domain'' meta property of property p.\n<br/>a.memberOf(c) =\tTrue if and only if article a is a member of category c, i.e., it contains a link of the form <nowiki>[[</nowiki>Category:''c''<nowiki>]]</nowiki>.\n\nIf a property''s ''Has domain'' is not defined explicitly, it is assumed to be equal to the imaginary universal category of which all articles within the wiki are a member.\n\nNote that rdfs:domain has different semantics in case of multiple values.\n\nThe additional semantics provided by ''Has domain'' can be used elsewhere in SFF (for example, in creating templates for a given category, prefilling the form with all the properties that have that category as part of their domain), and should be available for export in RDF(S) format (the conversion to the rdfs:domain counterpart has not yet been implemented).\n\nThe field supports autocompletion on the first value, providing suggestions from the category names currently defined in the wiki.\n\nInternally, SFF wraps these values in a ''#domain'' parser function call.  Upon displaying the property article, the parser function expands to a list of ''Has domain'' annotated links.\n\nThe values are assumed to be members of the ''Category'' namespace.  However, SFF automatically adds the ''Category:'' prefixes to the values upon expansion of the parser function, so they should not be entered by the user.  The categories entered here are not required to actually exist.\n\nIn case the ''#domain'' parser function call is used more than once in an article, only the first occurrence will be available for editing by form.  Likewise, individual ''Has domain'' annotated links that may appear in the article text will not be available for editing by form.  Nevertheless, all ''#domain'' parser function calls and ''Has domain'' annotated links are used semantically.\n\n===''Is inverse of''===\n\nThis meta property is predefined by SFF, and is largely based on owl:inverseOf<sup> </sup>.  The multi-valued ''Inverse of'' field on the special page is used to enter values for this meta property.  Use commas to separate the individual values (property names).\n\nThe semantics of the ''Is inverse of'' meta property is as follows: if a property p is the inverse of another property q, then if there is an article a that has a value for property q that equals article b, then article b can be assumed to have property p with a value equal to article a.\n\nMore precisely:\n\nhttp://is.cs.ou.nl/OWF/files/InverseFormula.png\n \nWhere:\n\nA<sub>U</sub> =\tSet of all articles in the wiki\n<br/>P<sub>U</sub> =\tSet of all properties defined (i.e., there is an article with that name in the ''Property'' namespace, or it has been predefined by a wiki extension, or both) or used (i.e., there is at least one article that has a (possibly empty) value explicitly assigned to a property with that name)\n<br/>p.inverseOf(q) =\tTrue if and only if q is an element of the set of properties in the ''Is inverse of'' meta property of property p.\n\nNote that the ''Is inverse of'' meta property is not symmetric: p.isInverseOf(q) does not imply q.isInverseOf(p), for example, ''Has child'' is the inverse of ''Has mother'', but not the other way around.\n\nNote also that the domain and range of either property are not taken into account in the above definition.  A future extension might use a stricter semantic interpretation of the ''Is inverse of'' meta property.\n\nThe additional semantics provided by ''Is inverse of'' can be used elsewhere in SFF (for example, in displaying the implied properties in an infobox; currently not implemented), and should be available for export in RDF(S) format (the conversion to the owl:inverseOf counterpart has not yet been implemented).\n\nThe field supports autocompletion on the first value, providing suggestions from the property names currently defined or used in the wiki.\n\nInternally, SFF wraps these values in a ''#inverse of'' parser function call.  Upon displaying the property article, the parser function expands to a list of ''Is inverse of'' annotated links.\n\nThe values are assumed to be members of the ''Property'' namespace.  However, SFF automatically adds the ''Property:'' prefixes to the values upon expansion of the parser function, so they should not be entered by the user.  The properties entered here are not required to actually exist.\n\nIn case the ''#inverse of'' parser function call is used more than once in an article, only the first occurrence will be available for editing by form.  Likewise, individual ''Is inverse of'' annotated links that may appear in the article text will not be available for editing by form.  Nevertheless, all ''#inverse of'' parser function calls and ''Is inverse of'' annotated links are used semantically.\n\n===''Is symmetric''===\n\nThis meta property is predefined by SFF, and is largely based on owl:SymmetricProperty<sup> </sup>.  It has a boolean type, meaning that the only allowable values are ''true'' and ''false''.\n\nThe semantics of the ''Is symmetric'' meta property is as follows: if a property p is symmetric, then if there is an article a that has a value for this property that equals an article b, then article b is implied to have property p with a value equal to article a.\n\nMore precisely:\n\nhttp://is.cs.ou.nl/OWF/files/SymmetricFormula.png\n \nWhere:\n\nA<sub>U</sub> =\tSet of all articles in the wiki\n<br/>P<sub>U</sub> =\tSet of all properties defined (i.e., there is an article with that name in the ''Property'' namespace, or it has been predefined by a wiki extension, or both) or used (i.e., there is at least one article that has a (possibly empty) value explicitly assigned to a property with that name)\n<br/>p.symmetric = \tTrue if and only if the ''Is symmetric'' meta property of property p is true.\n\nOr in other words, if a property is symmetric then it is the inverse of itself:\n \nIf the ''Is symmetric'' meta property is not defined for a given property, it is assumed to be ''false''.  If a property article has multiple (contradicting) occurrences of this meta property, the semantics are undefined and may lead to incorrect behavior.  This situation should therefore be avoided.\n\nNote also that the domain and range of the property are not taken into account in the above definition.  A future extension might use a stricter semantic interpretation of the ''Is symmetric'' meta property.\n\nThe additional semantics provided by ''Is symmetric'' can be used elsewhere in SFF as the special case of a property that is the inverse of itself, and should be available for export in RDF(S) format (the conversion to the owl:SymmetricProperty counterpart has not yet been implemented).\n\nThe meta property is displayed as a group of radio buttons, providing a choice between three values: ''yes'', ''no'' and ''not defined''.  The first two will insert an annotated ''Is symmetric'' link in the property article, with values ''true'' and ''false'', respectively.  The ''not defined'' option will not insert any annotated link in the property article (or remove any previous one if an existing property article is being edited), indicating that the default value for this meta property (i.e., false) should be used instead.\n\n===''Has label''===\n\nThis meta property is predefined by SFF, and is largely based on rdfs:label<sup> </sup>.  It has a text type, meaning that any text can be used.\n\nThe ''Has label'' meta property has no semantics.  It is intended to be a (short) human-readable version of the property name.  It can be used elsewhere in SFF (for example, in suggesting default field labels for properties when creating or editing a template), and should be available for export in RDF(S) format (the conversion to the rdfs:label counterpart has not yet been implemented).  Because of its use in SFF, t is recommended to provide only a brief text.  The ''Has comment'' meta property should be used if a longer description is desired as well.\n\nIf the ''Has label'' meta property is not defined for a given property, a default value may be assumed depending on the application.  For example, the property name could be used as the default value when creating a template, while in an RDF(S) export, there would be no default value, and the meta property would not be present in the file.  If a property article has multiple occurrences of this meta property, this may lead to incorrect behavior.  This situation should therefore be avoided.\n\n===''Has comment''===\n\nThis meta property is predefined by SFF, and is largely based on rdfs:comment<sup> </sup>.  It has a text type, meaning that any text can be used.\n\nThe ''Has comment'' meta property has no semantics.  It is intended to be a human-readable description of the property.  It can be used elsewhere in SFF (for example, as tooltips on property names; this has not been implemented yet), and should be available for export in RDF(S) format (the conversion to the rdfs:comment counterpart has not yet been implemented).\n\nIf the ''Has comment'' meta property is not defined for a given property, then the property simply has no comment text.  If a property article has multiple occurrences of this meta property, this may lead to incorrect behavior.  This situation should therefore be avoided.\n\n===''Has default form''===\n\nAlthough this meta property is used by SF, it is not prompted for in the SF Create a property special page in older versions.  SFF adds this as a convenience.  SFF will add the ''Form:'' namespace prefix to the value entered by the user in the generated link, so this should not be entered by the user.  The form is not required to exist.\n\nRefer to SF''s documentation for further information.\n\nIn case the ''Has default form'' meta property is used more than once in an article, only the first occurrence will be available for editing by form.\n\n===''Allows value''===\n\nThis is implemented differently from SF.  In SF, when the user enters a comma separated list of allowed values, the extension will generate an unordered (bulleted) list of ''Allows value'' wiki links.  Editing this list with a form would require a complicated interface, in particular for adding and removing allowed values.  To overcome this, SFF places the allowed values in a ''#allows values'' parser function call, where the allowed values are passed as parameters.  This parser function was added by SFF.  Upon displaying the property article, the parser function expands to the same bulleted list as generated by SF.\n\nRefer to SF''s documentation for further information.\n\nAs a result of the above, allowed values in property articles generate by SF will not be recognized and therefore not available for editing by form in SFF.  It is strongly recommended to generate property articles using the SFF ''Create a property'' special page described below instead.\n\n==Workflow==\n\n===Existing properties===\n\nUsed properties are semantic properties that have been used in one or more pages in the wiki.  Defined properties are semantic properties that have an article in the ''Property'' namespace, or that have been predefined by semantic wiki extensions, or both.  Properties that are either used and/or defined shall be referred to ''existing'' properties in this article.\n\nThere are two basic paths to edit an existing property with a form:\n\n# From Special pages, choose ''Edit a property'' (under the Semantic Friendly Forms heading).  A list of existing properties is displayed.  Choosing one of these will bring the user to the ''Create or Edit a Property'' screen.\n# When viewing a property article, either an existing article or the page that says that no article for the property has yet been defined, an ''edit with form'' tab appears at the top.  Selecting this tab will bring the user to the ''Create or Edit a Property'' screen.\n\nIn case the property is already defined (i.e., a property article exists), the values for the meta properties as defined in the article are displayed in the form and available for editing.  Otherwise, a blank ''create'' form is displayed where the user can enter the values for the meta properties.  In either case, the property''s name is already entered.  If it is changed by the user, a new article will be created under the new name, while the existing article remains unchanged.\n\nPress ''Save page'' to save the changes, or ''Preview'' to preview the changes without saving.  The Cancel link moves the user to the property article page, while discarding any changes made.\n\n===New properties===\n\nIt is strongly recommended to not use the SF special page for creating new articles.  Instead, go to the ''Create a property'' special page under the Semantic Friendly Forms heading.  Follow the ''new'' link near the top of the page to go to the form.\n\nThis will bring the user to the create property screen.  The same ''create'' form is displayed as in the case of a used but not defined property.  The user is required to enter a name.\n\nPress ''Save page'' to generate and save the new article, or ''Preview'' to preview the article without saving.  The Cancel link returns the user to the ''Create or Edit a Property'' page, while discarding any information entered.\n\n==Article generation and update==\n\n===Undefined properties===\n\nFor previously undefined semantic properties, i.e., semantic properties for which no article yet exists, SFF generates the article based on the data entered by the user.  For each meta property value entered, SFF looks up the surrounding default text from a message file appropriate for the user''s preferred language.  These message files can only be changed by system administrators.  For fields that are left empty, no text is generated.\n\n===Defined properties===\n\nFor defined semantic properties, i.e., properties for which an article already exists, SFF attempts to retain the existing surrounding wikitext as much as possible while updating the meta property values.\n\n# If a meta property is added, i.e., the user entered a value where there was no value provided in the original article, the relevant default text from the message file (as described under Undefined properties) is added to the bottom of the wikitext.\n# If a meta property is removed, i.e., the user cleared the value where there was some value provided in the original article, SFF will first attempt to remove the entire relevant default text from the wikitext, including the link itself.  If this did not succeed, meaning that some user has manually changed the default text previously, only the link is removed and replaced by a ''(not set)'' text from the message file.\n# If a meta property is changed, i.e., the user entered a value that differs from the value provided in the original article, the existing link is replaced by the new link.\n\n===Predefined properties===\n\nProperties that have been predefined by a semantic wiki extension, behave (for editing purposes) as if they have been undefined if no article yet exists, or defined if an article does exist, as described above.  However, they do have a predefined type.  Redefining a predefined property to be of a different type will result in unspecified behavior.\n\nPredefined properties are indicated with italicized names.\n\n==Notes==\n\n===Limitations===\n\nUpon interpreting an existing, possibly manually edited property article, the following concepts are not recognized by the form and can cause undefined behavior:\n\n* Escaped links\n* Alternate text\n* Multiple assignment (not very useful for these meta properties anyway)\n* Multiple values\n\nHowever, these are not likely to be used within the scope of a property article.  See [http://semantic-mediawiki.org/wiki/Help:Properties_and_types-http://semantic-mediawiki.org/wiki/Help:Properties_and_types] and [http://semantic-mediawiki.org/wiki/Help:Many-valued_properties-http://semantic-mediawiki.org/wiki/Help:Many-valued_properties] for further information about these concepts.\n\nCustom data types are not available for the ''Has type'' meta property.\n\n===Warning===\n\nChanging semantic meta properties of an existing property will not update or revalidate the articles that had been created with original meta values.  For example, if a property was previously of type String, then changing its type to Number will not ensure that existing articles will indeed have valid numeric values for this property.\n\n===Additional notes===\n\n* The name field is mandatory.\n* Vertical pipe symbols (''|'') should not be used in the values (due to constraints in the underlying software, this symbol cannot be escaped).  This may cause the wikitext to be interpreted incorrectly, resulting in unexpected behavior.\n* Care should also be taken when inserting character sequences that could be interpreted as wiki markup, or part of wiki markup.  This may cause the wikitext to be interpreted incorrectly, resulting in unexpected behavior.\n* The user enters the allowed values as a comma separated list.  Should the user require an actual comma as part of an allowed value, the comma should be ''escaped'' (preceded) by a backslash (''\\'') character.  This escape option is not available for the other fields, since the user is highly unlikely to need values that include the comma character.\n\n= Create or edit templates =\n\n==Introduction==\n\nIn the Semantic Forms extension (SF), users can use a form based interface to create templates designed for use by SF''s forms.  SF lets the user indicate the category defined by the template, one or more semantic properties that are part of it, as well as a semantic property used for aggregation.  When creating the template, SF generates a MediaWiki template article containing the information entered.\n\nHowever, if the user wishes to make changes to the template later, he or she will have to do this in the raw template text; there is no friendly form to assist in the editing process.  If the user uses the creation process to ''edit'' a template, the existing template is overridden by the newly generated version, so that all user edits to the existing template will be lost.\n\nThe Semantic Friendly Forms extension (SFF) augments SF by adding such a facility.  When the user requests to edit an existing template SFF displays a form with fields for the category, and the semantic and aggregation properties.  The current (saved) values are already inserted in the appropriate entry fields.  After the user edits the values and presses ''Save page'', SFF updates the template text to reflect these changes.\n\nSFF also adds some additional features; see below for further information.\n\nBecause of differences in the generated template text as compared to SF, new templates should be preferably created with the new ''Create a template'' special page added by SFF instead of the ''Create a template'' special page defined by SF.  See paragraph 2.5 for an explanation of the differences, and paragraph 3.2 for a guide how to create a new template.  Note that SFF is able to edit templates created by SF; the saved template will then contain the additional information provided by SFF.\n\n==Changes from SF==\n\nSFF adds some new facilities to the user interface, and also makes some changes to the template text to enable specific behavior in other parts of SFF.\n\n===Autogeneration===\n\nIf the user has entered a category in the category field, SFF is able to add semantic properties, that have this category as part of their domain, to the template.  This will also work if the category article itself doesn''t actually exist in the wiki.\n\nThe user can initiate this by pressing the ''Add fields from Category'' button, which is located next to the ''Add field'' button:\n\nhttp://is.cs.ou.nl/OWF/files/AddField.png\n \nFor each semantic property added through autogeneration, SFF checks whether that property has a value defined for its ''Has label'' meta property.  If so, this value is inserted in the ''Field name'' and ''Display label'' fields in the template; if not, these fields are left empty, which would result in the default values being inserted upon saving (see paragraph 2.4.\n\nSFF will not verify whether a semantic property to be added is already present in the template, which may result in multiple occurrences of the same property.  This is intentional, since this may be what the user intends to do, and it is easy to manually delete any unneeded properties.\n\nIf no category was entered in the category field, the button does nothing.\n\n===Autocompletion===\n\nAutocompletion is available for the name field.  It suggests article titles from the ''Template'' namespace.  Note that if the user chooses the name of an existing template, that template will be overwritten when saving (without notice) instead of edited.  Therefore, the autocompletion on this field may probably be more useful as a reminder which templates already exist, so as to help the user avoid accidentally overwriting an existing one.\n\nAutocompletion is also available for the category field, suggesting article titles from the ''Category'' namespace.\n\n===Links===\n\nSFF adds a direct link to the ''Create a category'' special page at the bottom for convenience.\n\n===Default name and label values===\n\nIn SF, a user could clear the name and/or label from a previously added semantic property, which would result in unspecified behavior when editing or displaying forms and articles.\n\nSFF adds the following defaults when saving a template:\n\n* If the ''Field name'' field is empty and a semantic property has been selected, then the field name will default to the semantic property''s name;\n* Otherwise, if the field name'' field is empty and no semantic property has been selected, the field will not be saved;\n* Otherwise, if the ''Display label'' field is empty and a semantic property has been selected, then the label will default to the semantic property''s name;\n* Otherwise, if the ''Display label'' is empty, then it will default to the value in the name field; no semantic property will be selected.\nA field containing only whitespace (spaces, tabs, newlines, etc.) is considered empty in these rules.\n\n===Template text format===\n\nSFF adds logic to the template text that will hide empty fields in wiki articles.  For infobox templates, SFF also adds a link in the infobox header that will take the user to a form to edit the article.  The form that will be used for this is the one that the article was created with.\n\n==Workflow==\n\n===Existing templates===\n\nThere are two basic paths to edit an existing template with a form:\n\n# From Special pages, choose ''Edit a template'' (under the Semantic Friendly Forms heading).  A list of existing templates is displayed.  Choosing one of these will bring the user to the add/edit template screen.\n# When viewing a template article, either an existing article or the page that says that no article for the template has yet been defined, an ''edit with form'' tab appears at the top.  Selecting this tab will bring the user to the add/edit template screen.\n\nThe values for the various fields as defined in the template article are displayed in the form and available for editing, including the template''s name.  If the name is changed by the user, a new template article will be created under the new name, while the existing article remains unchanged.\n\nPress ''Save page'' to save the changes, or ''Preview'' to preview the changes without saving.  The Cancel link moves the user to the template article page, while discarding any changes made.\n\n===New templates===\n\nIt is strongly recommended to not use the SF special page for creating new articles.  Instead, go to the ''Create a template'' special page under the Semantic Friendly Forms heading.  Follow the ''new'' link near the top of the page to go to the form.\n\nThis will bring the user to the create template screen.  The user is required to enter a name.\n\nPress ''Save'' to generate and save the new article, or ''Preview page'' to preview the article without saving.  The Cancel link returns the user to the ''Create or Edit a Template'' page, while discarding any information entered.\n\n==Notes==\n\n===Warning===\n\nChanging an existing template will not automatically update the forms that depend on it.  For example, if a semantic property is added to the template, this property will not be immediately available in the forms that use that template.  Simply opening each form for editing (using SFF) and saving it is sufficient to update the form (when opening a form for editing, the new semantic properties are automatically displayed, but not yet saved).  However, the user would probably like to make additional changes to the form anyway, such as, for example, the label for the newly added semantic property.\n\n===Additional notes===\n\n* The name field is mandatory.\n* The field names should be unique within the template, though this is not enforced.  Creating multiple identical field names in the same template will result in templates with duplicate parameter names, which will very likely not behave as intended.\n* Vertical pipe symbols (''|'') should not be used in the values (due to constraints in the underlying software, this symbol cannot be escaped).  This may cause the wikitext to be interpreted incorrectly, resulting in unexpected behavior.\n* Care should also be taken when inserting character sequences that could be interpreted as wiki markup, or part of wiki markup.  This may cause the wikitext to be interpreted incorrectly, resulting in unexpected behavior.\n\n= Create or edit forms =\n\n==Introduction.==\n\nThe Semantic Friendly Forms (SFF) is an Wiki Extension that is build upon the Semantic Forms extension (SF). On introducing  the SF extension, users got the advantage to use a full graphical interface for maintaining forms and were with this help of this extension able to create Wiki articles by defining and using forms in stead of the former way: by editing articles in a text editor. The SF extension improved not only the already existing functionality of \"Create properties\" and \"Create templates\" but offered the new developed functions to \"Create forms\" and \"Create articles\". This document handles about the mentioned function \"Create forms\". \n\nOne of the advantages of this SF function was the possibility to create on a similar way a set of  related Articles, who have the same subject. For example, as now 2 instances of type \"person\" are created in Wiki Media, it is guaranteed that they have the same characteristics as they are defined in and used by the \"Create Forms\" function. As 2 different forms with may be 2 totally different property selections were used, would that give 2 different, incomparable instances. The forms function also can result in a standardization of Wiki Articles. This makes it possible for e.g. computers to define computerized actions on Wiki Articles, for example to do reasoning with there data.\n\nThe SFF extension extends the advantages of the SF version by a couple of changes. While re-editing was not possible in SF, SFF supports. Users want to re-edit forms, for instance as the form has been extended with a template, an existing template has been changed, properties has been changed etc. This option makes the function more functional but, very important, very user friendly. Another user friendly extension is the possibility for users to press on the introduced links, nearly every place, where properties, templates, forms and categories are used in forms. By clicking on a link, the Wiki shows the user a display or change function for this item. This option is very context oriented.\n\nA second advantage from the SFF version is the support of semantic fields. First, the \"Create properties\"function has been extended with a couple of \"semantic\" fields. Secondly, they are used by the templates and therefore also available at the \"Create forms\" function. With this new extension, SFF supports the maintenance of fields used for a few RDF-S and OWL functions. This functionality can be used for the maintenance of Wiki Articles but they are also useful in further developments, for instance for exportation of data, for reasoning on data etc. \n\n===Work flow SFF forms===\n\n===New forms===\n\nThis paragraph describes the procedure to create from scratch a new SFF-based form. \n\nFirst, the user puts a form name in the form name field and adds the new form by pressing the button \"Add or edit\". While this field delivers the autocompletion functionality, a proposal list will be shown, based on the available forms, matching the field input. After inputing the field, the Wiki checks if the form name is already in use. While not, the system shows an input form where the user can construct a new Wiki Media form.\n\nA form consists of one or more templates. The user has to select an available template from the template list box and press after selection the button \"add\". On click this button, the Wiki shows the complete template with  its fields and other template properties and shows on the screen a new box for each template, extended with the input fields. The user can fill in this fields. Optionally the user is able to add more (even duplicate) templates to the form. By the \"Before template\" list box, the user can determine the position of the new template, for instance between the existing form templates.\n\nThe user can also remove a form template by pressing the \"delete\" button in the box of the form template: the selected template is then removed from the form totally.\nAfter succeeding the input of the new form, the user is able to save or to preview the new form by pressing one of the buttons \"save\" or \"preview\". This 2 buttons belong to the existing Wiki functionality and will not be described in this document.\n\n===Existing forms===\n\nA great advantage from SFF in opposite to SF is the possibility that the user has the possibility to change existing forms. In SF forms the forms could only be changed manually by use of the text editor. This is only advised due complexity for experienced users. The SFF form page provides to the user 2 ways to change existing forms: the first way is to type in the form in the form name box and select one of the by autocompletion offered form names and press after this the button \"Add or edit\". If the system detects the present form, the Wiki collects all the data from the form and shows the data to the screen. The second way is to press the link of  the forms presented in the list of forms as the user can find in the 2<sup>nd</sup> part of the edit form page. \n\nThe further way of editing form is already described in the previous section \"New forms\"; the user can add or remove form templates or can change the data of existing form template fields. After the user has finished the change process, a save or preview can be done by pressing the button. \n\nRe-edit forms has no implications for Wiki articles which are already generated by this form. The articles still posses the removed templates or fields. \n\nAfter editing or re-editing a form, the user is always able to change the form by text editor to add very special options which are not supported by the graphical SFF form editor. Re-editing the form by the SFF function including this additions can case unexpected effects.\n\n==Form generation and update==\n\n===Deleted or changed templates and properties===\n\nChanged or removed templates has implications for re-editing a form. Removed templates are not shown in the re-edit mode. The same for removed template fields: on re-edit the form, this fields will not be shown. On saving the re-edit, this templates and fields will be removed from the form.\n\nA removed property has no implication for re-editing a form; the property type is unknown, but the property can still be used by the form. \n\n===Defined templates and properties===\n\nDuring the form generation, the user is informed about the characteristics from the used properties and templates. From every used property in template the property name and property type is printed to the screen, formed by a link. The user can press the link to get more property information.\n\nThe same functionality is shown for the template information. So are links shown for the template name, the template categories and the template aggregation property.  \n==Notes==\n\n===Limitations===\n\nUpon interpreting an existing, possibly manually edited form article, the following concepts are not recognized by the form and can cause undefined behavior:\n\n* Escaped links\n* Alternate text\n* Multiple assignment (not very useful for this meta property anyway)\n* Multiple values\n\nHowever, these are not likely to be used within the scope of a property article.  \n\n=== Warnings ===\n\nChanging semantic meta properties of an existing property will not update or revalidates the articles that had been created with original meta values.  For example, if a property was previously of type String, then changing its type to Number will not ensure that existing articles will indeed have valid numeric values for this property.\n\n===Additional notes===\n\n* The name field is mandatory.\n* Vertical pipe symbols (''|'') should not be used in the values (due to constraints in the underlying software, this symbol cannot be escaped).  This may cause the Wiki text to be interpreted incorrectly, resulting in unexpected behavior.\n* Care should also be taken when inserting character sequences that could be interpreted as Wiki markup, or part of Wiki markup.  This may cause the Wiki text to be interpreted incorrectly, resulting in unexpected behavior.\n* The user enters the allowed values as a comma separated list.  Should the user require an actual comma as part of an allowed value, the comma should be ''escaped'' (preceded) by a backslash (''\\'') character.\n\n= Create or edit data =\n\n==Introduction.==\n\nThe Semantic Friendly Forms (SFF) is an Wiki Extension that is build upon the Semantic Forms extension (SF). On introducing  the SF extension, users got the advantage to use a full graphical interface for maintaining forms and were with this help of this extension able to create Wiki articles by defining and using forms in stead of the former way: by editing articles in a text editor. The SF extension improved not only the already existing functionality of \"Create properties\" and \"Create templates\" but offered the new developed functions to \"Create forms\" and \"Create data\"/\"Edit data\". This document handles about the mentioned functions \"Create data\" and \"Edit data\". \n\nThe SFF extension extends the advantages of the SF version by a couple of improvements. The relevanf fields got an autocompletion function. Another user friendly extension is the possibility for users to press on the introduced links, nearly every place, where properties, templates, forms and categories are used in forms. By clicking on a link, the Wiki shows the user a display or change function for this item. This option is very context oriented.\n\nA second advantage from the SFF extension is the support of extra semantic fields. With help of this new extension, SFF supports the maintenance of fields used for a few RDF-S and OWL functions. This functionality can be used for the maintenance of Wiki Articles but they are also useful in further developments, for instance for exportation of data, for reasoning on data etc. \n\n==Work flow SFF \"Add data\" and \"Edit data\".==\n\n===Add data===\n\nThe \"Add data\" page of the SFF is inherited from the SF version. This means, that the SFF page possesses the same process flow as the SF version. For this reason, the flow is not described here, but the user is referred to the SF documentation for this process description.\n\nThe SFF \"Add data\" page is extended on 2 items: first, on the start page, the \"page name\" field has been extended with an autocompletion function. Typed by the first character(s), the available pages are shown in a popup list directly. Secondly, on the page input screen, the user can press on the links of properties, templates and categories now,  as they are defined  in the form for which the page is composed.\n\n===Edit data.===\n\nThe \"Edit data\" page is also derived from the SF page \"Edit data\". All comments from the previous section regarding the \"Add data\" page are also valid for this page. \n\n==Form generation and update==\n\n===Deleted or changed form, templates and properties===\n\nChanged or removed forms, templates or properties have no implication for editing existing data. The Wiki collects the data of the existing data from a stored text (the user is able to change this text in a text editor) and places the information on the page. It is however not possible to jump to removed forms, templates, categories or properties.\n\n===Defined forms, templates and properties===\n\nDuring the data (article) generation, the Wiki picks up all the data of the selected form which it haves on that moment. After storing the data page, the used templates and fields are stored in a text (eventually to be displayed or changed with the text editor).  \n\n==Notes==\n\n===Limitations===\n\nUpon interpreting an existing, possibly manually edited form article, the following concepts are not recognized by the form and can cause undefined behavior:\n\n* Escaped links\n* Alternate text\n* Multiple assignment (not very useful for this meta property anyway)\n* Multiple values\n\nHowever, these are not likely to be used within the scope of a property article.  \n\n===Warnings===\n\nChanging semantic meta properties of an existing property will not update or revalidates the articles that had been created with original meta values.  For example, if a property was previously of type String, then changing its type to Number will not ensure that existing articles will indeed have valid numeric values for this property.\n\n===Additional notes===\n\n* The name field is mandatory.\n* Vertical pipe symbols (''|'') should not be used in the values (due to constraints in the underlying software, this symbol cannot be escaped).  This may cause the Wiki text to be interpreted incorrectly, resulting in unexpected behavior.\n* Care should also be taken when inserting character sequences that could be interpreted as Wiki markup, or part of Wiki markup.  This may cause the Wiki text to be interpreted incorrectly, resulting in unexpected behavior.\n* The user enters the allowed values as a comma separated list.  Should the user require an actual comma as part of an allowed value, the comma should be ''escaped'' (preceded) by a backslash (''\\'') character."
                    }
                ]
            }
        }
    }
}