# for namespace properties should be optional
pdpark opened this issue · comments
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.
@pdpark what is the problem cause by the current behavior?
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?
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
againsthttps://localhost/some/ns
will producehttps://localhost/some/property
- constructing URI from namespace
https://localhost/some/ns
and local nameproperty
will producehttps://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?
* 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.
* 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...