Profile definition [RPFDF]

[jpullmann]

Profile definition [RPFDF]

Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the profiles of DCAT they conform to.

These Use case specific requirements apply to the required scope of this definition. Where appropriate these are also captured as additional requirements.

1. Clarify any relationship between profiles and validation languages
2. Profiles have URI identifiers that resolve to more detailed descriptions
3. Each application profile needs to be documented, preferably by showing/reusing what is common across profiles
4. Profiles should provide both machine and human readable views.
5. Profiles may inherit clauses from one or more parent profiles
6. Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in.
7. Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to.
8. Conceptually, profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (#ID37)
9. Responses can conform to multiple, modular profiles (#ID3)

Related requirements: Profile representation [RPFRP] Profile negotiation [RPFN] Profiles listing [RPFL] 
Related use cases: Detailing and requesting additional constraints (profiles) beyond content types [ID2] Responses can conform to multiple, modular profiles [ID3] Discover available content profiles [ID5] Description of dataset compliance with standards [ID43] Profile relation to validation [ID48] 

[makxdekkers]

Point 1 (relationship between profile and validation languages) is important. In a way, a set of validation instructions (such a contained in a SHACL file) can be considered a machine-readable expression of a profile.

[dr-shorthair]

Over on https://github.com/w3c/dxwg/issues/111 we are discussing DCAT dependencies and alignments. And on https://github.com/w3c/dxwg/issues/110 we are considering a wholesale relaxation of some of the global (domain range) constraints that were used in DCAT v1. One possibility is to move these into separate RDF graphs (files) so that users can select the level of axiomatization and alignment that they need - following an approach to 'vertical and horizontal modularization' pioneered in SSN/SOSA.

This is beginning to look like another aspect of 'Profiles', right?

If so, then this would also be an aspect of #75

[aisaac]

I've noted the assignment and will try to come back to this issue next week! Sorry for the delay @dr-shorthair

[dr-shorthair]

The definition of 'profile' says "A profile is a named set of constraints on one or more identified base specifications ...". However, the heritage of the various *DCAT-APs and the tenor of much of our discussion is that a profile has just one (main?) dependency, typically DCAT - e.g. @nicholascar wrote "we say that a Profile is a profile of something else". The word 'profile' pulls you that way, but we should be careful to not exclude the compilation of standards that have multiple dependencies.

FWIW A decade back OGC developed a model for 'modular specifications' which focussed primarily on recording the dependencies. Dependencies are between modules within a specification (aka standard) or across specifications, each of which groups a set of normative requirements into a convenient grouping, so dependencies are at a convenient granularity. In some cases there is a single 'base' or 'core' - being a module that itself has no dependencies. But in other cases more than one module has no dependencies so there is no 'base'. But it is the dependency chain that matters.

See Configuration management of a system of interdependent standards and The Specification Model — A Standard for Modular specifications for more detail

[rob-metalinkage]

it explicitly says "one or more"

profiles may have an empty set of constraints (and just bind multiple sets of requirements into a named profile). any specification is a trivial profile of itself (like A rdfs:subClassOf A)

[dr-shorthair]

Yes - that is why I quoted the document. But the discussion elsewhere implies that a profile has a single base. "... a Profile is a profile of something else" has a singular object, and the diagrams show just one dependency.

In the OGC context I found myself continuously reminding people that the special thing about a base or core module is that it has no dependencies. It is not that there is only one of them. I'm trying to head-off that fumble at the outset here.

[aisaac]

@dr-shorthair I guess we have to live with the fact that in our more informal discussions we will often consider the simple case, for simplicity of the exchanges (which are already quite complex ;-) ). But yes I agree with you and @rob-metalinkage we should always check that in the final result of the discussions there's nothing that restricts to being a profile of only one base! If just because I've co-submitted a case that needs these multiple bases...

[agbeltran]

Including here comment by @kcoyle to the mailing list about this issue: https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Sep/0400.html

I apologize that I missed this in my earlier review of the document. The
DCAT draft says:

"Issue 72

DCAT provides a generic metadata vocabulary for cataloguing datasets.
Profiles of DCAT are required for specific applications and disciplines.
Providing a model and formalization for DCAT profiles is planned to be
an important part of this revision. Also see Issue #73, Issue #74, Issue
#75."[1]

Two things about this:

1) The issues cited here have been generally considered to be relevant
to the profile guidance document, not the DCAT revision. Issue 72 has
the label DCAT but that issue does not seem to have been revisited much
since it was created. Issue #75 has been closed.

2) I believe that we determined, with the help of Phil Archer, who
authored the charter, that the profiles guidance is not intended to be
guidance for DCAT profiles but for profiles in general, so a promise of
a "formalization for DCAT profiles" isn't what we'll deliver.

Therefore, it would seem that this section (12 in the current document)
should point to the (future) profile guidance document and not state
that "formalization for DCAT profiles is planned". There may be other
useful things to say her about DCAT and profiles; we can add that to the
agenda for the F2F where we intend to review (and solidify) the
relationships between the deliverables.

[1] https://w3c.github.io/dxwg/dcat/#profiles

[rob-metalinkage]

We have a common profile definition in use in all docs. Can we close this?

