use of relative url

[bourgeoa]

A way to do it could be to have a more extensive list of prefixes :
const prefixes = {
b0: '#'
sol: './'
acl: 'http://www.w3.org/ns/auth/acl#',
foaf: 'http://xmlns.com/foaf/0.1/'
}

and replace the turtle code value of acl:accessTo with sol: for folder <filename> for files

What do you think ?

Example of solid acl files :
text4.txt.acl- Copie.txt
folder.acl- Copie.txt

[Otto-AA]

I agree with you, that the long accessTo filename is not nice to read. I will either make it relative or use a prefix for it.

Regarding the first two suggested prefixes (b0: '#' and sol: './') I don't think that they have a benefit. It actually requires more characters to write these prefixes, than the thing they replace. Is there a specific reason you suggested them?

Btw, #2 also makes the rule name relative, so this will be nicer to read.

[bourgeoa]

Have you look at the example files

[Otto-AA]

Yes. And I don't see how the first two prefixes influence them. As far as I see, the main difference between them is that text4.txt.acl uses relative paths and folder.acl uses absolute paths. And this is not related to the prefixes afaik

[Otto-AA]

Oh, I've meant #3 above. Also in the other issue. I hope this didn't lead to confusion.

[bourgeoa]

sorry
I send you the wrong folder .acl file
this one is made by mashlib using the previous one made by solid-acl-parser, it creates test: as prefix but it could be a fixed sol:

folder .acl- Copie.txt

[Otto-AA]

The test: <./> prefix here seems pretty unnecessary to me. At least adding it to the N3.Writer prefixes doesn't change anything.

const N3 = require("n3")
const path = require('path')
const { DataFactory } = N3;
const { namedNode, literal, defaultGraph, quad } = DataFactory;

const fileUrl = 'http://pod.example.org/foo/bar/'
const aclUrl = fileUrl + '.acl'
const relativeFileUrl = './'

const prefixes = {
  acl: 'http://www.w3.org/ns/auth/acl#',
  foaf: 'http://xmlns.com/foaf/0.1/',
  test: './'
}

const writer = new N3.Writer({ prefixes })
writer.addQuad(
  namedNode('#my-rule'),
  namedNode(`${prefixes.acl}accessTo`),
  namedNode(fileUrl)
)
writer.addQuad(
  namedNode('#my-relative-rule'),
  namedNode(`${prefixes.acl}accessTo`),
  namedNode(relativeFileUrl)
)
writer.end((error, result) => console.log(result));

@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix test: <./>.

<#my-rule> acl:accessTo <http://pod.example.org/foo/bar/>.
<#my-relative-rule> acl:accessTo <./>.

The best result I got was when using test: dirname(fileUrl) + '/' as a prefix, but this only works for files. Therefore I don't think that using prefixes will solve the problem.

[bourgeoa]

I agree prefixes from N3.writer() is not the solution. Can you achieve the following ? Then eveything is relative. It is only for objects relative the the pod. To be checked against podRoot for webId and podParentUrl for folder and files.

I have manually edited acl files with mashlib and the following is working for relative files without new prefix (note there is no # in subject - it did break acl check returning error 309) :

this is for folder .acl

 @prefix n0: <http://www.w3.org/ns/auth/acl#>.
 @prefix n1: <http://xmlns.com/foaf/0.1/>.
  <ControlReadWriteDefault>
    n0:accessTo <./>;
    n0:agent </profile/card#me>;
    n0:agentClass n1:Agent;
    n0:default <./>;
    n0:mode n0:Control, n0:Read, n0:Write.

and this for file.acl

 @prefix n0: <http://www.w3.org/ns/auth/acl#>.
 @prefix n1: <http://xmlns.com/foaf/0.1/>.

<ControlReadWriteDefault>
    n0:accessTo <text4.txt>;
    n0:agent </profile/card#me>;
    n0:agentClass n1:Agent;
    n0:mode n0:Control, n0:Read, n0:Write.

[Otto-AA]

Can you take a look if #3 is good for you?

It's not exactly what you proposed. The differences are:

1. It will use relative paths if possible (e.g. <../../profile/card#me>)
2. it will use <./text4.txt> and not <text4.txt>

I will probably change changed (1) to use paths starting from the root instead of going directories upwards. This would be </profile/card#me> as you suggested. I can also remove the ./ in front of file names in the same directory, but I think it's okay this way.

[Otto-AA]

Please tell me when you've taken a look at the PR and if you think something related to these issues is missing. If not I would merge it and make a npm release for it.

[bourgeoa]

I shall try to check this evening. But you can push to npm in between. You may consider merging solid-acl-parser 115kb and solid-acl-utils 345kb which contains twice N3, and at least push to the parser the writer part. Not checked in detail Le mar. 3 déc. 2019 à 19:45, A_A <notifications@github.com> a écrit :

…

Please tell me when you've taken a look at the PR and if you think something related to these issues is missing. If not I would merge it and make a npm release for it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AAQ5TZR5QTM65HJJWTQ6FB3QW2SOFA5CNFSM4JULRKHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF2M2CY#issuecomment-561302795>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5TZRPO7D3HITHGCBGCX3QW2SOFANCNFSM4JULRKHA> .

[Otto-AA]

Afaik, N3 isn't included twice in solid-acl-utils. It hasn't got N3 as a dependency, so it should only have the one from solid-acl-parser.

The reason I've kept them separate is to allow other libraries to use solid-acl-parser directly without including unnecessary dependencies from solid-acl-utils. For example server side applications likely won't need the stuff from solid-acl-utils, but only solid-acl-parser. That's also why I would keep it this way.

at least push to the parser the writer part.

I'm not sure what you mean with this. solid-acl-parser has methods to load a turtle and output a turtle, but it is not intended to save this turtle string somewhere. Do you mean this?

[bourgeoa]

Sorry I should have checked. Forgive my remarks

[Otto-AA]

No problem. I am also not happy with the bundle size of solid-acl-utils, but I don't really know how to reduce it. I guess it would get better if it is in one project, but at this stage of Solid I don't think that performance issues outweigh the benefits of keeping these modules separate. And I'm pretty confident that there would be a good way to keep them separate AND to have a lower library size, but I'm currently not aware of how to do it. So maybe in the future this will be better :)