Dxwg: Formally align PROF to DCAT

[nicholascar]

Formally include DCAT alignment in the Profiles Vocabulary. The alignment would be made like this: prof:Profile rdfs:subClass of dcat:Resource .

Changes

• prof:Profile rdfs:subClassof dcat:Resource .
• prof:hasArtifact replaced by dcat:downloadURL and accessURL
• prof:ProfileResource rdfs:subClassOf dcat:Distribution .

NB : prof:hasResource is not a sub-property of dcat:distribution because the domain of dcat:distribution is dcat:Dataset. Implementations may declare this is if required, to catalog profile descriptions using dcat:Dataset . prof:Profile and dcat:DataSet are not disjoint.

Why now?

• DCAT had not previously defined abstract dcat:Resource
• It was not clear if something described in a document could be a dcat:Dataset
• It was open for debate whether a dcat:Distribution was “informationally equivalent” to a Dataset

Pros

• Some PROF properties are able to be deprecated in favour of long-standing DCAT properties
• Other previously proposed PROF classes and properties can be interpreted in the light of DCAT classes and properties which are widely understood
• Use of DCAT indicates how to apply basic metadata properties to profiles since, if a prof:Profile is a dcat:Resource, then users would expect to see dtc:title etc. for it
  dcat:downloadURL and accessURL is more nuanced that hasArtifact
• Resolves the debate about whether to force properties of distributions to be attached to the accessURL or allowed in the cataloged component (e.g. dct:format)

Cons

• PROF now has a dependency on DCAT (revised) which is a new (implication: somewhat un-tested) ontology
• PROF has to both differentiate its classes and properties from other DCAT classes and properties while still being DCAT-compatible

Implications:

• Revisit if ProfileResource should be named more like Distribution (ProfileDistribution)

[kcoyle]

"Resolves the debate about whether to force properties of distributions to be attached to the accessURL or allowed in the cataloged component (e.g. dct:format)"

Please say more about this, because I do not see how this "resolves the debate." What about this would change the validity of the use of dct:format for a catalog record rather than a digital file?

A disadvantage that I would add is that this could render PROF less visible outside of the DCAT community. They are many communities creating profiles that do not use (or even know of) DCAT. That's fine if we want PROF to be a profiles vocabulary that is primarily in support of DCAT, but it does change the intended audience. It also means that we will need to change how or whether we address it in the profiles guidance document, since that will not be directly related to DCAT. (I don't know if it has any affect on the conneg deliverable.) This is a change that affects more than one deliverable, which means that we need to take a macro view of the effect.

An advantage to having PROF be specific to DCAT is that in a sense makes the work simpler because then there is no need to elicit and satisfy comments from other communities. It has a narrower audience, and one that we have already engaged with. From a process point of view, if the DCAT community is satisfied with it, we don't need to go further in terms of community review.

[rob-metalinkage]

"resolves" as in no reason _not_ to follow DCAT pattern.

no effect on conneg deliverable - this is about descriptions, not behaviours.

PROF would not be "specific to DCAT" at all - it would just use DCAT to support the same "cataloguing of resources" pattern - and arguably could introduce DCAT to a wider audience.

[kcoyle]

@rob-metalinkage What is not resolved is that following DCAT does not correct the issue with dct:format. It also does not resolve the question in #769 about separating roles from artifacts. Using the DCAT classes and properties may be fine, but Nick's final pro point is not correct here. And that is a very concrete reason not to follow the DCAT pattern.

[nicholascar]

The editors of PROF have decided not to formally align PROF to DCAT since PROF is all about a dependency (isProfileOf) that DCAT doesn't know anything about. There is no prohibition on using DCAT with PROF of course.

[kcoyle]

@nicholascar Who is we? Could you bring this to the full group for consensus, please. Given how thin we are on the ground, it being August, we can add this to the plenary agenda (cc: @pwin ) but may need to conclude it via email or poll.

I'm not sure where the original idea/issue came from. Could you include that information for the discussion? thanks.

[nicholascar]

Above commented edited: s/We/The editors of PROF/

The idea, for formal alignment, originated with me: I raised the Issue to test ideas and I proposed Pros & Cons as above.

The reason for not seeking alignment that I, as issue raiser, am happy with, is outlined in the comment above.

[aisaac]

PROF call 29 august: we agree that this is not a crucial issue. We keep the issue open for now but we think we could drop it. There is no formal requirement for it.

[nicholascar]

Closing after listing in plenary 2019-09-03 + 3-day wait period.

[kcoyle]

@nicholascar Antoine suggested keeping this open. It isn't crucial but we also shouldn't lose sight of it. I'm going to reference it in another open issue, and we may be opening yet another issue around this topic, but not exactly the same.