[kcoyle]

The wording I mention in https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Sep/0400.html is still in the document. Let's keep this open until that is gone. It's a note so I'm pretty confident it'll eventually be removed.

[larsgsvensson]

Any views from the DCAT team on the suggestion to remove the note at https://w3c.github.io/dxwg/dcat/#profiles and close this issue?

[kcoyle]

pinging @davebrowning @agbeltran This is really just a formality, but can the note be removed? thanks.

[agbeltran]

@kcoyle @larsgsvensson @rob-metalinkage just to clarify, are you suggesting to remove the reference to this issue (in red) or the note (in green) or actually removing the whole section entitled 'DCAT profiles'?

I think it is ok to remove the reference to this issue, but I think it would be good to keep the section on 'DCAT profiles' adding some more text and pointing to the Profiles guidance document.

Does that work for you?

[kcoyle]

My main worry is about the sentence in the red box that reads: "Providing a model and formalization for profiles is planned to be an important part of the Dataset eXchange Working Group (DXWG)." Because in fact we will not be doing that. But I also assume that the red boxes with issues will not be in the final draft of the document.

Admittedly, having a section called "Profiles" (section 15) but with virtually no text doesn't seem very useful. If there isn't going to be more text I'd rather see the section removed. The introduction gives the profiles as a motivation for the update to DCAT, and that might be enough.

[larsgsvensson]

The only thing I can imagine would go into the section "Profiles" (§15) would be a general discussion of existing or future profiles of DCAT (e. g. DCAT-AP, GeoDCAT-AP, DCAT-AP.de etc.) and then a reference to the other profile documents, particularly profgui. Otherwise I think the section can be removed.

[agbeltran]

@larsgsvensson that's exactly what I had in mind

[agbeltran]

@kcoyle @larsgsvensson PR https://github.com/w3c/dxwg/pull/779 address removing the note and adding some text for DCAT profiles - would this be OK?

See pre-view: https://rawgit.com/w3c/dxwg/dcat-issue72/dcat/index.html#profiles

[rob-metalinkage]

NB At this stage I see little prospect for a separate Guidance deliverable being available, given the level of contribution and the need to focus on deliverables that enable implementations - guidance without mechanisms is not very useful.

[kcoyle]

@agbeltran Yes, that looks good, thank you. @rob-metalinkage You may be right, so let's keep this in mind for CR. It might be best in any case not to refer to other documents that are not themselves already recommendations. @agbeltran could you remove the note, just to be careful? Thanks.

[agbeltran]

thanks @rob-metalinkage - in that case, it would be better to remove the reference to the guidance document for now - @kcoyle @nicholascar @aisaac

[agbeltran]

@agbeltran Yes, that looks good, thank you. @rob-metalinkage You may be right, so let's keep this in mind for CR. It might be best in any case not to refer to other documents that are not themselves already recommendations. @agbeltran could you remove the note, just to be careful? Thanks.

ok - will remove reference to other documents

[andrea-perego]

There has not been further discussion on this issue.

I propose to close it.

[fanieli]

Hi all,

I have stepped down for the dxwg, so think it is best for you to decide.

Thanks ixchel

From: Andrea Perego notifications@github.com Sent: Wednesday, October 28, 2020 7:34 PM To: w3c/dxwg dxwg@noreply.github.com Cc: Faniel,Ixchel fanielI@oclc.org; Assign assign@noreply.github.com Subject: Re: [w3c/dxwg] Profile definition [RPFDF] (#72)

There has not been further discussion on this issue.

I propose to close it.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/dxwg/issues/72#issuecomment-718267761, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG7OEMGPOKR7XCGZT3ZWECLSNCS6VANCNFSM4EMOJGAQ.

[aisaac]

As for other requirements I'm a bit lukewarm to close them for good as they are relevant for other areas of work. It could well be as efficient to untag DCAT from it. But well considering the fact that other areas of work may not be active anymore and that the splitting of github repos create quite some confusion on the fate of these 'shared' requirements, I'm not going to push to hard for keeping it!

[andrea-perego]

Thanks, @aisaac . We'll try to see if we can address it in the 2PWD for DCAT3.

[rob-metalinkage]

The requirements were captured as part of the UCR exercise - DCAT is profiled in practice so its certainly a useful thing for DCAT to define or reference a definition for what constitutes a profile of DCAT and what a user can therefore expect. Other areas of work (eg. PROF) are no longer using issues in this repo - active issues have been transferred and this repo is just historical background - so close if DCAT is not planning to do anything else with it. I suspect the "guidance" Note would need to pick this thread up again - but it should do so by analysing documented requirements in the UCR and allowing a new issue to be made for additional or changed requirements backed by any strong examples surfaced in the issues here.

[aisaac]

@rob-metalinkage ok fair enough. If this issue has been copied in the PROF repo then clearly we can ignore it. And @andrea-perego I was really not asking for DCAT to "address it", merely suggesting to untag it so that (precisely) DCAT wouldn't be bothered by it now :-)

[andrea-perego]

@andrea-perego I was really not asking for DCAT to "address it", merely suggesting to untag it so that (precisely) DCAT wouldn't be bothered by it now :-)

Fine, @aisaac . Just untagged.