W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

[dxwg] Suggested updates to definition of PROF constructs (#1061)

From: aisaac via GitHub <sysbot+gh@w3.org>
Date: Mon, 09 Sep 2019 15:11:18 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issues.opened-491157793-1568041876-sysbot+gh@w3.org>
aisaac has just created a new issue for https://github.com/w3c/dxwg:

== Suggested updates to definition of PROF constructs ==
@nicholascar @rob-metalinkage As discussed in our last PROF call, here are suggestions for updating the definitions and notes of some PROF constructs. For now I've focused on the ones of section [8.3 Class: Profile](https://w3c.github.io/dxwg/profilesont/#Class:Profile) as this takes time, and I want to see how you react to my first suggestions before continuing this :-)

- [prof:Profile](https://w3c.github.io/dxwg/profilesont/#Class:Profile) still uses the old definition for profile, at odds with the WG definition ([which is present in the PROF spec](https://w3c.github.io/dxwg/profilesont/#definitions)). The definition should be the official one, verbatim. I can live with keeping the note _"This definition includes [...]"_ in the definition, but it could also live a better life as a new scope note or usage note, in order to keep the "core" definition clean. 

- [prof:hasResource](https://w3c.github.io/dxwg/profilesont/#Property:hasResource). The current definition (_"A resource which describes the nature of an artifact and the role it plays in relation to a profile"_) doesn't work very well imo. The resource doesn't describe by itself - that's the job of a document about the resource - rather, the resource is used as the subject of statements that describe the artefact. So I suggest to replace the definition by _"Relates a Profile to an artefact that implements (some aspects of) it, fulfilling a specific role in relation to the Profile."_

- [prof:isProfileOf](https://w3c.github.io/dxwg/profilesont/#Property:isProfileOf). The current definition (_"The subject of 'is profile of' defines constraints on the object which playes the role of a base specification"_) has a typo and is not well aligned with the new definition of profile (as it focuses on constraint). The style is also at odds with the other definitions (well, at least the one I'm leaning towards ;-) ). I suggest _"Relates a Profile to another data specification that it constrains, extends, combines, or provides guidance or explanation about the usage of"_. 
The usage note should also be refreshed. I suggest _"A Profile may be a profile of one or more specifications. This property is optional, allowing any specification to be declared at the root of a profile hierarchy."_ .This removes the bit on inheritance, which is probably better in other section(s) that discuss the semantics of profile hierarchies. Considering how the notion of inheritance is controversial in the WG, it's better to lower the number of times it appears in the document. The suggested note also gets rid of unnecessary/debatable detail (I don't think using the Profile class is necessary for the root for a profile hierarchy; anyway what's crucial for defining the root is to be a dead-end of a `prof:profileOf` chain, not to be of a given type...)

- [prof:isTransitiveProfileOf](https://w3c.github.io/dxwg/profilesont/#Property:isTransitiveProfileOf). The current definition (_"A specification for which this Profile defines constraints, possibly through a chain of isProfileOf relationships"_) needs to be refreshed too: it focuses too much on constraints. In addition, we could put the technical aspect first, so as to highlight that this property is especially for convenience. I suggest _"The transitive closure of the prof:isProfileOf property. Relates a profile to another specification that it is a profile of, possibly via a chain of intermediate profiles that are in prof:isProfileOf relationships"_.
I also suggest to amend the existing usage note, relinquishing it from too strong wording on conformance, into _"This is a convenience property that may be used to access all specifications (including other profiles) that could provide useful information and related resources for the Profile (for example, for better identifying conformance requirements). This avoids forcing clients to traverse a profile hierarchy to find all relevant resources. If this property is used, then all such relationships should be present so a client can safely avoid hierarchy traversal."_

- [prof:hasToken] The current definition and usage note are a bit confusing wrt the notions of "prefered" and "alternative" (that is a strict dichotomy in many contexts, for example in SKOS, where can't be such thing as a 'prefered alternative' label) and do not reflect well the suggestions made in #453 . In fact considering how the "token" aspect of the notion is key, I  suggest to merge definition and  most of the usage note, which were short anyway, into "Relates the Profile to a identifier that can be used as prefered alternative to its URI, in circumstances where this URI cannot be used, for example in API arguments or in content negotiation."
The usage note could focus on the "simple" aspect of the token: "The token shall be a simple lexical form of identifier that needs to be compatible with its circumstances of use, such as in API arguments or content negotiation."
Hopefully this caters for most if not all the comments made in last stages of #453.

Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1061 using your GitHub account
Received on Monday, 9 September 2019 15:11:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:57 UTC