Removing the domain constraints on the AS mediaType property

[iherman]

Please Indicate One:

• [x] Editorial
• [ ] Question
• [ ] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

I write this issue in the name of the Verifiable Credentials Working Group. An issue was raised (https://github.com/w3c/vc-data-model/issues/1408) on the possible name clash between the Activity Streams' and the Verifiable Credentials' @context files concerning the term mediaType. There were a bunch of discussions; I do not want to get into the details, you can of course look at the issue, and also the discussion on our meeting earlier today.

Our final conclusions is that the simplest, and possibly the cleanest, solution would be for the Verifiable Credentials world to simply reuse the AS version of the mediaType term. We would be happy to do that, but there is a technical issue. At the moment, the AS version of the term has domain restrictions (Link and Object). These restrictions make it impossible to use the term outside the AS domain. Would it be possible to update the RDF vocabulary without these restrictions? If that was done, the VC WG would be happy to modify the @context file to refer to the AS property URL.

cc: @brentzundel @msporny @gobengo

[msporny]

Would it be possible to update the RDF vocabulary without these restrictions?

Yes, please, and +1 to this. The alternative would require us to use the schema.org "encodingFormat" term or invent our own. The only reason we can't use the AS term is due to the Domain... if the domain is fixed, we can use it in the VC v2.0 specifications and each of the Data Integrity specifications.

/cc @dmitrizagidulin

[nightpool]

The discussion thread brings up a really good point that I don't think I've seen anyone address yet:

The renaming of mediaType to encodingFormat in the VC context will not alone solve the ActivityStreams issue. That context also defines name as as:name, which conflicts with the VC definition as schema:name. Changing that is a more difficult problem.

The mediaType property is really supposed to be a very specific, functional property representing the mime type of the content string in an AS2 object. So it's not 100% clear to me that it's helpful to implementors to reuse the same property. I want to try and understand more about the name clashes here and why we need to solve them (something about @protected? What is that?) instead of everybody just being able to have their own vc:mediaType or as:mediaType URI for their own algorithms and go about their day.

[iherman]

The mediaType property is really supposed to be a very specific, functional property representing the mime type of the content string in an AS2 object. So it's not 100% clear to me that it's helpful to implementors to reuse the same property.

So, if I understand it well, the property refers to an (RDF) object of another triple, instead of the (RDF) subject? If that is indeed the case, then I agree this is a very AS specific usage pattern which does not apply to the VC case (see the example in the vcdm spec), and we will have to go our own way.

I want to try and understand more about the name clashes here and why we need to solve them (something about @protected? What is that?)

The specification of the property is here in the JSON-LD 1.1 specification. I prefer to leave the exact rationale in the VC case to @msporny or @dlongley.

[nightpool]

So, if I understand it well, the property refers to an (RDF) object of another triple, instead of the (RDF) subject? If that is indeed the case, then I agree this is a very AS specific usage pattern which does not apply to the VC case (see the example in the vcdm spec), and we will have to go our own way.

Ah, actually this example does match up pretty closely with the way mediaType is defined for Link objects:

When used on a Link, identifies the MIME media type of the referenced resource.

Here's an as2 example of that:

      "actor": {
        "type": "Person",
        "id": "http://www.test.example/martin",
        "name": "Martin Smith",
        "url": "http://example.org/martin",
        "image": {
          "type": "Link",
          "href": "http://example.org/martin/image",
          "mediaType": "image/jpeg",
          "width": 250,
          "height": 250
        }
      },

which is very similar to the credentialSubject -> image example. We still have a little bit of weirdness with indirect vs direct references (id vs href) but that seems fixable.

[iherman]

I am not sure where we should take it from here, as far as the AS community is concerned...

[gobengo]

Would it be possible to update the RDF vocabulary without these restrictions?

@iherman @msporny Exactly which RDF vocabulary do you mean?

What I mean is that activitystreams-core refers to a "normative JSON-LD context defintion" here curl -H "Accept: application/ld+json" https://www.w3.org/ns/activitystreams

Which doesn't seem to encode these domain restrictions. Is there some conflict in practice with the JSON-LD contexts that you think a change to the as2 json-ld context can fix, or do you mean some other document?

activitystreams-vocabulary refers to some non-normative turtle at https://www.w3.org/ns/activitystreams-owl

If you mean changing the text on https://www.w3.org/TR/activitystreams-vocabulary/#dfn-mediatype , that seems like it might be a meaningfully normative change to which W3C process around changing TRs would apply. I don't see a strong reason that those notions of 'domain' need to be interpreted as requirements/prohibitions vs recommendations/options (in the rfc2119 sense)

[iherman]

@gobengo what I mean is the relevant lines in the vocabulary definition; more precisely, considering this part:

as:mediaType a owl:DatatypeProperty ,
       owl:FunctionalProperty ;
  rdfs:label "mediaType"@en ;
  rdfs:comment "The MIME Media Type"@en ;
  rdfs:range xsd:string ;
  rdfs:domain [
    a owl:Class ;
    owl:unionOf (as:Link as:Object)
  ] .

And the question is whether the rdfs:domain statement can simply be removed. (Meaning that the term mediaType can be used on any resource.)

[nightpool]

the OWL file is non normative and is published by the community group for convenience only. In this case it's merely encoding the normative text of the specification, if you want to publish a different OWL file you're welcome to.

On Sun, Feb 25, 2024, 10:11 PM Ivan Herman @.***> wrote:

@gobengo https://github.com/gobengo what I mean is the relevant lines in the vocabulary definition https://www.w3.org/ns/activitystreams-owl; more precisely, considering this part:

as:mediaType a owl:DatatypeProperty , owl:FunctionalProperty ; rdfs:label @. ; rdfs:comment "The MIME Media @. ; rdfs:range xsd:string ; rdfs:domain [ a owl:Class ; owl:unionOf (as:Link as:Object) ] .

And the question is whether the rdfs:domain statement can simply be removed. (Meaning that the term mediaType can be used on any resource.)

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/584#issuecomment-1963285106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV7NBEYGNMPGVQ2DXE3YVQDPTAVCNFSM6AAAAABDTPBGRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGI4DKMJQGY . You are receiving this because you commented.Message ID: @.***>

[iherman]

@gobengo, @nightpool

I was not complete in my answer in https://github.com/w3c/activitystreams/issues/584#issuecomment-1963285106, my apologies for that. Unfortunately, https://www.w3.org/TR/activitystreams-vocabulary/#dfn-mediatype has to be changed, too, because that spec is merely "reflected" in the RDF vocabulary specification (ie, the OWL file). The change would "simply" remove the entry on "Domain". And, indeed, it would be a normative change, although it would not affect any of the current implementations (unless they make a strict check on the type of objects that the mediaType property applies to and would raise an error if it is not a AS object or an AS Link).

I do not know who maintains the Specification right now, ie, which group has, per charter, the possibility to change that.

[msporny]

@iherman wrote:

And the question is whether the rdfs:domain statement can simply be removed.

I'm going to be less tactful than @iherman ... :)

Please remove the rdfs:domain statement so the VCWG can just re-use the AS definition of mediaType. This is a non-normative, non-substantive change that won't affect current implementations.

If you don't make the change, the VCWG is going to be forced to either invent yet another (almost equivalent term), or use schema.org (which is a bit wonky).

The right thing to do here is to re-use what AS has as long as the rdfs:domain statement is revised in the way that @iherman noted.

The VCWG is in CR with the specs that use mediaType; time is not on our side, we need to lock this in before our specifications are finalized.

What's the fastest route to making that happen?

/cc @nightpool @dmitrizagidulin @gobengo @pchampin

[csarven]

This issue is part of a recurring topic. It requires a clarification on W3C policy for ns management. I have created an issue w3.org/ns/ development and management policy requesting feedback from W3C Team ( nudge @plehegar ).

FWIW, there is a W3C Document Adding to W3C RDF namespaces with a section on Modification and removal of terms - a "first draft policy". That document actually was part of the reasons where the Social WG needed to add and define the http://www.w3.org/ns/ldp#inbox property in the LDP ns (required by LDN and later AP's aliasing as:inbox in the AS2 JSON-LD context.) See the issues above for more details.

(The Solid CG has used the draft policy as guidance in its own processes.)

[evanp]

I think it's important that Activity Streams 2.0 interacts nicely with other vocabularies. However, our primary responsibility is to the Activity Streams 2.0 community and to ActivityPub implementers. I haven't seen any discussion of how this could be useful in that way.

As has been noted before, our vocabulary documentation is canonical, in which mediaType is indeed scoped to Link and Object -- like literally dozens of other properties. Why would we loosen the constraint of that single property, but not the others? Why loosen any of them?

Loosening the constraint would be a normative change. I think it would be a backwards-compatible one; loosening constraints usually is. The SocialCG currently maintains errata and an editor's draft for the AS2 vocabulary. This is not an erratum; the document describes the vocabulary as designed. We don't currently have a WG to make normative changes. We're still trying to figure out how to do that.

@iherman if you are in a hurry with this, I'd highly recommend biting the bullet and just using a different term. If you're willing to wait, we can add it to the list of topics to address in the next version of the AS2 specification. My current estimate would be on the order of months to a year.

[iherman]

In view of https://github.com/w3c/vc-data-model/issues/1408#issuecomment-1965744282 being closed (this was the issue that started it all), I would propose to consider this issue moot and close it, too.

cc @msporny and @brentzundel before doing so, as this issue was raised as a result of a WG resolution.

[msporny]

@evanp wrote:

@iherman if you are in a hurry with this, I'd highly recommend biting the bullet and just using a different term.

That is quite unfortunate. Looks like there won't be consensus in the AS community on this any time soon, nor the ability to effect change even if there was consensus.

@iherman let's take this back to the W3C VCWG and let them know that AS won't be able to make the change we need. Now the discussion becomes whether or not we're going to be completely incompatible w/ the AS context (highly likely since name is protected in the VC context as well). IOW, we can maybe "fix" this issue by defining ianaMediaType in the VCWG, but even if we do that name will collide (IIRC).

One thing is clear at this point, we can stop engaging w/ the AS community as they won't be able to effect a change that would resolve the issue. I think we just write AS compatability off as a loss at this point and hope for alignment in the next version of the AS vocabulary.

+1 to close this issue.

[iherman]

Closing per previous comments.

[evanp]

@iherman let's take this back to the W3C VCWG and let them know that AS won't be able to make the change we need. Now the discussion becomes whether or not we're going to be completely incompatible w/ the AS context (highly likely since name is protected in the VC context as well). IOW, we can maybe "fix" this issue by defining ianaMediaType in the VCWG, but even if we do that name will collide (IIRC).

@msporny It's surprising to me that VCWG made an envelope format that's so brittle that you can't include terms from other namespaces in the document.

Have you considered that this might be an architectural fault, and maybe you should take some time to correct it, instead of demanding that others make changes to their already-published vocabulary?

Activity Streams 2.0 is hardly the only vocabulary on the web, and if you're running into conflicts with our terms, my guess is you'll run into other conflicts in the future.

One thing is clear at this point, we can stop engaging w/ the AS community as they won't be able to effect a change that would resolve the issue. I think we just write AS compatability off as a loss at this point and hope for alignment in the next version of the AS vocabulary.

One thing you might try, as you engage with other communities, is making the case for why including terms from the vocabulary into a VC might be useful for their implementers. They may be more amenable to making changes on your accelerated timeframe!

Good luck with your work!

[iherman]

Just to be very precise. The problem is not really with the vocabulary, but its embodiment in JSON-LD via a specific @context file (the source of the conflict is the usage of @protected, which is not a generic RDF notion but, rather, specific to JSON-LD).

Apologies for being pedantic...

[silverpill]

@msporny @iherman How implementers could work around this conflict? I'm primarily interested in digestMultibase property, which might become part of the data-integrity context (per https://github.com/w3c/vc-data-integrity/issues/241), but I also know people who work on a project that brings Verifiable Credentials to ActivityPub and who need to include both contexts...

[evanp]

Just to be very precise. The problem is not really with the vocabulary, but its embodiment in JSON-LD via a specific @context file (the source of the conflict is the usage of @protected, which is not a generic RDF notion but, rather, specific to JSON-LD).

Understood! In AS2 we have some prohibitions on overriding the core terms, so I can see why this would be useful. I think it's probably a hard problem for the VCWG -- I don't envy you!

Apologies for being pedantic...

Not at all. You've been really helpful here; I appreciate your contributions.

Could I ask a question while I have your time? I think for including AS2 data into a VC, the only work that's needed is to use the "as" prefix on conflicting terms, like "as:mediaType" or "as:name". Am I missing anything? I understand the big issue is that it would be nice for VCWG to re-use the mediaType term from AS2. But I am confused as to why AS2 data won't work inside a VC.

[nightpool]

I think the issue is the other way around, that you can't produce a valid AS2 document that includes a Verifiable Credential, because the VC context @protected directive conflicts with the normative requirements of the AS2 specification

[iherman]

@silverpill,

I'm primarily interested in digestMultibase property, which might become part of the data-integrity context (per https://github.com/w3c/vc-data-integrity/issues/241)

This is a good example. As I said in https://github.com/w3c/activitystreams/issues/584#issuecomment-1966707736, the issue is not the vocabulary but the context. The definition of digestMultibase does not specify a domain, which means that it can be used on any RDF resource without any semantic consequences. If AS is interested on using it, no problem whatsoever. Our problem with using the media type of AS is the domain restriction.

The issue, as @nightpool says, is indeed the combination of the JSON-LD context files. I am not really an expert in the intricacies of the JSON-LD contexts to find a way of combining these, I would leave that to people who are the real experts. That being said, @evenp is right in saying:

I think for including AS2 data into a VC, the only work that's needed is to use the "as" prefix on conflicting terms, like "as:mediaType" or "as:name".

Indeed, actively using namespace prefixes would work without any problems, even in context files. From my, basically, RDF based background, the issue is that we are desperately trying to "hide" the namespace prefixes from our respective developers' communities (due to a fear of rejection because the term "namespaces" seems to be cursed), and we are paying the price for that. But I may not be the right person judging the reactions of that community.