Semantic Friendly Forms

Description

Semantic Friendly Forms is an extension on top of Semantic Forms and Semantic MediaWiki. If offers two categories of functions:

• Form-based editing of existing properties, templates and forms (before forms interfaces could only create these).
• Additional properties from the Semantic Web, which here influence the generation of Semantic Forms interfaces.

Semantic Friendly Forms is the result of a Bachelors student group project at the Open Universiteit. Its creators are Rens te Kloese, Henri Gerrits and Mark Rotteveel.

More information about Semantic Friendly Forms and its use is available in the Semantic Friendly Forms student project final slides (in Dutch).

Code and download

You can download the Semantic Friendly Forms code in this compressed files:

• http://is.cs.ou.nl/OWF/files/SemanticFriendlyFormsV0.5.zip

Installation

Requirements

Semantic Friendly Forms (SFF) requires the following:

• MediaWiki, versions 1.14.0 to 1.15.1
• Semantic MediaWiki, versions 1.4.2 to 1.4.3
• Semantic Forms, version 1.8.5
• ParserFunctions, version 1.1.1

These 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.

Installation process

Installation is as follows:

1. Unzip the file SemanticFriendlyFormsV0.5.zip into the 'extensions' of your MediaWiki installation.
2. Add the following line to MediaWiki²s LocalSettings.php file (found in the MediaWiki installation directory):
   require_once('extensions/SemanticFriendlyForms/SFF_Settings.php');
3. Check the SFF version number on the 'Version' special page to verify that the installation was successful.

Create or edit properties

Introduction

In 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.

However, 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.

The 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.

SFF also adds some meta properties of its own; see below for further information.

The following meta properties can be edited:

• The Has type meta property ([1])
• The Has default form meta property ([2])
• The Allows value meta property ([3])
• The Has range meta property (SFF)
• The Has domain meta property (SFF)
• The Is inverse of meta property (SFF)
• The Is symmetric meta property (SFF)
• The Has label meta property (SFF)
• The Has comment meta property (SFF)

Because 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.

Semantic 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.

Supported meta properties

SFF 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.

Has type

As 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.

In 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.

Custom data types are presently not supported.

Has range

This meta property is predefined by SFF, and is largely based on rdfs:range . 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).

The 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.

More precisely:

Where:

A_U = Set of all articles in the wiki
P_U = Set 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)
p.range = The set of categories in the Has range meta property of property p.
a.memberOf(c) = True if and only if article a is a member of category c, i.e., it contains a link of the form [[Category:c]].

If a propertys 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.

Note that rdfs:range has different semantics in case of multiple values.

The 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).

The field supports autocompletion on the first value, providing suggestions from the category names currently defined in the wiki.

Internally, 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.

The 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.

In 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.

Has domain

This meta property is predefined by SFF, and is largely based on rdfs:domain . 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).

The 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.

More precisely:

Where:

A_U = Set of all articles in the wiki
P_U = Set 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)
p.domain = The set of categories in the Has domain meta property of property p.
a.memberOf(c) = True if and only if article a is a member of category c, i.e., it contains a link of the form [[Category:c]].

If a propertys 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.

Note that rdfs:domain has different semantics in case of multiple values.

The 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).

The field supports autocompletion on the first value, providing suggestions from the category names currently defined in the wiki.

Internally, 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.

The 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.

In 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.

Is inverse of

This meta property is predefined by SFF, and is largely based on owl:inverseOf . 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).

The 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.

More precisely:

Where:

A_U = Set of all articles in the wiki
P_U = Set 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)
p.inverseOf(q) = True if and only if q is an element of the set of properties in the Is inverse of meta property of property p.

Note 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.

Note 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.

The 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).

The field supports autocompletion on the first value, providing suggestions from the property names currently defined or used in the wiki.

Internally, 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.

The 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.

In 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.

Is symmetric

This meta property is predefined by SFF, and is largely based on owl:SymmetricProperty . It has a boolean type, meaning that the only allowable values are true and false.

The 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.

More precisely:

Where:

A_U = Set of all articles in the wiki
P_U = Set 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)
p.symmetric = True if and only if the Is symmetric meta property of property p is true.

Or in other words, if a property is symmetric then it is the inverse of itself:

If 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.

Note 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.

The 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).

The 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.

Has label

This meta property is predefined by SFF, and is largely based on rdfs:label . It has a text type, meaning that any text can be used.

The 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.

If 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.

Has comment

This meta property is predefined by SFF, and is largely based on rdfs:comment . It has a text type, meaning that any text can be used.

The 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).

If 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.

