Harmonise definitions across Profile docs

[nicholascar]

Currently the definitions sections for the Guidance & Ontology docs need updating and the Conneg doc is updated but now different and probably needs further updating.

We need to solicit feedback in the FPWDs on the granularity of definitions and, when we have a result, ensure that the same definitions are used in all 3 docs.

[rob-metalinkage]

Lets not reopen this - we put the DCAT-AP experience forward as an explicit Use Case and got it agreed - and it clearly shows DCAT-AP is supported by multiple resources. and it shows DCAT-AP usages illustrates both deep and multiple inheritance patterns. so lets not reopen those issues.

from now on we should focus on practical guidance on how to handle these realities in a consistent way in practice (e.g DCAT-AP was published as a dataset with distributions because that was the machinery available, but there is no formalism of relationships between profiles of DCAT-AP and DCAT-AP itself...)

[akuckartz]

@rob-metalinkage Did you comment the wrong issue?

[aisaac]

This issue is being discussed at https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jan/0047.html too.

[aisaac]

From @kcoyle: I don't know whether we want to re-open this, but I see a disconnect between our current definition of profile and the graph structure for profiles provided by the profiles ontology. Our definition was written before we considered the profiles ontology as describing profiles, and my impression is that we were considering "profile" to be a single resource like DCAT-AP. Should we lean more toward the multi-resource possibility of prof:Profile in ProfGui, and does that mean that we need to have a definition of profile that looks more compatible with the profiles ontology?

First, our definition states profile as a single thing:

"A named set ..."

which makes it compatible with prof:Profile. That's good. But then the definition moves on to say:

"A named set of constraints ..."

And this is where I begin to have issues. At the moment our definition goes on to say (in whole):

"A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function."

However, the profiles ontology does not mandate the existence of a resource with either the role ":fullConstraints" or ":partialConstraints", and it isn't clear to me if a prof:Profile with only one resource that has the role ":guidance" would meet our definition of profile. Therefore it may be necessary for the ProfGui document to mandate certain content to meet the definition of "profile" as we are using it.

In addition, nothing in our definition indicates that there can be more than one resource in this "set". I don't think that the one-sentence definition needs to do this but this becomes an issue for the guidance document that so far is not included there. This could become text for the section on Profile Description but I also think it needs to be introduced earlier on in the document. This would be where Antoine's revised diagram could be useful, and it may require a section in the profiles definition area that talks about the multi-faceted nature of profiles.

[aisaac]

From @aisaac:

@kcoyle Good questions. As I'm a bit hesitant to re-open the discussion on definition. Maybe the current one can be understood in a way that alleviates your doubts? (and that's perhaps a part of my action on aligning the view on this ;-) )

On the cardinality aspect, the fact that a profile is a named set (singular) of constraints doesn't rule out that there can be several expressions (i.e. resource descriptors) of this set of constraints, some of which may be partial.

On the question of mandating representations (such as the (human-readable) guidance to be a good expression of the constraints, I'm not sure we can do much. The enforcement of whatever PROF would say would have to rely on other mechanisms, as representations that play a guidance role certainly belong to a level which is not the one at which PROF operates (i.e. RDF or any other machine-readable implementation of PROF). I don't see other choice than doing a manual inspection of the representation. Or did you have something else in mind and I've not understood correctly the kind of thing you'd like to mandate?

[kcoyle]

@aisaac Since the guidance document is essentially a kind of "best practices" I think that we can suggest some best practices that could be implemented using the PROF ontology. Actually, I think that is indeed the role of the guidance document - not to say "anything goes, here's an ontology" but to talk about what is needed for a good "profile experience". Since this is just a document, some other mechanism (ShEx or SHACL, for example) would need to enforce that, but I don't think we need to supply that as part of our work. Do note that our definition states a "named set of constraints" so already that appears to be a defined requirement, although we haven't yet fully defined what we consider to be constraints within that definition.

As we move from talking about profiles as defined in our definition and talking about profiles as a set of resources (which I think will be a new concept for many readers) we have to decide how to do that and where it fits into the document. That's one of my concerns regarding the overall structure of the document - how we get from A to B in a way that readers will understand.

[aisaac]

@kcoyle I doubt that any existing technology like SHACL and ShEx can enforce a 'guidance' resource to fully meet what we expect in our profile definition, because these are just different levels. It would be a bit like assuming that a software testing suite can validate that an application meets its user requirements (acceptance tests), while this suite can only do low-level stuff such as unit testing.

Regarding the move from profiles as defined in our definition to profiles as a set of resources: this is indeed crucial. What I had in mind was to do this with the paragraph that starts with "A profile can have various Components/Manifestations in various expression languages" at https://w3c.github.io/dxwg/profiles/#whatisaprofile. But with the new general structure the message of that paragraph seems less visible than what it was. And anyway it was just a first try, certainly it can be improved!