reconsider `@id` for `mediaType` term

[gobengo]

Context:

• I'm trying to put W3C ActivityStreams2 inside the credentialSubject of a VC.
  • See this related issue I filed on JSON-LD, just to make sure I'm not missing some affordance that could be useful. advice on what to do when encountering @protected terms (vcdm/as2) json-ld-syntax#424
• the as2 mediaType term conflicts with the @protected vcdm2 mediaType term
• I think this means that I cant have valid AS2 (which requires a certain jsonld compaction) inside of a VC. I can only re-compact the as2 mediaType property to something else like as:mediaType.

Questions

• Is anyone super attached to defining mediaType in terms of https://schema.org/encodingFormat?
• Could we entertain the notion of defining it by re-using as2 mediaType?

Straw Man

• main...gobengo:vc-data-model:patch-1

[gobengo]

Looks like this was added in this PR #1296 by @iherman. wdyt @iherman ?

[iherman]

Just to make it clear for other reviewers in the WG:

we are talking about making a choice, in the VCDM vocabulary, between two externally defined terms for our internal use, namely:

1. The schema.org term encodingFormat; or
2. The activity streams' term mediaType

Our usage of the term is defined in the VCDM spec that uses the term mediaType, mapped (via the @context mechanism) to the schema.org term. In other words, so far our choice was (1) above. The usage of the term within the VCDM is related to the integrity control of related resources.

Back to the original question of @gobengo: we made a decision in the past of relying on externally defined terms whenever possible, hence our usage of several schema.org terms in our data model (instead of redefining them locally). Technically, we could decide not to use a schema.org term but, instead, map the value to the activity stream version (i.e., switch to choice (2) above); that would affect the VCDM only superficially. Also, taking into account the fact that this term has been introduced into the model relatively recently, I do not think it has any backward compatibility issue with deployed applications. On the other hand, doing so would bring some inconsistency in the vocabulary; that is why, taking into account the widespread usage and importance of schema.org, I am a little bit reluctant to do the switch. But the choice is not mine, but the WG's; if the WG decides to switch, I am happy to accept.

However. Making one step backward here for a moment: I wonder whether this may not be a more general issue that we may want to look at first. The use case of @gobengo is interesting in general: combining a well established Linked Data vocabulary with the VCDM. The fact of having a clash with the term names is bound to happen again. While the case of mediaType is relatively easy to solve (it is only a matter of a small change in the @context file, as shown in the straw man proposal), this may not be true for other cases which directly clash with the core vocabulary. I am curious to see whether experts would give an answer to w3c/json-ld-syntax#424 but, if there is no easy solution, I wonder whether the systematic usage of @protected will not become a general problem in the future. Maybe we will be forced to consider some alternatives. But I would leave this discussion to those who are much more versed in the intricacies of @context mappings, like @dlongley, @BigBlueHat, @pchampin, or @gkellogg…

[dlongley]

@iherman,

I provided an answer at the original issue.

My view regarding "wider questions" is: the fact that some contexts that predate the usage of @protected exist and are often used with unauthenticated data should not drive best security practices for authenticated linked data. Rather, new contexts should be created that follow best practices (e.g., use @protected and scoped contexts) -- especially if the data is intended to be secured (e.g., using VCs) and used by "type-specific" consumers that require particular contexts and JSON structure.

[dlongley]

Note: If we feel strongly about avoiding conflicts in particular with the mediaType definition we provide in the VC v2 context, we could type-scope it and require a type of ExternalResource (or similar) to bring mediaType into scope. This, IMO, is the right way to avoid conflicts -- if we feel that this one in particular is something we should be avoiding.

[iherman]

Thanks, @dlongley. If your solutions work and are acceptable to @gobengo, then we can indeed close this current issue.

Two remarks, however:

[…] new contexts should be created that follow best practices (e.g., use @Protected and scoped contexts) -- especially if the data is intended to be secured (e.g., using VCs) and used by "type-specific" consumers that require particular contexts and JSON structure.

