As per old DCAT PR 1109

Proposal from @kcoyle in w3c/dxwg#1061

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

There is the start of a SHACL file for testing of profiles but it is only boilerplate (not functioning yet): https://github.com/w3c/dxwg/blob/gh-pages/prof/rdf/constraints.ttl

Raised by Reviewer 1 of the Profiles Ontology ESWC paper and elsewhere: PROF must differentiate itself from OWL, specifically prof:isProfileOf v. owl:imports.

Example 3 in https://www.w3.org/TR/2019/NOTE-dx-prof-20191218/ has invalid Turtle.
Line 3 should be followed by a semicolon. (It may be a good idea to check all Turtle snippets in an RDF editor/validator.)

This issue was created in the Profiles Ontology 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.

Refer to OGC Modular Specification policy [[modspec]] and related work in ISO TC/211 [[cfg-mgmt]].

These specifications define how dependencies between 'standards' can be handled in a manageable way.

Internal comments like [1] and some external ones indicate it's not appropriate to assume all classes in PROF diagrams are OWL classes. They could be RDFS classes and perhaps should be OWL/RDFS non-specific altogether.

Suggested actions:

1. generalise PROF diagram keys to remove references to OWL/RDFS
2. better indicate that xsd:datatypes are not classes
3. consider E-R diagrams instead of class diagrams
4. compare with DCAT & other W3C specs for expectations
5. review all diagrams and their keys for consistency

[1] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0456.html

There has been much debate about the meaning of conformance and constraints. Given that the specification follows https://www.ietf.org/rfc/rfc2119.txt anyway, we should harmonise terminology with this spec:
i.e
constraints, restrictions etc => "requirements"

RFC 2119 also sheds useful light on different types of requirement and conformance implications. Profiles does not specify how conformance is ascertained or described - but the available role descriptions should reference these where appropriate. (needs a separate issue for that)

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

OWL Class is linked (https://www.w3.org/TR/owl-syntax/#Classes) but not RDF Property but it should be.

w3c/dxwg#642 provides an example - a suggestion that naming conventions might make examples easier to follow was provided - this issue provides for the opportunity to get feedback on this particular issue.

Note - a PR needs to be prepared and accepted for the provided examples so that these can be reviewed in the light of this issue.

The property chain axiom dct:conformsTo owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo ) ; is a "feature at risk" until discussion about its inclusion in PROF has reached a conclusion.

From Tom Baker et al. of the ShEx IG:

We wonder whether generic properties such as "hasExpression" or "documentedIn" might suffice to cover the simplest use cases for clustering profile-related resources.

Modeling these as [Profile->ResourceDescriptor] properties would more straightforwardly support scenarios in which a given profile-related resource were related to more than one other profile-related resource, but with different roles

hasArtifact currently says it is a URL (in the definition, no range given) but we want to allow it to be an inline literal, or a Resource etc.

• loosen the definition to remove "URL"

The Resource Role Mapping, if found to be necessary or useful, might need mappingFrom and mappingTo properties defined to indicate what is mapped to what.

https://w3c.github.io/json-ld-framing/

The profiledesc ontology has a role associated directly with a resource which it does not control. For example:

<https://.../dcat-ap-v11> prof:resource <http://data.europa.eu/...c096> .
<http://data.europa.eu/...c096> prof:resourceRole roles:Guidance .

This role is only true for dcap-ap-v11, and the same resource might have other roles in other contexts. For example a Guidance document for one profile might also include a constraints description for a different profile. Or more likely, a PartConstraints for one profile might be a FullConstraints for another simpler profile.

There are various solutions:

• Named Graphs. Not supported by many systems, and you only get to use the ace once (a triple can be part of only one named graph).
• Reification. Instead of resource, have a node between the Profile and the document that has the role associated with it. Compare the Web Annotation model for SpecificResource. Much more verbose, but good when the vocabulary of roles is open ended.
• Many Relationships. A simpler pattern but harder to extend -- each role is encoded in the predicate between the Profile and the document, eg hasPartConstraints vs hasFullConstraints. Good for implementations when the vocabulary is closed and relatively small.

Reification:

<profile1> prof:hasResourceWithRole <rr1> .
<rr1> prof:hasRole roles:PartConstraint ;
         prof:forDocument <constraint1>.

Relationships:

<profile1> prof:hasPartConstraintResource <constraint1> .

From https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Nov/0402.html:

1. the introductory sentence is opaque, abstract and provides no clues about the purpose/use of the document,
   replace by a more "introductory" section.

"An ontology for listing the set of resources required for a standard or a profile of one or more standards,
such as schemas, ontologies, and rules, and for specifying the relationships between them and supporting artefacts,
such as controlled vocabularies, validation tools, and guidelines."

