Must a DCAT profile validate against all of DCAT?

[agreiner]

In section 4, where we define DCAT profile, we say "A data catalog that conforms to the profile also conforms to DCAT." That means one cannot make a profile with DCAT as a base and also use terms from another standard that conflict with terms in DCAT that are not used in the profile. Are we simply reserving the name "DCAT profile" for when the profile does validate? If not, I see an issue here.

[smrgeoinfo]

Seems that the upshot of the discussion at #486 is that a resource instance that conforms to a profile MUST also conform to any specification linked via the profileOf predicate.

[makxdekkers]

@agreiner I think you are right, and I think that it make sense to have the obligation that a profile P of base specification B does not violate rules set for B.

[kcoyle]

@makxdekkers The key to this hinges on "violate rules set for". Conformance needs to be carefully defined. As @agreiner says above, it could mean that no additional terms from other vocabularies can be included, because those do not "conform" to DCAT. That would make the DCAT-APs all non-conformant. It also could mean that all classes and properties in the base specification are actually or algorithmically included in the profile. This would result in declaring profiles that are subsets of a large vocabulary non-conformant.

The DCAP (Dublin Core) uses a concept of conformance that is not based on entire vocabularies but instead includes only those classes and properties that are included in both the base and the profile. In that view, a property included in a profile must not conflict with the property as it is defined in its base vocabulary. There is no attempt to create equivalences or conformance between entire profiles. For that reason, the conformance rule is relatively simple.

Essentially, it makes no sense to talk about conformance until it is clearly defined.

[makxdekkers]

@kcoyle It also is dependent on what it means to be a profile. We had that discussion at one point at DCMI when someone asked whether you could call something a profile of Dublin Core if it only contained one DC property. Also, on the basis of what you write about the DCAP, DCAT itself is a profile of DC -- as it specifies the use of DC terms for the description of datasets.

[kcoyle]

@makxdekkers "... DCAT itself is a profile of DC..." I struggle with the difference between a profile and a vocabulary that "borrows" from other vocabularies. I'm not convinced that DCMI made a clear distinction. However, I detect in the profiles ontology that there is a notion of profile that is not the same as a vocabulary. Unfortunately, it's not made explicit. We need to tease that out.

[makxdekkers]

@kcoyle You are right. I was just looking at the definition of a DCAP. Other than that, it has been argued that a BaseSpecification is a kind of profile, one that does not specify rules and constraints on other specifications. At DCMI, sometimes the 15 elements have been called a (simple) profile of DC. The point with DCAT is that it embeds DC (and FOAF and vCard and SKOS) classes and properties in the human-readable spec -- but not in the namespace document.

[davebrowning]

Useful to clarify the status (and responsibilities) of this in the context of DCAT2 CR. The existing document has made no normative (and little non-normative) change to the text from 2014. Some of the issues here are tangled up with subjects that might get covered in profile guidance - the issue of competing/conflicting definitions in 'source' specifications seems to me to be a general profile design concern.

So I believe we're really just reserving the term DCAT profile as @agreiner originally asked. If future work on profiles provides a more expansive/coherent way of doing this then it would constitute new work to align.

Comment?

[aisaac]

I agree that strictly defining conformance is not appropriate for DCAT2. Well to be more precise, I think the current conformance section is doing a good enough job for it.

In my reading this week, I however encountered a problem that I think no other document than the DCAT2 spec can address: the issue of determining what is "all of DCAT" (as per the title of this issue) for defining profiles and conformance. Namely my problem is with terms from external namespaces. The paragraph external terms in the intro says

conformance to DCAT (§ 4. Conformance) concerns usage of only the terms in the DCAT namespace itself

Section 4 includes the following sentences:

The contents of all metadata fields [...] are expressed using the appropriate classes and properties from DCAT, except where no such class or property exists.

Additional constraints in a profile MAY include [...] Sub-classes and sub-properties of the standard DCAT classes and properties; Classes and properties for additional metadata fields not covered in DCAT.

This leaves me quite puzzled, about how one should consider the external terms. It is indeed hard to understand that section 4 would consider that elements "from DCAT" or "standard DCAT classes and properties" would not include something like foaf:homepage. Otherwise this means that foaf:homepage is an "additional metadata field not covered in DCAT". And thus every specification that adds foaf:homepage to the core DCAT namespace would be a DCAT profile. But this means that the specification described in the DCAT2 CR is a profile of DCAT, not DCAT itself! This sound odd. So I'm concluding that for section 4 foaf:homepage is in DCAT. But that is at odds with the paragraph on external terms.

NB: I'm happy to move this to another, new issue if the raiser of this issue (@agreiner ) thinks it's out of scope.

[agreiner]

@aisaac I think this is a different issue, though it is clearly related. For myself, I think a term is internal to DCAT if it is used in DCAT. That includes foaf: homepage and the like.

[riccardoAlbertoni]

@aisaac I think we refer to external terms as those not included in the vocabulary specification, section 6.

If the other editors (@andrea-perego, @dr-shorthair, @pwin, @davebrowning, @agbeltran ) agree on my interpretation, One option would be replacing "the DCAT namespace itself" with "DCAT vocabulary specification".

conformance to DCAT (§ 4. Conformance) concerns usage of only the terms in the DCAT vocabulary specification DCAT namespace itself

and the last occurrence of "DCAT" with "DCAT vocabulary specification" in

Additional constraints in a profile MAY include [...] Sub-classes and sub-properties of the standard DCAT classes and properties; Classes and properties for additional metadata fields not covered in DCAT vocabulary specification

Would this limit the oddity?

[aisaac]