We have to acknowledge that this is non-trivial for designers, and it requires a more elaborate knowledge of how @context works. I wonder whether we will have some place where these implementation advices could be documented. I think it would be important to do so. (cc this to @brentzundel to possibly come back to this issue during CR phase. Should we open a separate issue with this?)

If we feel strongly about avoiding conflicts in particular with the mediaType definition we provide in the VC v2 context, we could type-scope it and require a type of ExternalResource (or similar) to bring mediaType into scope.

I am not sure how this would be possible. We deliberately chose to keep the domain of digestSRI open (and mediaType is the "adjacent" term). If we went down the line you propose, it may become difficult to properly use constructions like Example 27: I presume it would require to do something with the image property in the @context file. But, I presume, that is an application-specific term...

(But, again, you may have some extra @context trick up in your sleeve…😀)

[msporny]

@dlongley wrote:

I provided an answer at the original issue.

Here's the link to the answer: w3c/json-ld-syntax#424 (comment)

Is anyone super attached to defining mediaType in terms of https://schema.org/encodingFormat?

As Ivan noted, the use of mediaType is "new" so changing it at this point wouldn't be a big deal, but changing it for the reasons proposed above might be a bad idea.

Could we entertain the notion of defining it by re-using as2 mediaType?

The question in the group will become: "Why is Activity Streams, which has far less usage than schema.org, defining mediaType? Why isn't Activity Streams just re-using schema.org encodingFormat, instead?"

Another option could be that the AS3 (the next version of the context) would change/update to use schema.org.

I don't have a strong opinion one way or the other on this issue, but I am hesitant to change things w/o more implementer feedback. How many implementers are planning on using VCDM v2.0 w/ AS2. If this is an experiment at this point, with no production-track implementations doing the above, then it's going to be a hard sell to the WG.

We are attempting to go into CR this coming week with VCDM v2.0, so any kind of "hail mary" type change at this point would probably be frowned upon. I will note that we can change the context file during CR (we explicitly mention that we might do that in the spec).

So, the options open to us in "least disruptive" to "most disruptive order are:

1. AS2 doesn't work w/ VC2, we need a new AS3 context for that to work, which will start using schema.org's encodingType.
2. AS2 works w/ VC2 because we update the VC2 context to use AS2's mediaType URL.
3. AS2 works w/ VC2 because VC2 and AS2 aggressively scopes the mediaType property in the AS2 context.
4. We rename VC2 mediaType to encodingFormat.

I'm marking this as post-CR since we can "fix" this in CR and will need more time to discuss on the proper path forward here given that we're trying to transition VCDM v2 into CR this coming week.

[gobengo]

@msporny sounds right. options 3 or 4 would be ideal. Moreso even than option 2 which is what my original post suggests only because I didn't think of options 3 or 4.

[iherman]

I presume that the easiest solution for all of us is option (4), unless AS2 does that change for the mediaType property. I would be fine with it (it may reduce future clashes, because the term "media type" may be more widespread).

I am happy to come up with a PR if we have a general agreement. Do we?

[msporny]

I presume that the easiest solution for all of us is option (4), unless AS2 does that change for the mediaType property. I would be fine with it (it may reduce future clashes, because the term "media type" may be more widespread).

Unfortunately, I don't think any of the options are "easy". The problem is that both AS2 and schema.org have claimed two different ways of expressing media type and now VC2 is in the unenviable position of having to choose one or the other, or do something weird (like start using the "encodingFormat" term, which is not readily used in the industry).

In VC2, we really do mean media type w/ our property... so I don't think renaming it to "encodingFormat" is the right way to go.

I am happy to come up with a PR if we have a general agreement. Do we?

No, unfortunately, I don't think we do. I think we need to be very careful about what we do here, none of the options are as straightforward as they seem. Yes, some of them are "easy" in that they don't require us to think too hard about the repercussions, but there will be repercussions.

