for evidence that supports claims, do we need pointers within a URI?

[monkeypants]

Related to #42, when providing evidence to support a specific claim in a DPP (e.g. a conformity claim, facility location claim, etc) we can reference the evidence by a URI.

It's possible that the same evidence URI could support multiple claims. E.g. a document or audit may relate to multiple claims. . Perhaps we need a way to explicitly reference a location within the URI. For example, "Section 5.8" of the document at the given {URI}.

Maybe it's possible to use different URIs for specific parts of the same document. for example:

• fragment https://example.com/path/to/document#section-5-8
• query https://example.com/path/to/document?section=5.8
• path https://example.com/path/to/document/5.8

However, that won't be possible in all cases. For example

• https://example.com/path/to/document.pdf <-- "read Section 5.8"

Suggest maybe evidence needs another (optional) attribute that's an internal reference within the URI. Possibly multiples (human readable instruction, machine readable instruction).

in VCDM evidence model, it says "The precise content of each evidence scheme is determined by the specific evidence type definition." Does that mean we could specify an evidence type with this attribute, within VCDM?

[VladimirAlexiev]

https://en.wikipedia.org/wiki/URI_fragment describes a number of fragment schemes. For PDF, there is

• #page=
• #nameddest= (similar to section, but I guess depends on PDF producing software)

https://www.w3.org/TR/media-frags/ specifies fragments in images, video, audio. See also:

• https://www.w3.org/TR/media-frags-recipes/
• https://www.w3.org/TR/fragid-best-practices/

The Web Annotation model https://www.w3.org/TR/annotation-model/#segments-of-external-resources also uses such URL fragments.

[monkeypants]

Thanks, good references - that's helpful!

It seems I was underestimating URI fragments, they might be sufficient in all cases of machine-readable references. Especially with RFC 6901 JavaScript Object Notation (JSON) Pointer, which would allow fragments that reference a specific claims within another VC. From there could be turtles all the way down.

Consider a scenario where the evidence is not conducive to conventional machine reading e.g. a scan of a wet-signed paper document, published in PDF but essentially similar to a jpeg. Even though some kind of geometric fragment might possibly create a valid reference, let's imagine for a moment that it's not convenient for the user to manage that with the tools they have. Does this scenario warrant a human-readable attribute on the evidence type, and would such an (optional) attribute be harmless?

[VladimirAlexiev]

@monkeypants I strongly recommend you don't use JSON pointers to refer to anything within a VC.

• VC are also JSON-LD (RDF), and for RDF all (significant) nodes should have their own URL (@id).
• The same RDF content can be expressed in many different ways in JSON: RDF is a graph but JSON is a tree, so JSON gives you semantically insignificant choices how to represent the graph as a tree. So the specific JSON pointer to an element is nothing like a permanent address (URL) of that element.

[monkeypants]

VCs are immutable, the insignificant choices / potential variability of equivalent structures happened in the past, before the reference to it was made. I don't see how a specific JSON pointer is not a permanent address in the case where the tree is imutable.

I do agree that links to RDF nodes are better than JSON pointers, because they are easier to parse with semantic web technology. But sometimes evidence won't be a VC, it could be unstructured data (or unverifiable structured data, semi-structured data, etc). I think @VladimirAlexiev that you are agreeing that we don't need a separate path property for evidence URI, right?

[nissimsan]

Is this what is meant?

[nissimsan]

@monkeypants , how can we drive this issue to close? Can you suggest actions, pls?