Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle predicate for confidenceMethod in JSON-LD context #1116

Closed
awoie opened this issue May 8, 2023 · 4 comments
Closed

Handle predicate for confidenceMethod in JSON-LD context #1116

awoie opened this issue May 8, 2023 · 4 comments
Assignees
Labels
pending close Close if no objection within 7 days

Comments

@awoie
Copy link
Contributor

awoie commented May 8, 2023

Update JSON-LD context to handle confidenceMethod

@Sakurann
Copy link
Contributor

subject to PR #1054

@iherman
Copy link
Member

iherman commented May 25, 2023

The issue was discussed in a meeting on 2023-05-24

  • no resolutions were taken
View the transcript

2.3. Handle predicate for confidenceMethod in JSON-LD context (issue vc-data-model#1116)

See github issue vc-data-model#1116.

Orie Steele: I don't think we should include confidenceMethod or any predicates in the core contexts for which there are no defined RDF types.
… Exceptions to that -- are where we have a formal spec that defines an RDF type for that extension point.

Michael Prorock: +1 orie.

Orie Steele: If there's a CG spec then we can include it, like renderMethod ... for any predicates with "a blank check" because they have no RDF types ... should not be in the core context.

Kristina Yasuda: I'll assign this to Oliver for now to have him handle that.

Oliver Terbu: The confidenceMethod PR is currently stuck.
… And I don't know how to proceed.
… I don't have anything to add today. I encourage everybody, especially those people who raised concerns in the PR to follow up on the latest.
… Just to make it clear that there's a chance to get this PR merged or not.
… If there's a chance to get it merged, what needs to be changed?

Orie Steele: ideally, define an RDF type for confidenceMethod completely, such and interoperability at both the predicate and the type can be achieved.

Orie Steele: look at the renderMethod PR.

Michael Prorock: I would suggest that there's a path forward but might not be desirable. It is to follow exactly the model that was taken with renderMethod, where you take confidenceMethod define it in a CCG spec.
… I don't see people objecting.
… Point to it -- and at that point the road is clear, make sure it's in there and referencable, etc. It gives a clean path to incubate and polish.
… In the render case, there's a lot of implementers -- it may not be suitable as part of the core data model.
… I was having this conversation in person -- it isn't that a lot of things aren't good ideas, it's just a question of whether it would be better to standardize things in their own documents instead of in the core data model spec.

Oliver Terbu: I'm totally fine with that approach by the way. I can't really speak for the other people -- especially people who created holder binding over the last couple of years.
… I think before closing this PR and moving forward with the way MikeP suggested, we need to reach out to those people and see if they object to moving forward the way he said.

Orie Steele: I just wanted to say -- a lot of this is related to VPs.
… I find this incredibly poorly defined in the current data model. It's possible that efforts going into this confidenceMethod could massively improve the requirements around VPs.
… I don't know, it's hard for me to tell. The requirements for a VP is that it's a JSON-LD object with a context and a type and that's enough rope to build anything.
… It seems weird to me, some of this is related to subject-is-holder flows.

Michael Prorock: +1 orie - there is good value here - however once again this may be better handled as a separate specification.

Orie Steele: That's one reason this is held up -- it's covering a lot of ground.
… VPs remain a weak spot in the spec and they need improvement.

@brentzundel
Copy link
Member

Now that PR #1054 is pending close, I believe this related issue should be as well.
Marking as pending close and will close in 7 days if no one objects.

@brentzundel brentzundel added the pending close Close if no objection within 7 days label Jun 26, 2023
@brentzundel
Copy link
Member

No objections raised since marking as pending close, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending close Close if no objection within 7 days
Projects
None yet
Development

No branches or pull requests

4 participants