@riccardoAlbertoni thx! More than limiting the oddity, I think this would completely solve my issue. So maybe we don't need to create a new one :-)

[pwin]

I''m in agreement with this proposed change

On Tue, 24 Sep 2019 at 21:02, aisaac notifications@github.com wrote:

@riccardoAlbertoni https://github.com/riccardoAlbertoni thx! More than limiting the oddity, I think this would completely solve my issue. So maybe we don't need to create a new one :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/430?email_source=notifications&email_token=AAIFYTC7A5NMZDD6DRI25WDQLJW4LA5CNFSM4FYUK6O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7PT7OY#issuecomment-534724539, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIFYTB4W3UC5SHDE5MFXNTQLJW4LANCNFSM4FYUK6OQ .

[dr-shorthair]

Future Work? maybe due-for-closing

[aisaac]

Now that my side problem is resolved, maybe the issue can be closed?

The text pointed in @agreiner is quite clear to me. Even if the general rules about profiling and conformance are a subject of discussion (see PROF issues on the matter), it seems quite legit that an individual specification like DCAT could make such rule to assess whether a specification based on DCAT counts as a valid profile.

[andrea-perego]

Thanks, @aisaac .

@agreiner , do you agree we can close this issue?

[agreiner]

If we are just reiterating text from DCAT 2014, then I think it's okay to stay in there, the claim has already officially been made. My concern here is putting in a new requirement for something we don't really understand (conformance of profiles to what they "profile"). I do want it to be possible to reuse parts of multiple specs in a profile as desired by the community or app.

[agreiner]

Just to note a thought here for possible future work: we might distinguish profiles that conform to their base spec(s) and those that do not with conformsTo, once we understand what conformance actually means.

[rob-metalinkage]

this is a strange conversation to be having at this point... you just use prof:profileOf (or some other relationship with those specific semantics) to distinguish conformsTo transitivity and some other relationship such as voaf:usedBy for other relationships that are useful to know but do not necessarily carry any conformance implications.

As always, if you have a different functional requirement that matters you just need to identify or create a vocabulary term to uniquely identify that relationship. At any rate it doesnt affect the right of DCAT to specify what conformance means in its case.

[dr-shorthair]

Appears to be stale/overtaken.

[agreiner]

I think we have one part of this that is resolved and one part that is not. As @kcoyle pointed out, we still don't really have a robust definition of conformance for a profile. If we end up writing guidance for using profiles, we will want the reminder here to put in something more precise. I will admit to some lingering concern about the statement that a profile of DCAT must not deviate from DCAT with regard to any part of the spec. One reason to make a profile would be to document that one is using DCAT with a tiny exception. If we feel that it's more important to have a guarantee of conformance than to accommodate such use, we are doing the right thing currently. I guess I just want us to be clear on that. And if we agree that a conformance guarantee is important, that makes me wonder whether we should be defining a subset of terms that must be used. For example, does it make sense to say that a catalog record is DCAT conformant if the dataset has no URL? No title? How useful is conformance in that case? And if we include all the non-DCAT terms that we mention in the spec as part of the conformance, what is the difference between something that we give the dcat prefix to and something we do not?

[rob-metalinkage]

There are a few separate concerns here - the first is that the specification needs to define its own conformance rules - it may for example provide a series of tests that must be passed. Neither DCAT (nor PROF) should attempt to over-define this.

Secondly, if "conformsTo" = "may nearly conform to" then its impossible to tell how near, and the statement wont have much value - so a different predicate with those explicit semantics should be created if necessary.

Thirdly, in the case of a "near miss" you can refactor your profile hierarchy to exactly match your intent. You could define a profile that is an effective subset, then declare both the original and your slightly deviant profile to both profile this super-profile. DCAT prof:isProfileOf myDCAT-subset, myDCAT-inspired-model prof:isProfileOf myDCAT-subset. These statements only need to exist within your own domain (i.e. can be in a separate alignment ontology mapping DCAT. How the subset is expressed is up to you - chose the constraint language of your choise, e.g. SHACL - but the extent of overlap is now explicitly modelled and the semantics of dcterms:conformsTo is preserved.
The other choice is to somehow tell the user that your idea of "conformance" doenst mean the same as DCAT's - this is much trickier to imagine a canonical mechanism to achieve this.

[aisaac]

This sounds like one of these overarching discussions that was supposed to be put in perspective by the profile guidance, as @agreiner says. The DCAT space has made a choice of strict conformance so far, and I am ok with it. But perhaps we can keep the issue in the DCAT backlog, in case some feedback comes? In fact at a stage where DCAT has been wonderfully progressed since the beginning of this issue, maybe we could put an issue note calling for feedback from implementers?

(and a process point: even though it points to profile guidance, related to yesterday's discussion about cleaning up our github space... I still consider this issue here to be specifically about DCAT. So maybe we keep it in the DCAT github repo but label it with 'profile-guidance')

[andrea-perego]

@aisaac , as far as DCAT is concerned, I'd rather create a separate issue, asking for feedback (as you suggest), and keep this one linked specifically to the Profile Guidance deliverable. We can of course keep it here in the DXWG repo - unless we eventually decide to move the Profile Guidance deliverable to a separate one.

[aisaac]

@andrea-perego I'm also fine with your alternative, if you think this issue here is already too noisy/general for DCAT.

[andrea-perego]

@aisaac said:

@andrea-perego I'm also fine with your alternative, if you think this issue here is already too noisy/general for DCAT.

I think it is indeed a general one. For DCAT, this boils down to whether the conformance statement in the spec needs to be revised based on existing implementations.

[andrea-perego]

Issue created: https://github.com/w3c/dxwg/issues/1332

Removing "dcat" label and adding "profile-guidance".