Fragment identifiers for blank nodes on IPFS

[joeltg]

So I'm curious about fragments, blank nodes, and content-addressable documents.

I have a bunch of flattened json-ld documents on IPFS (where they're named by their hash) and I want to have IRIs for their blank nodes.

IPFS recommends URIs like this for files: dweb:/ipfs/QmYR8mihaWhwmY2RcQqmyXRU8qdCMcc5pMvU7AkZdvgD4f

and I'm imagining trying to reference some blank node of a previous json-ld document:

{
  "...some_property": {
    "@id": "dweb:/ipfs/QmYR8mihaWhwmY2RcQqmyXRU8qdCMcc5pMvU7AkZdvgD4f#_:b0"
  }
}

Is this an appropriate use of fragment identifiers? Is the idea of IRIs for blank nodes heresy?

The spec just has one sentence that points to the RDF spec, which says that in "a primary resource <foo>, the secondary resource identified by a fragment bar is the resource denoted by the full IRI <foo#bar> in the RDF graph". From my understanding, this is actually impossible for content-addressed resources, since it would require the document to contain its own hash.

[elf-pavlik]

From my understanding, this is actually impossible for content-addressed resources, since it would require the document to contain its own hash.

Inside document you can use relative path <#bar> or "@id": "#bar" in JSON-LD

I want to have IRIs for their blank nodes.

I think if one needs IRI then should NOT use blank nodes, one of mechanism available to create resource which has IRIs instead of blank nodes: https://www.w3.org/TR/rdf11-concepts/#section-skolemization

Is this an appropriate use of fragment identifiers? Is the idea of IRIs for blank nodes heresy?

From what I understand blank nodes identifiers come as a side effect of specific serializations or store implementation see this NOTE. IRIs serve purpose of directly identifying something.

[gkellogg]

You can’t directly create IRIs from blank nodes (other than through RDF Skolemization, which you don't really want to do). However, you can change the document source to use document-relative fragment identifiers instead. In 1.1, you can use "@vocab": "" in the context definition to cause vocabulary-relative terms to be resolved against the document. Of course, document relative IRIs are already resolved against the document.

As @elf-pavlik notes, fragments are sub-resources, and fetching a URL with a fragment does not cause the fragment, itself, to be sent as part of the request. Instead, the fragment is defined within the retrieved document, subject to the definition of the particular media type.

According to RFC3986:

The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced.

JSON-LD defines it's media type in IANA Considerations and notes the following:

Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].

JSON-LD (and RDF, in general) makes use of this across different IRI schemes, and the fragment identifier doesn't necessarily need to be defined within the document itself in order to have meaning. It's use in IPFS should be no different.

So, my interpretation is that you're fine for schema such as IPFS, as you continue to retrieve the resource using it's hash, as before. It's the interpretation of that resource which defines the sub-resources identified using fragment identifiers.

If you're happy with this interpretation, please close the issue. Otherwise, we can keep talking!