2. section 1. Introduction
   "The profiles ontology provides a structure to describe profiles of information standards."

   • is the target of profiles really "information standards" or something like "digital contents"?

   • introduce the verb "profile" in a technical sense, i.e. as adding constraints resolved according to
     inheritance rules defined at X. Otherwise sentences like "Standards which do profile others" are hard to
     interpret

3. section 5. Conceptual model

   • the "profile of" relation between base and specialized specifications (profiles) does not match my naive intuition,
     a profile would -extend-> a base profile, while it is -profile of-> digital content that adheres to it?

4. section 6.5. Class: ResourceDescriptor

   • could not the dcat:Resource / Distribution content model be reused here to capture the implementation of the profile (part)
     (which does not match the "alignment PROF classes with DCAT 1.1")

5. section 6.5.4 hasRole

   • is there a (preliminary) vocabulary of roles (e.g. as given in examples) defined?

The RDF expressions of the list of Role individuals is as it was before 8 Roles were included in the HTML version of PROF and now the RDF needs to be aligned.

The example ResourceRole instances in this document are considered a "feature at risk" until the total list and definitions for them can be widely agreed to.

If not listed here, ResourceRole instances will be listed in a supplimentary vocabulary to PROF.

I guess the intention for profileOfTransitive was to replicate the modelling pattern adopted for the broaderTransitive and broader properties in SKOS.
In that case, I have two issues:

• I would consider renaming this property in "transitiveProfileOf". Of course, I leave the last word to native speakers but while "broaderTransitive" works well to me, "profileOfTransitive" is a little confusing, probably due to the 'Of" before "Transitive" which might be interpret as "profile of transitive" instead of "profileOf transitive".

• In order to replicate the skos:broader /skos:broaderTransitive, the following statement might be added

prof:profileOfTransitive rdf:type owl:ObjectProperty , owl:TransitiveProperty .
prof:profileOf rdfs:subPropertyOf prof:profileOfTransitive .
 

https://w3id.org/profile/vocpub is one of the examples in the Implementation Report. This profile needs to be fully fleshed out.

In order to support the case for PROF on rec-track, a detailed tabulation of evidence of implementation is needed.

VoID has a number of properties that relate Datasets (RDF-datasets only are considered). See if either PROF can recommend these for use for RDF datasets or re-issue them for more general use (non-RDF data).

Also see the VoID implementation projects such http://void.rkbexplorer.com/

Proposal: replace isInhertiedFrom with a more general property that allows any ResourceDescriptor to directly indicate the Profile that defines the ResourceRole of this resource.

Created on request from @nicholascar for "generating a cogent Use Case in time for a 2PWD"

In w3c/dxwg#273 (between w3c/dxwg#273 (comment) and w3c/dxwg#273 (comment)) the notion of different levels of conformance was proposed, together with the idea that one of these levels is the 'most authoritative' one, which can be seen as a 'center' for validation rules.

I do have some issues with the Profiles Ontology at https://w3c.github.io/dxwg/profilesont/, mainly with the definitions.

1. several definitions are substitutions in the template "A [Domain] [property label] [Range]" (e.g. "A dct:Standard has a Profile") which is not really helpful, as it makes the definitions circular (e.g. hasProfile, hasResource, isProfileOf etc.). Others still use the same words: e.g. property hasRole "Functional role of an Resource"; hasResourceRole "The role that an Resource plays". Terms like "functional", "role" and "Resource" need to be explained. Actually, from the definitions of hasRole and hasResourceRole, it is not immediately clear what the difference is.

2. Other terms that should be explained are "aspect" (in the definition of Resource Descriptor), "artifact (resource)" (in the definition of hasArtifact) and "implementing resource object" (in the Usage Note for hasArtifact).

3. Not all definitions use the same style, e.g. some have "A ..", other have "The ...", still others do not start with an article, and the definition of hasToken starts with "A property for ...". This should be made consistent.

4. The usage note of Resource Descriptor (as I wrote in GitHub, I think this is a really bad name) puts constraints (using "must" twice) on the way it is to be implemented. It might be better to formulate this as suggestions rather than obligations, e.g. "the formalism used can be expressed using dct:format and any adherence to a dct:Standard can be expressed using dct:conformsTo to allow for machine mediation. For human understanding, its purpose can be expressed via a relation hasRole to a ResourceRole".

5. Dublin Core terms are sometimes given as dct: and sometimes as dcterms:.