[nicholascar]

This issue was raised for the 2PWD release and dealt with for that release (informal alignment only).

The 3PWD candidate also has a Related Work section that talks about PROF v. DCAT in addition to the informal alignment in the Alignments section so it's got more info about the relationship between the two.

So, I think that if there is to be more consideration of the relationship between PROF & DCAT, in addition to other Issues like #529 referencing this, then a new issue should be raised for alignment in general, based on the 3PWD state.

[rob-metalinkage]

If you want to propose a new approach to this, or focus on some specific aspect that has emerged that doesnt affect the decision not to formally align, then just open a new issue for that. Leaving quite clearly addressed issues open because you might want to look at the topic in future or the discussion raises other issues just reduces our ability to focus on the merits of any specific concern or proposal. Issues should not open just because they are interesting or have gone off topic - its because there is some specific issue that can be identified and acted on.

[kcoyle]

I have trouble with this characterization in DCAT:

"The main subject that differentiates PROF from DCAT is that PROF specifically addresses the notion of conformance – of profiles to specifications or other profiles – about which DCAT is silent. DCAT does address the notion of instance data conforming to an "established standard" (see it's suggested use of the dct:conformsTo property and here – instance data conformance to specifications – DCAT and PROF offer compatible instructions. "

My problem is that it's kind of saying "the apples don't look like oranges". That DCAT does not address conformance between distributions is logically irrelevant to DCAT. So I wouldn't put this in a description of differences because I don't think it makes sense. DCAT and PROF have distinctly different functions. It WOULD be interesting to explain more about what it means that PROF borrows those structures. Right now there is only one sentence, and I'm not sure that it gives much information to someone who doesn't know DCAT.

"PROF borrows its main structures from DCAT in that PROF's prof:Profile & prof:ResourceDescriptor classes parallel DCAT's dcat:Dataset & dcat:Distribution classes. "

Something perhaps about the profile/dataset classes represent abstract works, and that these works are expressed in distributions which embody the meaning of the abstract work. (OMG, that's even worse! Sorry, but maybe you can see what I mean.)

[rob-metalinkage]

@kcoyle - thats all good points - can we move it to a new issue which addresses those called something like "improve description of relationship between DCAT and PROF" and close this one, since we are definitely not going to have time or interest to revisit the original topic and try to find a new motivation to do a formal alignment.

[aisaac]

Actually I do have one comment about the alignment, as I'm looking at conformance discussions again...
The sentence that @kcoyle noted raises a big issue for me, as it seems that much more could be said to align with DCAT, rather than to differentiate from it, and this could be useful for all the discussions around PROF and conformance...

My starting point is that DCAT actually says quite a lot about conformance:

• https://www.w3.org/TR/vocab-dcat-2/#Property:resource_conforms_to
• https://www.w3.org/TR/vocab-dcat-2/#conformance
• https://www.w3.org/TR/vocab-dcat-2/#quality-conformance
  The latter two are not acknowledge in the current PROF section on DCAT alignment (unless it was meant as an hyperlink for a "here" at the end of the section, that doesn't link to anything)

So the story should be imo:

1. DCAT expresses view on conformance of data with specifications, which follows DCMI's one (arguably vague but workable), and that PROF adheres to
2. In addition, PROF provides the means to represent relations between specifications, which can be used to handle case of conformance across different levels of profiles (and let's not be more specific than this: we don't need to, for this section, so let's keep a minimal editorial commitment and refer to other sections where more details are given, on what happens on conformance and isProfileOf).
   It shouldn't be the other way round, and not a way that minimizes the issue of conformance of instance data with specifications/standards, which is core to PROF too.

[aisaac]

@rob-metalinkage I'm perfectly fine moving this to another issue!

[nicholascar]

Closing after a period of due-for-closing and no further actions.

[kcoyle]

The suggested resolution was to open a new issue, which has not been done yet. I'm afraid that we'll forget it if this is closed. Could someone open that issue (may Rob or Antoine), and then we can close this with a pointer to that issue.

Also, what has been decided about aligning PROF to DCAT? I don't see a clear resolution here. I think that Antoine's comment above is the closest we have. If it was decided in a meeting then a link to the meeting minutes woud be the best way to document this.

[nicholascar]

As per the suggestion here https://github.com/w3c/dxwg/issues/808#issuecomment-529345225, a new issue has been created, #1108, titled "Improve description of relationship between DCAT and PROF".

Addressing @kcoyle's question:

what has been decided about aligning PROF to DCAT?

Exactly as per the referenced comment: "PROF call 29 august: we agree that this is not a crucial issue." & There is no formal requirement for it. and so now, with the handover issue created, this can be closed.