exporting storage content (including metadata)

[elf-pavlik]

In #32 we specify which link relations gets used for each kind of metadata resource. Some of them use full URIs some of them try to reuse registered by IANA link relations. If we want to be able to export all the content of solid storage, i would need to include all the metadata resources as well as all the links between resources and metadata resources. Full URIs can easily be used as predicates in RDF statements but IANA registered link relations don't have official mapping to URIs mnot/I-D#140

[ericprud]

@elf-pavlik, that's an enormous thread; much respect for your persistent attention to it. If you recall, can you summarize where it ended up and whether the algorithm in RFC4287 sufficiently defines a URL for rel="notAURL"?

(Also, you owe me a band-aid for the blister on my finger from scrolling through I-D#140.)

[justinwb]

@elf-pavlik In the absence of stable link relation URIs - would it be fair to say that for any IANA string definition we're using we create a URI for it in the solid namespace that can be used at a minimum for portability during serialization (if not as outright replacements)?

[ericprud]

I would dispute a couple assumptions in mnot/I-D#140 which lead to pessimism about solving the problem in RFC5988 (still a draft):

1. This is an RDF problem (really it's a WebArch problem as it encourages IRI identifiers for anything worth discussion).
2. Because Atom specified an Atom-specific behavior, IETF can't specify a general rel-to-IRI mapping that conflicts with it.

If I understand our problem we'd like a homogeneous way to reference URI-based and string-based rel relations. The tension is that we'd like to use something that works for any WebArch app, e.g. Atom if it were re-written today.

Isn't this identical to the IRIs-for-media-types problem? There's always been an irresolvable tension between the notion that we want a few centralized media-types for interop and we have a long tail of formats that deserve interop. The same is true for relationships between IRIs, just less poignant 'cause IDing types is typically a higher priority.

I this Justin's proposal allows us to set a good example someplace and use it provisionally, with the hopes that IETF folks decide to own it. That said, we'd like to write it down in the most public and tech-neutral place possible so it's available for wide use if the IETF doesn't adopt it. w3id and w3.org both seem reasonably prominent, neutral, and responsible about long-term maintenance. Mixing IETF and non-IETF rel types would probably mean you'd want some hierarchy ('/'s) or aggregation ('#'s)to reduce cognitive collisions, e.g. http://www.w3.org/rel/ietf#latest-version, http://www.w3.org/rel/solid#shapeSchema, http://www.w3.org/rel/acls#acls. Whoever owned it would have to administer contention for names in that hierarchy.

Thinking aloud about the format of the rel declaration (i.e. the GETable doc); a JSON-LD doc with field for the Relation Name, Description, Reference and Notes fields defined in 5988 (examples). Non-registered relations could be the same minus the Relation Name. e.g.

GET http://www.w3.org/rel/ietf =>

[
  {
    "@content": "…",
    "@id": "http://www.w3.org/rel/ietf#latest-version",
    "ietfRelationName": "latest-version",
    "description": "Points to a resource containing the latest version of the context.",
    "reference": {
      "name": "RFC5829",
      "url": "https://www.rfc-editor.org/rfc/rfc5829"
    }
  },
  …
]

Here we're inventing a media type which documents the resolution of fragments to elements in the collection. It could be specific to this registry like the above (look for the entry with the matching @id), or a more general scheme using JSON objects:

{
  "latest-version": {
    "@content": "…",
    "ietfRelationName": "latest-version",
    "description": "Points to a resource containing the latest version of the context.",
    "reference": {
      "name": "RFC5829",
      "url": "https://www.rfc-editor.org/rfc/rfc5829"
    }
  },
  …
}

So, who want to own maintenance of that?