Profiles have URI identifiers that resolve to more detailed descriptions (6.1)

[kcoyle]

75

[andrea-perego]

If the distinction I made at http://lists.w3.org/Archives/Public/public-dxwg-wg/2018May/0144.html between "profile description" and "profile definition(s)" makes sense, I would say that the URI should return the "profile description" (i.e., profile metadata, possibly in different formats - e.g., RDF & HTML), which includes links to the available profile definitions.

[kcoyle]

Andrea, although this has its own logic, this does not meet the use case provided for content negotiation. I think we need to hear from Ruben and Lars on this as it would seem to require an additional interaction beyond http. See https://w3c.github.io/dxwg/ucr/#ID2

[andrea-perego]

Thanks, @kcoyle . So looking at the relevant UC, I guess that "the more detailed descriptions" are specifically referring to the HTTP response headers telling which are the available profiles and, for each of them, which formats are available.

The two things are not mutually exclusive: the URI can return both such HTTP headers and the profile metadata. And actually this is approach used in the GeoDCAT-AP API - quoting:

Besides the resulting RDF serialisation of the source ISO 19139 records, the API returns a set of HTTP Link headers, and the corresponding HTML LINK elements in the HTML+RDFa serialisation.

Relation type	Type	Title	Target URI
derivedfrom	application/xml	ISO 19139	The URL of the source document, containing the ISO 19139 records.
profile	The media type of the document returned by the API.	DCAT-AP	core
		GeoDCAT-AP	extended
self	The media type of the document returned by the API.	The name of the returned RDF serialisation.	The URL of the document returned by the API.
alternate	The media types of the alternative RDF serialisations supported by the API.	The name of the relevant RDF serialisation.	The URL of the document, encoded with the relevant RDF serialisation, as would be returned by the API.

[kcoyle]

Thanks, Andrea. This is very helpful. Now I hope that Lars & Ruben weigh in as to whether this fits with their concept of the requirements on servers in response to the headers they envision.

[larsgsvensson]

Only speaking for myself here (and hoping that @RubenVerborgh weighs in if he has a different view on this), the use of Link headers (and html link elements) to point clients to other representations definitely fits with the concept. My preferred solution would be a profile relation type (i. e. not rel="profile"but profile="https://example.org/profiles/1") just as @andrea-perego lists in his example (although I guess that there's a copy-and-paste error and that the profile is not about the media type...). So I think we're on the same page here.

[RubenVerborgh]

+1

[larsgsvensson]

Great, then we're on the same page

[aisaac]

I have an additional question: I agree that for a basic request for an 'holistic' data container like RDF, the URI of the profile should return to the 'hub' description in profileDesc. But what if the request is for XML? And could it be that for a request for RDF, asking for a 'SHACL' profile (ouch, metaprofiling ahead!!!) then what would get returned would be an XML Schema, or a SHACL file?

[RubenVerborgh]

(ouch, metaprofiling ahead!!!)

You said that like it's a bad thing :-) It's perfect that we can reuse the same mechanism on profiles too.

[andrea-perego]

I agree with @RubenVerborgh . A profile is just another resource, and shouldn't be treated differently.

I'm probably missing some background discussion, but I'm not clear whether the current agreement is that a profile URI MUST or instead SHOULD be dereferenceable. I would be in favour of SHOULD, and to use MUST only for requiring a profile to have a URI (irrespective of whether it is dereferenceable or not).

[kcoyle]

+1 Lars, Ruben, Andrea. In terms of "SHOULD be dereferenceable", another way is to couch it in terms of functionality: if you want to do X then the profile MUST be dereferenceable; if it isn't dereferenceable, then you cannot do X. People should be able to choose what services and what functions they want to support, and to understand what they need to provide to get the services they desire.

[andrea-perego]

@kcoyle said:

+1 Lars, Ruben, Andrea. In terms of "SHOULD be dereferenceable", another way is to couch it in terms of functionality: if you want to do X then the profile MUST be dereferenceable; if it isn't dereferenceable, then you cannot do X. People should be able to choose what services and what functions they want to support, and to understand what they need to provide to get the services they desire.

+10! (factorial :)

[aisaac]

ok it seems we do have an agreement here!

Now should this requirement be added to the ones on our requirement working space at https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg ? Or perhaps we need to attach it to a use case before. I'm not yet sure we have one, though.

[kcoyle]

I'm not sure we've resolved this one completely. We have a requirement that profiles have identifiers, but the discussion here seems to be about what those identifiers resolve to. Can someone identify the relevant use case and find or create a requirement that fits this discussion? Thanks!

[rob-metalinkage]

This issue is addressed by the use of URIs in conneg-by-ap and the provision of the profiles vocabulary and accepted requirements in the prof-guidance doc.

[kcoyle]

Does this mean that we do not need to address this in profile guidance?

I ask because it seems that this fits in to describing profiles as being sets of resources, and it would be necessary for the members of those sets to be available/linked from the profile identifier. Without this I don't know how we will have a platform to talk about the profile vocabulary, as this would be the motivation to include that in the guidance document.