gfse / specif-schema Goto Github PK
View Code? Open in Web Editor NEWDefinition of the SpecIF JSON-schema and constraint checker
License: Apache License 2.0
Definition of the SpecIF JSON-schema and constraint checker
License: Apache License 2.0
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.
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 ...
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.
We would like to add an attribute to a propertyClass, whether a corresponding propertyValue must be given for every resource or statement instance.
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 items of 'SpecifMultiLanguageText' have not a type of its own. Change the schema so that 'SpecifMultiLanguageText' is a list of 'SpecifLanguageText'.
JSON Schema draft 2019-09 is needed and a new version of AJV.
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.
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.
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:
Further thoughts:
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'.
Values:
Further thoughts:
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"}]],
.
}
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).
There is little value in defining separate dataTypes. Of course a dataType can be used by several propertyClasses, but in practice this doesn't make a big difference. In contrast, software implementation is made more complex.
When defining the SpecIF ontology, the data type is defined together with the propertyClass anyways.
There is no reason why the root nodes of a hierarchy should be in a list named differently to nodes of lower levels. So a list of 'node' is always 'nodes' at all levels.
Attention, there is a dependency with #28.
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.
.. namely 'created' and 'modified'.
In v1.1, SpecifIcon is specified too weakly. Should not simply be of type 'string', but a SpecifText ready to display:
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.
.. this would allow an automatic type checking at schema-level.
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:
Each permission is a vector of Create, Read, Update and Delete permissions to allow a fine-grained access control on property level.
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).
Oliver Alt: "Koennte man die Hierarchien in SpecIF nicht auch mit Hilfe von Resourcen und Statement abbilden? Man braeuchte, um solche Baeume zu bauen doch nur ein paar Dinge wie
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.