media type of canonicalized application/n-quads

[gobengo]

I have a blob of canonicalized application/n-quads, and I want to describe the media type of that blob.

I can use application/n-quads, and I'm also curious if there is an appropriate way to also indicate that the canonicalized part. I thought maybe I'd add a profile parameter (and see @gkellogg ideate similarly), but I'm note sute what the value should be.

application/n-quads; profile=https://www.w3.org/TR/rdf-canon/

Is there a better way, or a reason I shouldn't do this?

[gkellogg]

We specifically avoided describing an API for the canonicalization algorithm or a media type for canonicalized N-Quads. The media type is defined in RDF 1.1 N-Quads.

The question comes to how would such a profile parameter be used: If used in an Accept header would a service be expected to perform RDC canonicalization? Or, in a reply if the result was canonicalized? RDC determined to not define an API or any expectations on what the media type should be, other than application/n-quads. Typically, RDC would be used within other specifications and may not ever be returned as such, but used to derive a hash value.

[gobengo]

@gkellogg I would like to be able to send in an Accept header a weighted preference so I can be like "I'll take noncanonicalized application/n-quads if its all you got, but I'd prefer the rdf-canon one" (e.g. if response Content-Type indicated I got my preference, I can use that to e.g. show a progress bar, but if the response content-type does not indicate canon, I shouldnt try to show a progress bar because it will be wrong).

Just sharing the use case in case you have any suggestions.

Thanks for explaining the rationale for avoiding profile= in the media type.

[gobengo]

If used in an Accept header would a service be expected to perform RDC canonicalization?

yes, sort of. The server could always ignore the preference and respond with application/n-quads or whatever it wants, and the client would have the info it needs to understand that that is different than the preferred/canonicalized media type (and either deal with it or throw). Right now without a distinct media type or URI that identifies the media type of the canonicalized form, it is hard to indicate that subset of the broader class of application/n-quads

[gobengo]

Until there is a better option, I will use the following URI to refer to the 'type' of rdf-canon canonicalized application/n-quads (if I need to distinguish it from non-canon)

ni:///sha-256;-FvtXcSdJkOPSJ1WxEOjFl5ljWk6oMwfQ2h6RhTLrxo?ct=application%2Fn-quads

bengo@bengo ~ ⚡  mediaType='{ "@type": "https://www.w3.org/ns/activitystreams#Link", "https://www.w3.org/ns/activitystreams#mediaType": "application/n-quads", "https://w3c-ccg.github.io/#canonicalizationAlgorithm": "https://www.w3.org/TR/rdf-canon/" }'
bengo@bengo ~ ⚡  echo "$mediaType" | jq .
{
  "@type": "https://www.w3.org/ns/activitystreams#Link",
  "https://www.w3.org/ns/activitystreams#mediaType": "application/n-quads",
  "https://w3c-ccg.github.io/#canonicalizationAlgorithm": "https://www.w3.org/TR/rdf-canon/"
}
bengo@bengo ~ ⚡  echo "$mediaType" | iprd ni
ni:///sha-256;-FvtXcSdJkOPSJ1WxEOjFl5ljWk6oMwfQ2h6RhTLrxo?ct=application%2Fn-quads
bengo@bengo ~ ⚡  echo "$mediaType" | iprd cid
bagb6qaqsed4fx3k5ysosmq4pjcovnrcdumlf4zmnne5kbta7inuhurquzoxru
bengo@bengo ~ ⚡  echo "$mediaType" | iprd car
wrote car to
bagb6qaqsear5z6avpika5ubpqra3rfa5wxnml5hv5fuv2evrjykyspbjacf7a.car
bengo@bengo ~ ⚡  w3 up --car bagb6qaqsear5z6avpika5ubpqra3rfa5wxnml5hv5fuv2evrjykyspbjacf7a.car
  1 file 0.4KB
⁂ Stored 1 file
⁂ https://w3s.link/ipfs/bagb6qaqsed4fx3k5ysosmq4pjcovnrcdumlf4zmnne5kbta7inuhurquzoxru

[TallTed]

@gkellogg -- I wonder why not simply register application/canon+n-quads in addition to application/n-quads? I see no requirement here that a service do something extra to deliver the canonicalized form, but it makes it easy to request that with whatever weight relative to the un-canonicalized form...

[gkellogg]

Perhaps we should take it up next time we meet

[gkellogg]

Reopening for further group discussion.

[philarcher]

As recorded in the minutes of the meeting on 2024-02-28

We thank Ben for the comment but feel that C14N would always be re-executed before trusting that the data was canonicalized and don't see the value in adding a new media type, especially this late in the standardization process. Also, no scope for extensions in the existing n-quad media type registration