Complete related defns

[nicholascar]

This issue was created in the Profile Guidance document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

(Nick:) Complete table of related works' definitions

[kcoyle]

We seem to have both related works and examples of profiles in this section. We should separate these. Related works would be other attempts to define what a profile is (e.g. DCAP, ADMS, perhaps ODRL); examples would be actual profiles (DCAT-AP, BIBFRA.ME). This would mean that we could put the profiles ontology in the "what is a profile" section as it describes profiles generally. So that would mean that the above changes to what a profile is (e.g. DCAP, profiles ontology, ADMS, perhaps ODRL) which gives us a place to talk about the different ways that profiles are defined, and to different degrees, in those views.

[aisaac]

@kcoyle I don't understand the starting point of your comment. This section (today, A.3, https://w3c.github.io/dxwg/profiles/#relatedworkdefns) is only meant to include definitions (from other works) as a way to contrast them with ours. The examples of profiles are already moved to another section (two, actually: 1.3 and 5). It could be that some of the explanations about related work in 1.3 would touch on the definitions of what is a profile in these related works. And I think such lightweight 'touching' this is fine. But I would certainly not like 1.3 to include verbatim definitions from these related works, as @nicholascar wanted to do in this section A.3. Anyway, repeating what I've written in a note in A.3, I think this (including the formal definitions and comparing them with ours, also formally) is a noble endeavour but one that would consume too much of our time right now.

[dr-shorthair]

As previously noted, the OGC's Modular Specification model encodes a related effort. Clause 4 gives the terms and definitions, within which the following are immediately relevant:

4.9 direct dependency (of a requirements class)

another requirements class (the dependency) whose requirements are defined to also be requirements of this requirements class NOTE A direct dependency of the current requirements class will have the same standardization target as the current requirements class. This is another ways of saying that the current requirements class extends, or uses all the aspects of the direct dependency. Any tests associated to this dependency can be applied to this requirements class. When testing a direct dependency, the standardization target is directly subject to the test in the specified conformance test class of the direct dependency.

4.10 indirect dependency (of a requirements class)

requirements class with a different standardization target which is used, produced or associated to by the implementation of this requirements class NOTE In this instance, as opposed to the direct dependency, the test against the consumable or product used or produced by the requirements class does not directly test the requirements class, but tests only its side effects. Hence, a particular type of feature service could be required to produce valid XML documents, but the test of validity for the XML document is not directly testing the service, but only indirectly testing the validity of its output. Direct dependencies test the same standardization target, but indirect dependencies test related but different standardization targets. The standardization target of the indirect dependency is different from the target of ―this requirements class‖ but it may be of the same or related standardization target type. For example, if one service is related to another second service, then a service requirement may be placed against the second associated service to assure that the first service has access to its functionality. For example, if a DRM-enabled service is required to have an association to a licensing service, then the requirements of a licensing service are indirect requirements for the DRM-enabled service. Such a requirement may be stated as the associated licensing service has a certificate of conformance of a particular kind.

4.11 extension (of a requirements class)

requirements class which has a direct dependency on another requirements class NOTE Here extension is defined on requirements class so that their implementation may be software extensions in a manner analogous to the extension relation between the requirements classes.

4.13 home (of a requirement or recommendation)

official statement of a requirement or recommendation that is the precedent for any other version repeated or rephrased elsewhere NOTE Explanatory text associated to normative language often repeats or rephrases the requirement to aid in the discussion and understanding of the official version of the normative language. Since such restatements are often less formal than the original source and potentially subject to alternate interpretation, it is important to know the location of the home official version of the language. These alternative statements use non-normative language and are statements using the definitions of the ISO Directives Part 2.

4.16 profile

