Should a server list all profiles it supports, even those in a hierarchy

[nicholascar]

A server might support DCAT, DCAT-AP (profiling DCAT), GeoDCAT-AP (profiling DCAT-AP), StatDCAT (profiling DCAT-AP) etc. Should it list all of these or just the leaf node profiles?

[smrgeoinfo]

From the point of view of a client, it seems that it would be simpler if all profiles supported were listed, rather than requiring the client to be aware of or figure out hierarchical relationships.

[tombaker]

@nicholascar StatDCAT "defines a certain number of additions to the DCAT-AP model". So is DCAT narrower than DCAT-AP, which is narrower than StatDCAT? Or the opposite? Does it even make sense to characterize one as "narrower" than the other? The position of @smrgeoinfo seems the most realistic, but I'd take that one step further and assert that people creating metadata about supported profiles, or machines deriving such metadata algorithmically, should not be expected to be aware of or figure out the nature of relationships between profiles.

[nicholascar]

@tombaker

is DCAT narrower than DCAT-AP, which is narrower than StatDCAT? Or the opposite? Does it even make sense to characterize one as "narrower" than the other?
We understand profiling to be about conformance to, not narrowness of element (class etc) element definitions so something that extends something else with more or specialised class definitions is profiling it.

So if DCAT-AP instances conform to DCAT, DCAT-AP, however constructed, is the profile. If DCAT instances don’t necessarily conform to DCAT-AP, it’s not the profile.

So yes StatDCAT-AP profiles DCAT-AP which profiles DCAT, as per the example of a hierarchy in PROF.

I’m not sure if we’ve used the term ‘narrower’ much, we shouldn’t, ‘conforms to’ is better. I’ve updated this Issue description to remove ‘narrower’.

[tombaker]

@nicholascar CONNEG talks about "adherence". Is that the same as "conformance"? I note that neither term is used or explained in the section on definitions.

[rob-metalinkage]

it looks like we are having to fill a hole in the general concept of specifications - so we have a choice

1. expand the scope of profiles ontology to capture core issues around specification conformance (i.e. a conformanceTarget property on dct:Standard or some subclass
2. ignore it and take it as read that these are well understood concepts
3. continue to add more and more explanation of every word used in definitions into text (i'm not sure this ever ends - its a recursive process)

consistency in the terminology and some formalism (option 1) may be the most useful approach -it does something useful at the implementation level, and we can then tweak definitions to highlight the concept.

[nicholascar]

+1 @smrgeoinfo's comment #932 (comment): we should list all profiles.

[aisaac]

+1 @smrgeoinfo @nicholascar
Whatever definitions we add, requiring clients to use the "hierarchy of profiles" is going to be very demanding, as they would have to follow their nose to the profile description and then do some inferencing over the links they find there.
I think enabling such thing to happen is good, especially in case the data services are "lazy" (i.e. for some good or bad reason or another they only publish a subset of the profiles they conform to, see note) but we shouldn't require it. So servers SHOULD list all profiles they support.

Note: there's a limit to our recommendations though, and this where the "inferencing" would be useful: first, the designers of a service may not be so much aware of profile derivations for the specification they use. Then it could be that designers of different agents don't have the same perception of what qualifies as a "relevant" base for a profile. I.e. a DCAT-AP server could count only DCAT as a valid base profile, and thus advertise these two profiles. But others (and we had this discussion) would consider Dublin Core to be a relevant base profile too, as DCAT re-uses some of it. We won't solve that I believe, so we have to engineer around it. And with I believe so far we're quite in a good position for this, with that PROF enables us to do.

[rob-metalinkage]

Addressed along with #603 and #1040 in PR-1037