Has default form

Although 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.

Refer to SFs documentation for further information.

In 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.

Allows value

This 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.

Refer to SFs documentation for further information.

As 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.

Workflow

Existing properties

Used 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.

There are two basic paths to edit an existing property with a form:

1. 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.
2. 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.

In 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 propertys 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.

Press 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.

New properties

It 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.

This 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.

Press 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.

Article generation and update

Undefined properties

For 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 users preferred language. These message files can only be changed by system administrators. For fields that are left empty, no text is generated.

Defined properties

For 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.

1. 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.
2. 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.
3. 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.

Predefined properties

Properties 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.

Predefined properties are indicated with italicized names.

Notes

Limitations

Upon interpreting an existing, possibly manually edited property article, the following concepts are not recognized by the form and can cause undefined behavior:

• Escaped links
• Alternate text
• Multiple assignment (not very useful for these meta properties anyway)
• Multiple values

However, these are not likely to be used within the scope of a property article. See [4] and [5] for further information about these concepts.

Custom data types are not available for the Has type meta property.

Warning

Changing 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.

Additional notes

• The name field is mandatory.
• 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.
• 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.
• 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.

Create or edit templates

Introduction

In the Semantic Forms extension (SF), users can use a form based interface to create templates designed for use by SFs 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.

However, 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.

The 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.

SFF also adds some additional features; see below for further information.

Because 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.

Changes from SF

SFF 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.

Autogeneration

If 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 doesnt actually exist in the wiki.

The user can initiate this by pressing the Add fields from Category button, which is located next to the Add field button:

For 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.

SFF 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.

If no category was entered in the category field, the button does nothing.

Autocompletion

Autocompletion 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.

Autocompletion is also available for the category field, suggesting article titles from the Category namespace.

Links

SFF adds a direct link to the Create a category special page at the bottom for convenience.

Default name and label values

In 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.

SFF adds the following defaults when saving a template:

• If the Field name field is empty and a semantic property has been selected, then the field name will default to the semantic propertys name;
• Otherwise, if the field name field is empty and no semantic property has been selected, the field will not be saved;
• Otherwise, if the Display label field is empty and a semantic property has been selected, then the label will default to the semantic propertys name;
• Otherwise, if the Display label is empty, then it will default to the value in the name field; no semantic property will be selected.

A field containing only whitespace (spaces, tabs, newlines, etc.) is considered empty in these rules.

Template text format

SFF 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.

Workflow

Existing templates

There are two basic paths to edit an existing template with a form:

1. 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.
2. 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.

The values for the various fields as defined in the template article are displayed in the form and available for editing, including the templates 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.

Press 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.

New templates

It 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.

This will bring the user to the create template screen. The user is required to enter a name.

Press 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.

Notes

Warning

Changing 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.

Additional notes

• The name field is mandatory.
• 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.
• 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.
• 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.

Create or edit forms

Introduction.

The 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".

One 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.

The 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.

A 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.

New forms

This paragraph describes the procedure to create from scratch a new SFF-based form.

First, 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.

A 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.

The 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. After 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.

Existing forms

A 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^nd part of the edit form page.

The 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.

Re-edit forms has no implications for Wiki articles which are already generated by this form. The articles still posses the removed templates or fields.

After 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.

Form generation and update

Deleted or changed templates and properties

Changed 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.

A 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.

Defined templates and properties

During 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.

The same functionality is shown for the template information. So are links shown for the template name, the template categories and the template aggregation property.

Notes

Limitations

Upon interpreting an existing, possibly manually edited form article, the following concepts are not recognized by the form and can cause undefined behavior:

• Escaped links
• Alternate text
• Multiple assignment (not very useful for this meta property anyway)
• Multiple values

However, these are not likely to be used within the scope of a property article.

Warnings

Changing 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.

Additional notes

• The name field is mandatory.
• 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.
• 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.
• 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.

Create or edit data

Introduction.

The 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".

The 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.

A 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.

Work flow SFF "Add data" and "Edit data".

Add data

The "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.

The 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.

Edit data.

The "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.

Form generation and update

Deleted or changed form, templates and properties

Changed 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.

Defined forms, templates and properties

During 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).

Notes

Limitations

Upon interpreting an existing, possibly manually edited form article, the following concepts are not recognized by the form and can cause undefined behavior:

• Escaped links
• Alternate text
• Multiple assignment (not very useful for this meta property anyway)
• Multiple values

However, these are not likely to be used within the scope of a property article.

Warnings

Changing 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.

Additional notes

• The name field is mandatory.
• 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.
• 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.
• 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.