Allowing expanded type values in conforming documents

[OR13]

@TallTed wrote here: w3c/vc-jose-cose#76 (comment)

type is RDF Class, this question seems more about the core data model.

Given that `type` is RDF Class, its value MUST be a URI, not a literal.

examples/vc-2.0/vc-ld-jwt.jose no longer resolves to a file, so I cannot check its actual content, and say what it should decode to contain, but that certainly is not —

  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],

That should be something more like this, with fully qualified URIs —

  "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": [
    "http://example.com/ontology/VerifiableCredential",
    "http://example.com/ontology/UniversityDegreeCredential"
  ],

... edit from @OR13 below ...

While I think the left hand side is expected to be type based on the compact form requirement... I don't know if you are allowed to use the right hand side values as expanded when compact form is used.

This would seem useful to "none JSON-LD processors" who want to distinguish:

Cases like this:

  "type": [
    "https://www.w3.org/2018/credentials#VerifiableCredential",
    "https://vendor1.example/ontology/UniversityDegreeCredential",
    "https://vendor2.example/ontology/UniversityDegreeCredential",
  ],

[iherman]

The issue was discussed in a meeting on 2023-07-26

• no resolutions were taken

View the transcript

2.2. Allowing expanded type values in conforming documents (issue vc-data-model#1206)

See github issue vc-data-model#1206.

Manu Sporny: It's fine to use full URIs in normal JSON-LD documents, however if publishing in JSON-only mode implementors would have to add support for both shortened and full URIs.

Ted Thibodeau Jr.: This reminds me of a discussion about MIME types for VCs, and that to be able to use the JSON media type for JSON-LD documents the URI has to be expanded.

Ivan Herman: There is nothing specific to the 'type' property here. It would apply to any JSON-LD property.

Manu Sporny: Yes, agree with Ivan, which is not a good developer experience, which is why we don't do/require that today.

Sebastian Crane: Plain JSON processing is not about avoiding implementing something w/ JSON-LD... it's more important to view the case where you don't have an active internet connection, you need to be stuff w/o active connection to Internet.

Joe Andrieu: In production systems, you don't want to retrieve context values... you want to understand which context which software your software has been written to... and write to that.

Sebastian Crane: From ease of use, you don't want to require active internet connection to pass something. For example, ticket machine loses WiFi and then you can't get through... this needs to work w/o fetching stuff from the Web.

[iherman]

The issue was discussed in a meeting on 2023-08-16

• no resolutions were taken

View the transcript

2.2. Allowing expanded type values in conforming documents (issue vc-data-model#1206)

See github issue vc-data-model#1206.

Kristina Yasuda: we discussed 3 weeks ago, there didn't seem to be agreement to add this to VCDM.

Orie Steele: Our current language says document has to be compact, don't know if you can use URL in compact JSON document, I expect people have done that in v1 of spec, expect them to keep doing that.
… We should expect to see people mix compact type w/ expanded tpes, or just put URLs in there... that can create logical/validation issues... if you process as JSON-LD and RDF and doesn't expect to not have them, libraries can explode.
… This is in the category of not addressing this particular piece, make it clear to implementers that it's not ok to do, might see this in the wild, we should providde some guidance.

Orie Steele: A JSON processor has not problem with arrays of strings.

Manu Sporny: The problem isn't with JSON-LD processing, a JSON-LD processor will be fine. Doing vanilla JSON processing will have to look out for the long and short forms. The reason we made the rule is so that vanilla JSON processors could just use the shortened form.

Orie Steele: JSON Processors don't understand "compact form"... thats a JSON-LD concept.

Manu Sporny: If the JSON processors put that logic in -- that would work just fine. I agree we should put in guidance to say "don't do that, if there's a shortened form, use that, not the full URL".

Sebastian Crane: JSON processors don't understand �anything� - semantic meaning is always added by the scheme, like an OWL document in the case of JSON-LD.

Brent Zundel: who is willing to be assigned?

Manu Sporny: As Orie said, there are some ecosystems might expect that. If we didn't use JSON-LD (only vanilla JSON) people would still need to pay attention to it. So some guidance that says you might experience it in the wild, and the ecosystem you're operating in might use long URLs when they could have used short ones, but in general, use the short form for everything when you can.

Kristina Yasuda: anyone willing to be assigned?

Sebastian Crane: I just want to say that URIs and IRIs are difficult to work with, JSON-LD is about dealing w/ that, but in general, this is an advantage that when processing pure JSON, you don't have to parse actual keys themselves... "a" and value, then "x" and value, you don't have to parse string value -- parsing becomes a lot more difficult, if it is feasible, we should enforce short names and that will be a tangible help for those not going full JSON-LD route.

Orie Steele: IMO that guidance would be fine...

Manu Sporny: If I'm going to do a PR for this, it would say that you should use short form URLs, not long ones, but if you use long ones it's ok, just don't expect interop.

Sebastian Crane: When we're talking about using long or short forms, we are talking about official and VC context, not other context.

Orie Steele: I would say we are talking about all contexts.

Manu Sporny: Compact form means every single context that's applied.

Sebastian Crane: So fragmentation is an issue?

Manu Sporny: No, that's not what's being said. For a given document, if you're using a set of contexts, you are expected to use the short form for everything that's defined in those contexts.
… The comment you made on fragmentation I didn't follow, because not every VC will use the same context. A VC for a permanent resident card will use one set of contexts and one for a university degree, a different set of contexts will be used. The guidance will be to use the short form with each respective context used.
… If there's a short form version of the thing, don't use the long form. It doesn't mean you can't use URLs anywhere, you can of course do that. But when using the specific vocab and context you're using, use the short form.

Sebastian Crane: When people create contexts for use for anyone issuing and consuming VCs, people should use shortened forms for those and that helps with interop at a second order.
… I'm for that.

Kristina Yasuda: ok, thanks for clarification.
we have 12 minutes, let's go through before CR that don't have "ready for PR".

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22.

[msporny]

Based on the discussion last week, we decided that allowing expanded type values would have negative impacts on environments that don't do JSON-LD Processing. The suggestion during the call was to strongly advise document authors to NOT use expanded type values (or any expanded form for a term).

[OR13]

I disagree with framing, regarding JSON processors, which will happily process arrays of strings or URLs or a mixture...

I look forward to seeing the value of JSON-LD processing section address the concerns regarding processing types that are URLs.

[iherman]

The issue was discussed in a meeting on 2023-08-16

• no resolutions were taken

View the transcript

2.2. Allowing expanded type values in conforming documents (issue vc-data-model#1206)

See github issue vc-data-model#1206.

Kristina Yasuda: we discussed 3 weeks ago, there didn't seem to be agreement to add this to VCDM.

Orie Steele: Our current language says document has to be compact, don't know if you can use URL in compact JSON document, I expect people have done that in v1 of spec, expect them to keep doing that.
… We should expect to see people mix compact type w/ expanded tpes, or just put URLs in there... that can create logical/validation issues... if you process as JSON-LD and RDF and doesn't expect to not have them, libraries can explode.
… This is in the category of not addressing this particular piece, make it clear to implementers that it's not ok to do, might see this in the wild, we should providde some guidance.

Orie Steele: A JSON processor has not problem with arrays of strings.

Manu Sporny: The problem isn't with JSON-LD processing, a JSON-LD processor will be fine. Doing vanilla JSON processing will have to look out for the long and short forms. The reason we made the rule is so that vanilla JSON processors could just use the shortened form.

Orie Steele: JSON Processors don't understand "compact form"... thats a JSON-LD concept.

Manu Sporny: If the JSON processors put that logic in -- that would work just fine. I agree we should put in guidance to say "don't do that, if there's a shortened form, use that, not the full URL".

Sebastian Crane: JSON processors don't understand �anything� - semantic meaning is always added by the scheme, like an OWL document in the case of JSON-LD.

Brent Zundel: who is willing to be assigned?

Manu Sporny: As Orie said, there are some ecosystems might expect that. If we didn't use JSON-LD (only vanilla JSON) people would still need to pay attention to it. So some guidance that says you might experience it in the wild, and the ecosystem you're operating in might use long URLs when they could have used short ones, but in general, use the short form for everything when you can.

Kristina Yasuda: anyone willing to be assigned?

Sebastian Crane: I just want to say that URIs and IRIs are difficult to work with, JSON-LD is about dealing w/ that, but in general, this is an advantage that when processing pure JSON, you don't have to parse actual keys themselves... "a" and value, then "x" and value, you don't have to parse string value -- parsing becomes a lot more difficult, if it is feasible, we should enforce short names and that will be a tangible help for those not going full JSON-LD route.

Orie Steele: IMO that guidance would be fine...

Manu Sporny: If I'm going to do a PR for this, it would say that you should use short form URLs, not long ones, but if you use long ones it's ok, just don't expect interop.

Sebastian Crane: When we're talking about using long or short forms, we are talking about official and VC context, not other context.

Orie Steele: I would say we are talking about all contexts.

Manu Sporny: Compact form means every single context that's applied.

Sebastian Crane: So fragmentation is an issue?

Manu Sporny: No, that's not what's being said. For a given document, if you're using a set of contexts, you are expected to use the short form for everything that's defined in those contexts.
… The comment you made on fragmentation I didn't follow, because not every VC will use the same context. A VC for a permanent resident card will use one set of contexts and one for a university degree, a different set of contexts will be used. The guidance will be to use the short form with each respective context used.
… If there's a short form version of the thing, don't use the long form. It doesn't mean you can't use URLs anywhere, you can of course do that. But when using the specific vocab and context you're using, use the short form.

Sebastian Crane: When people create contexts for use for anyone issuing and consuming VCs, people should use shortened forms for those and that helps with interop at a second order.
… I'm for that.

Kristina Yasuda: ok, thanks for clarification.
we have 12 minutes, let's go through before CR that don't have "ready for PR".

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22.

[brentzundel]

It is my understanding that the PR that addresses #1227 will also address this issue.

[msporny]

PR #1276 and #1270 have been raised to address this issue. This issue will be closed once PR #1276 and #1270 have been merged.

[msporny]

Marking issue as pending close, as it does not seem like we will be able to get consensus around #1276 or #1270 and you can use full URLs everywhere in JSON-LD if you'd like (even though it would harm interop). Closing in 7 days unless there are objections.