specification or standard consisting of a set of references to one or more base standards and/or other profiles, and the identification of any chosen conformance test classes, conforming subsets, options and parameters of those base standards, or profiles necessary to accomplish a particular function. [ISO/IEC TR 10000-1] NOTE This definition has been adopted from ISO 10000: Part 1. The wording has been changed to accommodate the shared vocabulary of OGC and ISO TC 211 and for editorial reasons. The original text is ―A set of one or more base standards and/or ISPs, and, where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a particular function.‖ In the usage of this standard, a profile will be a set of requirements classes or conformance classes (either preexisting or locally defined) of the base standards. This means that a standardization target being conformant to a profile implies that the same target is conformant to the standards referenced in the profile.

4.19 requirements class

aggregate of all requirement modules that must all be satisfied to satisfy a conformance test class NOTE There is some confusion possible here, since the testing of indirect dependencies seems to violate this definition. But the existence of an indirect dependency implies that the test is actually a test of the existence of the relationship from the original target to something that has a property (satisfies a condition or requirement from another requirements class).

4.20 requirements module

aggregate of requirements and recommendations of a specification against a single standardization target type NOTE This term is included to be consistent with the use of modules in ISO 19105. The third type of normative language, the ―permission‖ which uses ―may,‖ is not considered here mainly because it is usually used to prevent a requirement from being ―over interpreted‖ and as such is considered to be more of a ―statement of fact‖ than a ―normative‖ condition.

4.21 specification

document containing recommendations, requirements and conformance tests for those requirements NOTE This definition is included for completeness. See Clause 5.3. This does not restrict what else a standard may contain, as long as it does contain the three types of element cited.

4.22 standard

specification that has been approved by a legitimate Standards Body NOTE This definition is included for completeness. Standard and specification can apply to the same document. While specification is always valid, standard only applies after the adoption of the document by a legitimate standards organization. The legitimate Standards Bodies for OGC consist of OGC, ISO and any of the other standards bodies accepted and used as a source of normative references by OGC or ISO in their standards. In the normal meaning of the word ―standard‖, there are other conditions that may be required, but this standard has chosen to ignore them in the process of abstraction.

4.23 standardization target

entity to which some requirements of a standard apply NOTE The standardization target is the entity which may receive a certificate of conformance for a requirements class.

4.24 standardization target type

type of entity or set of entities to which the requirements of a standard apply NOTE The standardization target types give the standardization targets a typing system similar to the UML classifiers. In general, the types inherit from one another in the same way that UML classes do. The same class/metaclass semantics apply, and two targets can be considered to have the ―same type‖ (in a particular situation) if their instantiation types share the appropriate supertype, as is the case in UML. In OGC for example, all service types that must pass the OWS (Open Web Services) Common specification are some extension of the ―Open Web Service‖ standardization target type. This makes OWS Common a default ―global core‖ for all OGC Services. In some cases, the standardization target type may be another specification. A GML application schema is a standardization target for the GML standard, but is in turn a specification of instances of that application schema.

[kcoyle]

@aisaac I was referring to the section in the introduction, currently at 1.3, not the appendix. My main comment on that section is here. I wouldn't expect that section to be a list of profiles, but would use some existing profiles as examples of what we are talking about. It wouldn't go into great detail.

[aisaac]

@kcoyle ok I was confused because your comment starts with 'this section' and within the issue here, this section is the appendix, as the issue has been raised in the document in the context of the appendix.

@dr-shorthair thanks for the input. It's a bit overwhelming but gives a good example of the direction in which this section (the appendix labeled A.3 now) could go.

[aisaac]

(before I forget this) @nicholascar has started an example of comparing the definition of 'profile' in DCAP and in DXWG, which can be used for this section. This is in an email entitled 'ProfDesc representation of a DCAP' send on Sept 3 2018. A wider thread branched out of the same original discussion (but without the material in the private mail) and could bring additional, useful ideas: https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Sep/0188.html

[nicholascar]

The profile (a DCAP, expressed in DCAP DSP and Prof Ont terms) is here: https://github.com/CSIRO-enviro-informatics/csiro-epub-dcap