I think the next step is to list "Pros" and "Cons" for each approach so we can do a full analysis w/ the VCWG engaged. Let's not do something hasty here as mediaType is fairly critical to a variety of VC2 use cases.

[iherman]

I presume that the easiest solution for all of us is option (4), unless AS2 does that change for the mediaType property. I would be fine with it (it may reduce future clashes, because the term "media type" may be more widespread).

Unfortunately, I don't think any of the options are "easy". The problem is that both AS2 and schema.org have claimed two different ways of expressing media type and now VC2 is in the unenviable position of having to choose one or the other, or do something weird (like start using the "encodingFormat" term, which is not readily used in the industry).

Just for the sake of arguments: for some reason (maybe being faced with a similar dilemma), the schema.org vocabulary creators decided to use the encodingFormat term, and industry survived by using this. After all, what our @context file does is to map the term mediaType to schema's encodingFormat, i.e., your option (4) in #1408 (comment) is simply to say that we fully embrace the usage pattern of schema.org instead of hiding it (which is what we do now).

I do agree that this is a VCWG's choice, though. A PR can come before doing that (to facilitate the decision) or after it.

[TallTed]

schema.org has redefined a great many things, or at least ignored common use and understanding, without much if any apparent concern for any repercussions. Something about being backed by multiple 800lb Gorilla organizations seems to encourage this.

Several IANA media types may be encoded in multiple ways. For instance, text/plain; charset=UTF-8 is a UTF-8 encoding of the text/plain media type. As you might guess, there is also text/plain; charset=UTF-32, among others.

schema:encodingFormat, formerly schema:fileFormat, lacks any strong assurance that it's not going to change again, and while its description cites IANA and MDN, it largely ignores the information found there (and the second cite itself ignores many aspects of the authoritative content of the first).

Maybe we might consider ianaMediaType and not map it to anything in AS2, AS3, schema.org, or elsewhere....

[iherman]

The issue was discussed in a meeting on 2024-02-14

• no resolutions were taken

View the transcript

2.6. reconsider @id for mediaType term (issue vc-data-model#1408)

See github issue vc-data-model#1408.

Brent Zundel: reconsider @id for mediaType term. looks like this was addressed?

Ivan Herman: my impression is that this was solved, we can close it. we are sticking here to what schema.org does.

Brent Zundel: proposal to close with no action?

Manu Sporny: currently there is a conflict b/w activity streams and verifiable credentials. activity pub wants to use VCs. they will be blocked/have a bad experience with things as-is. we have the easiest ability to change this. shouldn't just close. we should do something about it.
… easiest for us to rename the term from mediatype to ianamediatype or similar. then a question of whether we should re-use the schema.org term for it.
… or create our own. then it gets complex.

Ivan Herman: don't want to get into the weeds of defining/creating types. we can change the term we use to map to schema.org, but would leave this to schema.org, they are already doing this. we can use whichever term we want in our vocab.

Manu Sporny: let's rename our term to 'IANAMediaType' and keep the schema.org URL the same.
… we should do this and then be done, and we will be fine.

Ivan Herman: change to be made is in the spec text and context file, right?

Manu Sporny: yes.

Ivan Herman: never touched this but should be able to do it.

Dave Longley: do we want to use encoding format as the term? since we're using it as the schema.org property? avoid inventing a new term.

Manu Sporny: I'm fine w/ "encodingFormat".

Ivan Herman: perfectly fine.

Brent Zundel: any opposition?

Manu Sporny: Only argument against would be: "People don't call these things "encoding format" usually? They say media type?

Dave Longley: they also don't say "ianaMediaType".

Manu Sporny: true story.

Brent Zundel: none heard. Ivan is assigned. that is our meeting for today.
… please jump on PRs that need feedback in vc-jose-cose and others. if you are assigned in the data model please get a PR in for that.

Manu Sporny: "iana" -> "I Am Not A" Media Type.

Brent Zundel: getting to the point where we could mark things as 'future' ... people will need to be assigned to address them.
… thank you everyone, we could not do this without you. see you next week.

---