Re: [dxwg] Clarify need for unambiguous profile URIs when compound specifications referenced. (#1017)

From @tombaker 2019-08-23 :

Dear Lars,

On Mon, Aug 05, 2019 at 09:49:13AM +0200, Lars Svensson wrote:
> In order to be able to use profiles specified as
> parts/sections of larger documents, those
> profiles/sections need their own URIs.

On Wed, Aug 07, Lars wrote [1]:
> If a profile is part of a larger document that contains
> several profile specifications, each of those profile
> specifications needs it's own URI (which would probably
> be a URI fragment). _Iff_ the larger document only
> contains one profile specification, it MIGHT be
> possible to use the document URI as a proxy for the
> profile URI for conneg purposes, but that feels a bit
> streched.

I'm having trouble reconciling what look to me like three
quite different messages about the role of URIs in

1. The notion that "From a conneg point of view, the
   profile URI can point to anything (including nothing,
   i.e. the profile URI can return 404)". [2]

2. The first position above: that from a conneg point of
   view, a profile that is part of a larger document
   MUST have its own URI.

3. The second (and more radical) position above:
   that a document URI is not good enough for conneg if
   the document "contains several profile specifications".

FWIW, I strongly agree with #1. For starters, profile
URIs _will_ increasingly return 404s over time.  And
service interruptions on servers that provide profile
documents should surely not prevent users from leveraging
a URI to get data.

Requiring that document fragments have their own URIs
raises many questions.  A "hash URI", for example, may
have a conceptual meaning (e.g., "the definitions of
terms used in this document"), but it also may function
as an anchor for positioning the browser window at the
start of a section.  What a hash URI does not do, as far
as I know, is define the _end_ of a document fragment.
In other words, a hash URI provides no basis for actually
extracting a fragment from a larger document.  In the
case of PDF documents, the hash URI would not even serve
as an anchor.

WRT #3, I see a tension between the very generalized view
of profiles as being pretty much anything that builds on
something else -- e.g., the vocabulary DCMI Metadata
Terms as a "profile" of RDF -- and the functional role of
URIs in conneg.  From a conneg point of view, as I
understand it (see #1), the URIs used in content
negotiation might typically be profiles, but they are in
fact not even required to be profiles at all.

Of the three approaches, the first is the most realistic
and workable.  This approach can be presented with plenty
of SHOULDs (e.g., SHOULD resolve to a resource with a
profile description), as done in the IETF document.

Approaches #2 and #3 hope that implementers will grasp
the notion that a profile document (i.e., what most
people think of as profiles, such as DCAT in its various
manifestations) might actually consist of distinct
"profiles" (or "profile specifications"); that they will
come to a reasonably coherent collective understanding of
the nature and granularity of such embedded
specifications; and that they will go through the trouble
of coining URIs for those embedded specifications.

If I have understood it correctly, this approach seems
both quite new and somewhat out of line with how people
currently think of profiles (i.e., as documents).  Maybe
we should be moving in this direction -- I'm sceptical,
to be honest -- but it would need to be implemented and
tested, and we would IMO need to see evidence that people
actually want to do things this way.

In short: the idea that a profile URI can point to
anything (or nothing) is IMO exactly right [4].
Introducing, at this point in the process, new, complex,
and untested notions about separately identified parts of
documents IMO muddies the waters and should therefore be
out of scope for CONNEG -- or perhaps reserved for a
future revision, by which time one might be able to point
to a significant body of implementation experience.



GitHub Notification of comment by nicholascar
Please view or discuss this issue at using your GitHub account

Received on Thursday, 29 August 2019 12:21:44 UTC