Question on IETF definition of Profile

[aisaac]

This is especially for @RubenVerborgh but I'm eager to hear from others.
In w3c/dxwg#963
the new proposed definition for IETF profiles is:

a profile is a description of structural and/or semantic constraints documents can conform to in addition to the syntactical interpretation provided by more generic MIME types.

And now as per this commit it is

a profile is a description of structural and/or semantic constraints documents can conform to structural and/or semantic constraints on representations of documents in addition to the syntactical interpretation provided by more generic MIME types.

@smrgeoinfo suggested that

this IETF definition is that it defines 'profile' to only apply to profiles of MIME types-- certainly a narrower scope that our discussions here.

@RubenVerborgh refuted that, and I note that indeed the last bit of the definition seeks to clarify that profiles are not MIME type focused.

However I am really struggling with the first part of the definition, which mentions "representations of documents" and "structural constraints". Does this part include or exclude the JSON-LD profiles that are different from our profiles, as we're trying to establish here? Can you give examples of "structural contraints that wouldn't be semantic constraints nor syntactical constraint? Maybe a reference to a definition for "structural" would help here.

[RubenVerborgh]

@smrgeoinfo suggested that

this IETF definition is that it defines 'profile' to only apply to profiles of MIME types-- certainly a narrower scope that our discussions here.

@RubenVerborgh refuted that

Indeed. The definition says that profiles provide constraints in addition to those provided by more generic MIME types. For example, there could be a profile saying "use FOAF to represent people" and that profile could apply to text/turtle, application/ld+json, etc. Furthermore, there is nothing that says that profiles could not work together, and thus constrain each other. So there is a flexible relationship between profiles and MIME types; this definition just separates one from the other (which is not the case of some of the other proposed profile definitions).

Does this part include or exclude the JSON-LD profiles that are different from our profiles

An IETF profile can be a JSON-LD profile; we don't see any reason to restrict it.
But the DXWG definition can be stricter than the IETF definition, so not a problem.

(I do have a problem with the exclusion of JSON-LD profiles, to the point I will be making below.)

Can you give examples of "structural contraints that wouldn't be semantic constraints nor syntactical constraint?

Also see earlier thinking on https://ruben.verborgh.org/articles/fine-grained-content-negotiation/#where-mime-types-fall-short

The difference between structure and syntax is not black and white, but where I draw the line is "would I need a different parser?". For instance, a JSON document for which specific keys are required, would likely still be parsed with a JSON parser, not with a custom one. Hence, I see JSON as a MIME type, and the requirement of specific keys as a profile.

• Structure examples:
  • arrays can only contain numbers
  • objects can be nested up to 2 levels deep
  • only certain keys are allowed in certain places
• Semantic examples:
  • the value under the key "prev" has the interpretation of a back link
  • the value under the key "pages" indicates the total number of pages

Maybe a reference to a definition for "structural" would help here.

Constraints about what constitutes a valid (not "meaningful") document that are not covered by the parser corresponding to the MIME type.

[agreiner]

It feels odd to specify that I want a MIME type more than a profile when I want a profile with a certain MIME type. It's a bit like being asked whether I want an orange or to have it delivered on Tuesday.

[RubenVerborgh]

It's a bit like being asked whether I want an orange or to have it delivered on Tuesday.

That is exactly the current limitation of MIME types. You can only say "orange on Tuesday", not "apple or orange" and "Tuesday or Wednesday".

Hence, for backward compatibility, we include "orange on Tuesday", but now can also add "or orange" and "Tuesday or Wednesday".

[agreiner]

So if I want an orange on Tuesday, I have to state that I want an orange and then I have to state that I want an orange and I want it on tuesday, but I want the orange more than I want it on Tuesday. By conflating the two types of profile, you require extra ranking among what should be orthogonal desires. I suppose that ship has already sailed, but it just doesn't bode well for uptake, IMHO.

[RubenVerborgh]

I have to state

Not really, that's just the full version for backward compatibility.

orthogonal desires

They are. By all means, drop the backward compatibility; it was a shortcoming of past solutions that they were not orthogonal.

[larsgsvensson]

@aisaac Has your original questions been satisfactorily answered? There is much discussion but I haven't seen a resolution...

[nicholascar]

@aisaac can you respond about this Issue's status?

[larsgsvensson]

@aisaac this issue is now "due for closing". Last chance to say that you're not satisfied!

[aisaac]

@larsgsvensson I would gladly tell that I am satisfied, but I suppose a bit of due diligence is in order: can you point here to the latest definitions of profiles in the IETF draft and the Conneg spec(s) that have one, please? The links above don't work anymore, and I'm not sure I have the right pointers myself.

[larsgsvensson]

The definition of "profile" in the latest IETF draft (not yet submitted to IETF) is:

a description of structural and/or semantic constraints on representations of resources that apply in addition to the constraints inherently indicated by their MIME type: (I-D §1.1 Terminology)

In the current ED from DXWG-CNEG, the definition is:

A specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications.
If the specification profiled is a specialized type of specification, for example a data or a functional specification, the profile will be of the same sort - a data or functional profile.
This Content Negotiation by Profile specification concerns negotiation for data profiles, and specifies functional profiles for different ways of achieving this. In this document, most occurrences of the term "profile" refer to "data profile". (Content Negotiation by Profile §3 Definitions.)