6. The document needs a spelling/grammar check. There are broken sentences (e.g. "Base Specifications or Profiles can have Resource Descriptors associated with them that defines implementing rules for the it"), misspellings ("GeoDCAt", "RDf", "StatDTAC-AP", "available", "summarises") and singular/plural errors (A vocabulary .. are provided").

I tend towards voting -1 if those issues, in particular 1 and 2 above, are not addressed, as I think these issues make the document hard to understand for an outside audience. However, because I am late with my comments, I can vote -0 if people think these are all minor issues that can be repaired in 2PWD.

see http://ga.surroundaustralia.com/sparql in Chrome

prof:hasResource always points to a Resource Descriptor, not the resource itself which is indicated by the ResourceDescriptor 's prof:hasArtifact property, therefore prof:hasResource is missnamed. prof:hasDescribedResource would better indicate what the property's doing.

This Issue contains suggested additions to the Roles vocabulary.

The Resource Descriptor class' name may not convey its intention well. This name needs to be reconsidered with discussion about it here.

I have a comment regarding this part of the conceptual model:

Why is "Profile" present as a class?

I would be inclined to model this part as follows (UML-style model, as that's what I'm used to...):

So

• a specification can have one or more a base specifications (that are instances of Specification)
• a specification can have one or more profiles (that are instances of Specification)

This model also implies not using dct:Standard ("A basis for comparison; a reference point against which other things can be evaluated.") at all.

The information that is currently modelled with ResourceDescriptor and its relations, couldn't that be generalized to specifications in general, and be useful?

Note: I used "specification" as that term is used in several places in the set of documents of profiles. Other place mention "standard".

The Editor's Draft of PROF contains an updated example that characterises a ShEx resource for a profile, Example 4 [1].

[1] https://w3c.github.io/dxwg/prof/#eg-isInheritedFrom

The example is not specifically about ShEx or similar but it does contain the following RDF which lakes about a ShEx resource:

# example standard
# with a single resource indicated for this Standard
ex1:Standard_X
    a dct:Standard ;
    dct:title "Standard X" ;
    prof:hasResource ex1:RD_1 .  

# example ResourceDescriptor for Standard X
# using the ShEx Expression Language
# in the JSON format
# this ResourceDescriptor is to validate instance   
# data claiming conformance to Standard X
# the actual file the ResourceDescritor describes
ex1:RD_1
    a prof:ResourceDescriptor ;
    dct:conformsTo <http://shex.io/shex-semantics/> ;               
    dct:format <https://w3id.org/mediatype/application/json> ; 
    prof:hasRole role:validation ;
    prof:hasArtifact ex1:constraints.json .                                    

@tombaker, @ericprud: could either of you please indicate whther this looks like a sensible characterisation of a ShEx resource in PROF?

Specifically, the URI identifying the ShEx spec is a best guess URI since, as far as I'm aware, there is no specific "conformance target" URI specified for ShEx. If there is a better URI that we could use, please let us know!

The links at https://www.w3.org/ns/dx/prof/ are pointing to out-of-date content. Can the static resources be updated or, better, pointed to the latest repo content?

JSON-LD has contexts and other features that look a bit like profiling. PROF should align/differentiate with/from JSON-LD, if not in a whole subsection at least in text somewhere.

If the PROF resourceDescription is analogous to the DCAT distribution, it is a description of a physical resource, essentially a file. The PROF role is the relationship between a profile and a resource. It is not the nature of the resource, and the resource can have different roles in association with different profiles. I can only think to illustrate this with a (crude) diagram:

Also note that with inheritance of resourceDescriptions, that inheritance implicitly includes the role, which may not be appropriate.

Among the possible solutions are:

1. make role a property that links the profile to the resource
2. ?? (I can only think of that one; surely there are others)

Currently there is no way, in PROF, to say:

Class X has constraining elements in Profile Y

How do we say <Profile_Y> constrains <Class_X> ?

The motivation for this is that we want to be able to do a reveres look up to know what Profiles (Specifications) are relevant to what classes so that people can know, per class, what Profiles they should consider.

Suggested properties could be:

prof:constrains
    a owl:ObjectProperty ;
    rdfs:domain prof:Profile ;
    rdfs:range owl:Class ;  # or perhaps rdf:Resource
    rdfs:comment "A Profile constrains, that is places restrictions on the use of, a Class"@en ;  # ...of, a Resource
    rdfs:label "constrains"@en ;
.

prof:isConstrainedBy
    a owl:ObjectProperty ;
    owl:inverseOf prof:constrains ;
    rdfs:label "is constrained by"@en ;
.

Motivated by the suggestion here w3c/dxwg#808 (comment) and the points here w3c/dxwg#808 (comment) which are:

I have trouble with this characterization in DCAT:

"The main subject that differentiates PROF from DCAT is that PROF specifically addresses the notion of conformance – of profiles to specifications or other profiles – about which DCAT is silent. DCAT does address the notion of instance data conforming to an "established standard" (see it's suggested use of the dct:conformsTo property and here – instance data conformance to specifications – DCAT and PROF offer compatible instructions. "

My problem is that it's kind of saying "the apples don't look like oranges". That DCAT does not address conformance between distributions is logically irrelevant to DCAT. So I wouldn't put this in a description of differences because I don't think it makes sense. DCAT and PROF have distinctly different functions. It WOULD be interesting to explain more about what it means that PROF borrows those structures. Right now there is only one sentence, and I'm not sure that it gives much information to someone who doesn't know DCAT.

"PROF borrows its main structures from DCAT in that PROF's prof:Profile & prof:ResourceDescriptor classes parallel DCAT's dcat:Dataset & dcat:Distribution classes. "

Something perhaps about the profile/dataset classes represent abstract works, and that these works are expressed in distributions which embody the meaning of the abstract work. (OMG, that's even worse! Sorry, but maybe you can see what I mean.)

This is to indicate that expected values of this property are not RDF nodes (named noes or blank nodes) but terminal values, e.g. a URL

EXAMPLE 3: Demonstrating conformance via the vocabulary's dct:conformsTo/prof:isProfileOf property chain.

Profile X, is a profile of Specification Y

http://example.org/profile/x a prof:Profile ;
prof:isProfileOf http://example.org/specification/y
dct:title "Profile X" .

missing ";" at the end of the penultimate line

In w3c/dxwg#642 I have expressed a concerned that some properties (at prof:transitiveProfileOf) look like 'utility properties' that are of lesser interest for most implementers. I.e. these implementers could mint their own property and derived statements with it from other statements, the same way that skos:broaderTransitive is in SKOS.
At a minimum, they could be kept for amateurs only ;-) and put in an "advanced" section.

@andrea-perego and @akuckartz have expressed some level of support.

Of course this is not an urgent issue, perhaps not even in the medium term, but it would be nice to help readers get a better feeling of the level of 'core-ness' of the various PROF properties.

A small set of roles has been included in the PROF document as a starting set. That set is:

• constraints
• example
• guidance
• mapping
• schema
• specification
• validation
• vocabulary

There are questions about the definitions in a Google doc that are still not addressed and may need additional discussion. Also, we need a general consensus on whether these are the roles that the group feels are the basic ones to be included.

As in the title...
This came to mind while writing the ESWC paper.
The property is not super-clear in https://w3c.github.io/dxwg/profilesont/ and there's no example for it.

Actually one could question whether it is needed, or whether it is just a "utility properties" to be derived from other statements, the same way that skos:broaderTransitive is in SKOS. That is to say, that they could be kept for amateurs only ;-) and put in an "advanced" section.

