Each 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).