Skip to content
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

Must a DCAT profile validate against all of DCAT? #430

Open
agreiner opened this issue Oct 3, 2018 · 18 comments
Open

Must a DCAT profile validate against all of DCAT? #430

agreiner opened this issue Oct 3, 2018 · 18 comments

Comments

@agreiner
Copy link
Contributor

@agreiner agreiner commented Oct 3, 2018

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.

@agreiner agreiner added this to To do in Profile Guidance via automation Oct 3, 2018
@agreiner agreiner added this to To do in DCAT revision via automation Oct 3, 2018
@agreiner agreiner removed this from To do in Profile Guidance Oct 3, 2018
@agreiner agreiner added dcat and removed profile-guidance labels Oct 3, 2018
@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

@smrgeoinfo smrgeoinfo commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Contributor

@makxdekkers makxdekkers commented Nov 15, 2018

@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

This comment has been minimized.

Copy link
Contributor

@kcoyle kcoyle commented Nov 15, 2018

@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

This comment has been minimized.

Copy link
Contributor

@makxdekkers makxdekkers commented Nov 16, 2018

@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

This comment has been minimized.

Copy link
Contributor

@kcoyle kcoyle commented Nov 16, 2018

@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

This comment has been minimized.

Copy link
Contributor

@makxdekkers makxdekkers commented Nov 16, 2018

@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

This comment has been minimized.

Copy link
Contributor

@davebrowning davebrowning commented Sep 23, 2019

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

This comment has been minimized.

Copy link
Contributor

@aisaac aisaac commented Sep 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@agreiner agreiner commented Sep 23, 2019

@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

This comment has been minimized.

Copy link
Collaborator

@riccardoAlbertoni riccardoAlbertoni commented Sep 24, 2019

@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

This comment has been minimized.

Copy link
Contributor

@aisaac aisaac commented Sep 24, 2019

@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

This comment has been minimized.

Copy link
Contributor

@pwin pwin commented Sep 25, 2019

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

@dr-shorthair dr-shorthair commented Sep 26, 2019

Future Work? maybe due-for-closing

@aisaac

This comment has been minimized.

Copy link
Contributor

@aisaac aisaac commented Sep 26, 2019

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

This comment has been minimized.

Copy link
Contributor

@andrea-perego andrea-perego commented Sep 26, 2019

Thanks, @aisaac .

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

@agreiner

This comment has been minimized.

Copy link
Contributor Author

@agreiner agreiner commented Sep 26, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@agreiner agreiner commented Sep 26, 2019

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 comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Sep 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
DCAT revision
  
To do
You can’t perform that action at this time.