Currently PROF roles are defined in their own namespace, separate from the "base" one for PROF.
In w3c/dxwg#535 and w3c/dxwg#536 points have been made for and against having them in separate namespace. But that discussion was mixed with the discussion on whether they should be documented in the same document as PROF, which is slightly different.
In the end I am not sure there has been a definitive argument for keeping roles in the same namespace. So I would like the WG to re-examine this.
Maybe to there has been progress on the front of possible W3C registry (such registry was envisioned at one point as a possible place for a role vocabulary).

In the meantime I think there should be a note acknowledging the issue in the role section of the PROF spec, asking for commenters to give feedback.

NB: I believe this is not a blocking issue for moving to CR.

This issue supersedes several redundant issues to motivate a complete review of PROF's hierarchy transitivity.

Profiles include "functional" profiles, such as examples for OGC services (a prime motivating use case for design and implementation of profiles) - and the Conneg document needed to distinguish between profiles of the specfication itself and the data profiles that are being negotiated.

Proposal:
Add a subclass of Profile called DataProfile which carries the "data profile" definition agreed and does not restrict the usefulness of the general model.

Pros:

1. makes it clear that profiles may be data profiles
2. makes it clear that other types of profiles may exist
3. makes it possible to distinguish that a particular profile is specifically about requirements for data content rather than functional behaviours.

Cons:

1. (now redundant ) not originally modelled because "data profile" wasnt originally an identifiable thing with an agreed definition
2. begs the question whether other sub-types should be modelled
3. redundant if systems declare what the profile is about in other ways

Those "cons" I think can now be dismissed - we dont have time or motivations to agree definitions for other sub-types and absence doesnt impact utility of what is modelled, and we dont have canonical ways to describe the scope of a dct:Standard available, so this subClass has semantic value.

dcterms:identifier can act in all the ways we've specified prof:hasToken to act (same datatye pf xsd:token too) but we save the hassle of introducing a new property.