Profiles listing [RPFL]

[jpullmann]

Profiles listing [RPFL]

Create a way to list the profiles implemented by a dataset or a specific distribution

Some subset of profile metadata that can be included in a DCAT context should have a canonical set of properties recommended. Initial requirements are 1) short definition 2) input and editing guidance. Links should be consistent with#RPFRP

Related requirements: Profile definition [RPFDF] Profile negotiation [RPFN] Profile representation [RPFRP] 
Related use cases: Profile support for input functions [ID46] 

[andrea-perego]

I wonder whether this requirement covers also the scenario where a catalogue record includes links to alternative representations, following different metadata schemas / profiles. For instance a DCAT metadata record can also have an ISO 19115 and/or DataCite representation.

[makxdekkers]

I wonder if this information is needed on a per-dataset basis or could be done on the level of the Catalog? ADMS has a property adms:supportedSchema for AssetRepository (subclass of dcat:Catalog): "A schema according to which the Asset Repository can provide data about its content, e.g. ADMS".

[nicholascar]

I have put up a proposal at https://github.com/w3c/dxwg/tree/profiledesc-working/profiledesc/profileneg

[nicholascar]

The proposal above indicates how we have addressed the requirement to list profiles available for a resource but we did it in a non-standardised way and only with a Query String Argument convention. The work done by @larsgsvensson and @RubenVerborgh to introduce an Accept-Profile and Profile HTTP header would seem to bring the functionality we sought in our implementation to the HTTP level.

The major difference between our previous work and the profileneg proposal as I read it in http://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema is that there seems to be no way for a client to find out profile information other than identity of the identifier of the profiles a server can supply is non-dereferenceable. This is one of the motivating factors for a profile description ontology and resolvable profile URIs.

[azaroth42]

Who is the intended audience for the profiles list? I see two different answers, with different rationales, that seem somewhat conflated together in the issue (and supporting use cases and discussion)

a) Machines -- in order to request an appropriate profile, the client software needs to be able to discover, retrieve and interpret a list of identifiers for the available profiles, in order to use the chosen identifier to request the correct representation. This seems essential, given that there isn't a central registry of profiles like there are for languages, media types and so forth. In the same way as a 300 HTTP response, a list of options seems necessary.

b) Humans -- A short definition and editing guidance seem appropriate for humans, but almost certainly irrelevant to machines. Yet these are mentioned explicitly in the issue.

Some unpacking of the issue might help?

[nicholascar]

Both. I think it entirely reasonable (and it's been accepted as in scope) to have Guidelines that indicate machine-readability of profile listing and other info but that also have mechanisms that profile for human-friendly versions of such tasks. The human versions would necessarily not break with the machine versions.

We just can't expect people to use and understand profiling if we only provide HTTP mechanisms! Who can set HTTP headers manually and inspect results? Not most people I work with. And yet in order for profiling guidelines to be understood and adopted, we need people to be able to do this. If we let them, we then want to make sure they do it in ways compatible with the HTTP mechanics.

[rob-metalinkage]

UCR has been updated since - this requirement is handled by conneg-by-ap - should this issue be closed.

[kcoyle]

If "handled by" means it's in the draft already then I agree about closing.