gfse / specif-schema Goto Github PK

The items of 'SpecifMultiLanguageText' have not a type of its own. Change the schema so that 'SpecifMultiLanguageText' is a list of 'SpecifLanguageText'.

Boolean dataTypes cannot have enumerated values, because boolean is already enumerated. That's correctly represented in the SpecIF schema v1.1.

However properties with boolean dataType may have a list of multiple values, in other words a vector of values, like any property having another dataType. That's missing in the SpecIF schema v1.1; a dataType with type xs:boolean should have a native property 'multiple' as well.

'multiple' and 'enumeration' have nothing to do with each other ... which was different for SpecIF v1.0 and below.

The idea is to provide separate schemata for the SpecIF elements, such as 'dataType', 'resourceClass' or 'resource'. Separate schemata can be used by an API to check incoming data.

There are two alternatives:

• JSON Schema allows to separate a schema into multiple files. Then, a schema for each SpecIF element is provided and the SpecIF schema references them.
• Keep the SpecIF schema as it is and to provide element-schemata in addition. Advantage is that a single schema file is quicker to load and disadvantage is that duplicate definitions need to be maintained in parallel.

Further thoughts:

• the partial element schemata could be used in the API definition, rather than appending separate schema definitions (@oalt )
• While a segmented schema with references is preferrable in terms of redundancy avoidance (DRY principle), it is perhaps more difficult to handle, as the complete schema consists of multiple files.

For property values of type string, there is no reason to have formatted text in one language and plain text in another. Also there is the possibility to specify the format for a propertyClass.

Thus, omit attribute 'format' from SpecifLanguageText.

Not all properties of dataType xs:string are multi-language, for example those of type dcterms:identifier. Even more, those must not have multiple languages; Otherwise information is largely obscured.

A user interface must know whether a property may or may not have multiple languages, so the proposal is to add a native boolean attribute 'multiLanguage' to a propertyClass, similar to 'multiple'. This attribute is only meaningful for properties of dataType xs:string.

The values of a property are unchanged: In case a propertyClass specifies "multiple": false and "multiLanguage": false, the values are represented by two nested arrays with a single text value ... without language attribute:

{    
    .
    .
    "values": [[{ "text": "lorem ipsum"}]],
    .
}    

Have played around a little and without any limitations in terms of backward compatibility, we can add
"@context": "http://purl.org/dc/terms/"
to all SpecIF data sets without problem; the SpecIF schema v1.1 supports it as is. This would take away any ambiguity where our property names come from.

There are some interesting questions ahead, for example using @id, @type as well as additional namespaces like schema.org or INCOSE for systems engineering terms.

This is for v1.2 or v2.0 ...

So far, we have a home-grown pattern for SpecIF identifiers. Consider to use 'uuid' as defined in JSON Schema ("A Universally Unique Identifier as defined by RFC 4122.")

Currently there is no potential issue when using ReqIF identifiers in SpecIF and vice-versa. Check whether this is still the case when SpecIF uses 'uuid'.

Proxy-Elements in a SpecIF data set (package) reference elements from other data sets (packages). Use case: Classes are defined and published centrally; not necessarily supplied in a data set (package).

Comment: There will be certain constraints to assure consistency.

There is an idea to specify the classes of resources which can be referenced by a certain hierarchy node. This allows to create folders which can only contain resources of one or more specified classes. For example a requirement folder would only allow subordinated requirement folders or requirements.

Values:

• public
• private
• protected (?)

Further thoughts:

• All features with respect to multi-projects, visibility and inter-project statements will be left to schema versions >v1.0.0, as we have some ideas, but no real use-cases.

.. namely 'created' and 'modified'.

SpecIF resourceClasses and statementClasses may be extended by others. If a parent class shall never be instantiated and ignored completely at the user interface, an additional value "instantiation":"never" is necessary. For example any statistic report may show "auto" or "user" instantiated resources, but ignore those which are "never" instantiated (thus abstract).

We would like to add an attribute to a propertyClass, whether a corresponding propertyValue must be given for every resource or statement instance.

JSON Schema draft 2019-09 is needed and a new version of AJV.

In v1.1, a property with link to value of enumerated dataType looks like:

{
  "class": {"id":"PC-Priority"},
  "values": ["V-Prio-1"]
}

where "V-Prio-1"is the id of an enumerated value of the referenced dataType.

In order to be consistent with other internal links, it is proposed:

{
  "class": {"id":"PC-Priority"},
  "values": [{"id":"V-Prio-1"}]
}

Towards this end, the schema element SpecifValue needs an additional option.

The dataType xs:duration is not defined in OWL. As any tranformation is difficult and the dataType is not of great importance, it is removed from SpecIF.

Reference: Hitzler, Krötzsch, Rudolph: "Foundations of Semantic Web Technologies", p. 117.

With schema v1.1, both dataTypes and propertyClasses may have an attribute 'multiple', where the propertyClass' supersedes the dataTypes'.

There is no real benefit in having both options. But it complicated the code of applications processing SpecIF. It is proposed to remove the attribute 'multiple' from dataTypes.

Add the possibility to define roles with their permissions. The permissions shall support inheritance: For example a read permission at project root is a read permission on every item, except if a different permission is given in the children hierarchy.

There are 2 inheritance hierarchies, which must both grant a certain permission to become effective:

• Project <-- ResourceClass/StatementClass <-- PropertyClass ... to control permission by class
• Project <-- Hierarchy <-- Folder <-- Resorce Reference ... to control permission within the hierarchy tree

Each permission is a vector of Create, Read, Update and Delete permissions to allow a fine-grained access control on property level.

So far, SpecIF is limited to a simple data type per propertyClass. resourceClasses and statementClasses can have a flat list of propertyClasses with a simple dataType, each.

Very probably we will need complex data types such as 3D coordinates.

Elements of a SpecIF data set (package) can be classified as public or private. Only public elements can be referenced by other data sets (packages).

.. this would allow an automatic type checking at schema-level.

In v1.1, SpecifIcon is specified too weakly. Should not simply be of type 'string', but a SpecifText ready to display:

• UTF-8 character
• URL in a XHTML image or object tag.
• dataURL in a XHTML image or object tag.