This thread is for discussion of the RFC. Please fire in with comments / critique / concerns, and all that lark. PRs to my repo are welcome with suggestions / fixes etc (though let’s discuss here first).
So, aye. Have a read and let us know what you think! There are no stupid questions, if something is not clear to you, then we should probably be making it clearer.
Any chance you can provide the RDF in Turtle? I find JSON-LD hard to relate to triples and the structure of an RDF graph. Cheers
As far as I can make out it maps into the existing data model for public names etc, adds support for xor URIs (woop!), and brings the power of RDF / LinkedData to SAFE APIs, so it gets my vote
@joshuef one question I had rolling around in my head.
This RFC proposes that url schemes such as safe://somewhere can have sub-domain’s with resolvable services which can be either chosen by the end user application, or default to specific data.
Does this mean we can have human readable pretty url’s?
By the way, and I hate to be that guy but (PNS) coughcough
@bochaco and I have just done a wee rejig of the schemas to be based off of RDF documents as opposed to attempting a single graph. So we’ve included some ttl representations of that in the updated data structure image in the RFC @happybeing.
Indeed. It means there’s a lot of flexibility in terms of how we can name / use links to target data on the safe network. beautiful urls included.
I’m a bit confused by your question @Nigel , are you by any chance talking about tiny URLs like https://tinyurl.com/?
Because the subNames are not exactly that, I just wanna be sure of what you were referring to.
Thanks guys, that helps a lot. I shall find out if I understand turtle now.
I’ll accumulate my comments in this post for now.
Notes
can we tentatively add a ‘directory/container’ type in case when we get to implementation this can be supported - maybe just as a footnote? Mainly so we can consider it rather than necessarily implement it. Reason: for SAFE Drive I’m currently having to jump through tricky hoops to cope with the lack of empty directories - because applications don’t like directories to disappear when they become empty! I may have some other requests wrt to the NFS API as I get into why certain apps aren’t working yet, but this probably won’t affect this (RDF Schema) area, while directories certainly would. Some things are proving hard to map from POSIX to SAFE NFS. Fingers crossed for now though, I have lots of things working and can use up all my PUTs with three runs of my test script I digress!
@bochaco when I was looking at safe://subName.subName.subName.subName.publicName It made me think something like safe://RideOn.DirtyDeedsDoneDirtCheap.AC/DC
or the like. Where you could almost represent a directory as subdomains and have that shown in the URL.
@joshuef@bochaco I wonder if it would be useful to explain your process of options considered, reasons for any choices a bit.
This occurred to me because I recall early on Gabriel thinking out loud about whether to use different LDP container types, for example. It would help me understand how to think about the structure you’ve arrived at having not delved into the what’s and whys myself. It looks perfectly sensible and adequate as it is, but I’m not really sure what other options there might be to think about.
Also, have you / do you plan to run this past any of the RDF experts in the Solid team? I guess they might just not have time, but generally they will take a look if you approach them directly.
In the PoC we experimented with LDP-DC, if you look at the example 25 from here: Linked Data Platform 1.0 Primer you’ll see there is like a redundancy in linking to “< bug3 >, < bug4 >” with ldp:membershipResource, since “< bug3 >, < bug4 >” are already linked with: ldp:contains <bug3>, <bug4> . triples.
So now we considered the format the WebID uses, which is simpler as it doesn’t seem to need any link from the default graph to the other named graphs, except for the foaf:primaryTopic, yoou can see the example here: WebID 1.0
No, that was in the context of the public names container, what it’s called Resolvable Map in the RFC, that it’s just the same as the Files Map which would replace the NFS. Dunno how you image it could be better, please share a Turtle for how you imagine it could be better so people can compare the approaches, that’s the only way we found useful for discussing about this.
You’d also be able to do the same with a path safe://AC/DC/DirtyDeedsDoneDirtCheap/RideOn. It’s all possible.
Main thing to watch our for with subsusubNames is redirects. Right now I’m proposing a limit of 10, which is an entirely arbitrary number just to keep load times reasonable (though what that actually means in practice we’ll have to see.
I was mulling this over. I totally don’t see a reason not to have one. And i wonder if the simplest approach is just for the directory graph to point to a blank node. That doesn’t require any major changes / additions, perhaps aside from noting it in the Resolvable Map schema that that is what that signifies…
I’ve posted in the linked data gitter atm. Will drop it in the SOLID forum to see if anyone might want to opine, though it does feel a bit off topic over there (not sure if they have categories for such things on the forum. Will find out soon enough!
@joshuef I was thinking of asking somebody directly. I’ve done this in the past and now your faces are known you could do this, although they are now very busy with Inrupt so may just not have time.
On containers I don’t know the RDF implications, and how we’d translate this in storage implementation. I’m just thinking that the lack of this causes problems in the application side of things. Any app that provides its own UI for storing files may have to tackle this.
@bochaco yes, sorry again. It was of course the public names container! I don’t have an alternative in mind, nor time to figure one out. I’ve not spent time learning the ins and outs of ontologies and RDF handling, so you and Josh are way ahead of me there. Just trying to understand your process and review the proposal through discussion.
About URL resolution: Is it possible to have a Public Name that looks like a XOR-URL? If so, I understand that webFetch will try to resolve it as a XOR-URL first, and then try resolving as a Public Name after the XOR resolution fails, which seems like an inefficient use of GETs even if it is an edge case.
There’s nothing stopping that at the moment, for sure.
It would be a pretty bad choice for a public name (a xor url exmaple: safe://a078516207e36aa2371e17750c93276446bdb4867c027035531b89430aa8d3ae2fa4dbb59 from the proposal post ).
One possible thing is to alert people to this when making a publicName (of given length/style or some such), but that’s not a real solution.
I’m not sure what we’d need to do to prevent it (nor if we should be, given how edgy / terrible that is for a public name… which if you’re doing that, why not just use the xor url?)
I also don’t think this necessarily needs to prevented, just trying to consider all the edge cases
One interesting consequence of this is that if someone uses an existing XOR-URL as a Public Name, that Public Name will never be resolvable. I don’t know why anyone would want to do that though, and e.g. displaying an alert should be enough to dissuade them.
I digress!