subName is its own
Resolveable Map. You could potentially string them to infinity, which is why I suggest we put a timeout limit on that.
Originally, I was intending a
Files Map to be a sub class of
Resolvable Map (being all but the same, but for the context of its use (which can be important for the resolver).
With this I’m intending to mean, the last MD of
Files Map type… and we then go on to resolve the
path of the url, with what we’ve found there.
I’ll clarify this in the RFC
I find myself wondering the same. While we’ve set up the
default construct to allow for now wanting a
Sub Name… Do we require a
Resolvable Map before a
Files Map. I don’t think so. I can’t see a reason to need it… thoughts? (@bochaco?)
Yeh, we actually spoke briefly about this being its own RFC, which I think might be worth doing as it is not strictly anything to do with the resolution (beyond the sha3 hash of name pointing to our first
Map. So I think that might be worth doing, to give that the space it needs to clarify such things (as I think it is confusing trying to shim it in here).
(Though in short: it would be RDF, so yes, talking about
keys is somewhat confusing. Though to clarify in our current setup of using MD, a sub graph will actually map to a key, such that we can have
safe://<yourPublicName> as a key in the MD (which would be the subject of the graph, and target
@id in jsonld terms).
This should actually be changed to talk about
resolvesTo, and is something I’ve missed after we did a refactor of the graphs last week (Though I agree on the use of base URI’s where it’s appropriate).
I honestly don’t find turtle any easier, and more often than not, more confusing. This comes down to personal preference IMO. (There are many w3c specs which choose JSON-LD over turtle in their examples).
But the representation becomes important when considering how it might map to our data structures (namely MD in this case, as that’s what we’re suggesting to use, and the mapping is important when considering performance on fetches/iterating over graphs etc).
I’m not really into adding in two formats for examples though, as it would make everything very long (given the limitations of github presentation… a tabbed setup for examples would be ideal).