-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should a server list all profiles it supports, even those in a hierarchy #932
Comments
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. |
@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. |
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’. |
@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. |
it looks like we are having to fill a hole in the general concept of specifications - so we have a choice
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. |
+1 @smrgeoinfo's comment #932 (comment): we should list all profiles. |
+1 @smrgeoinfo @nicholascar 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. |
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?
The text was updated successfully, but these errors were encountered: