# for namespace properties should be optional

[pdpark]

From the README: "Property namespace is constructed by adding # to the base URI."

If the base URI ends in a forward slash (/), a pound/number sign (#) should not be added to the base URI.

[namedgraph]

@pdpark what is the problem cause by the current behavior?

[mielvds]

I agree with this. When you supply a # in the property namespace you get a weird error and it takes a while until you figure out that you have to remove the #. I also find it rather unintuitive; if you supply a namespace, you don't expect modifications. What's the reason you designed it like this?

[namedgraph]

OK, I can see # can be unintuitive. This was done mostly to align with CSV2RDF, which uses # for properties made from column names.

We should be careful about the terms "base URI" vs. "namespace" though, as those can lead to different behavior:

• resolving property against https://localhost/some/ns will produce https://localhost/some/property
• constructing URI from namespace https://localhost/some/ns and local name property will produce https://localhost/some/nsproperty

Not a great example, but based on this issue I think what we want here is the namespace, not base URI. I'm not even sure it's legal for base URI to have # in it, for example. @pdpark @mielvds do we agree here?

[mielvds]

* resolving `property`  against `https://localhost/some/ns` will produce `https://localhost/some/property`

Oh, why is that?

* constructing URI from namespace `https://localhost/some/ns` and local name `property` will produce `https://localhost/some/nsproperty`

Sure, but that's the user's concern, no? I see two options: 1) a warning that URIs will be weird if the supplied namespace does not end with # or /; or 2) adding a #, but only if the supplied namespace does not end with # or /.

Not a great example, but based on this issue I think what we want here is the namespace, not base URI. I'm not even sure it's legal for base URI to have # in it, for example. @pdpark @mielvds do we agree here?

If it's not allowed, it should be in https://tools.ietf.org/html/rfc3986#section-5.2 (can't tell at this point)

Since we're talking about a namespace, a nice-to-have is adding it as source or json prefix to the turtle output.

[namedgraph]

* resolving `property`  against `https://localhost/some/ns` will produce `https://localhost/some/property`

Oh, why is that?

Resolving against base URI follows general URI resolution:

System.out.println(java.net.URI.create("https://localhost/some/ns").resolve("property").toString());

returns https://localhost/some/property since there was no trailing / in the base.

* constructing URI from namespace `https://localhost/some/ns` and local name `property` will produce `https://localhost/some/nsproperty`

Sure, but that's the user's concern, no? I see two options: 1) a warning that URIs will be weird if the supplied namespace does not end with # or /; or 2) adding a #, but only if the supplied namespace does not end with # or /.

Yes it is a user's concern. In this case namespace and local name are simply concatenated. I'd rather not put any restrictions on that.

I will refactor this to be a namespace thing rather than a base URI thing. So the base parameter name might change.

Now I wonder how CSV2RDF should be aligned with this...