There are still many, many instances of repo paths
appearing in the RDF model where there should be
absolute ftss URIs. Many scopes and statement
subjects are repo paths. You can see them if you do
a '4ss rdf complete'.
MikeO has a fix but it is quite tangled into the other "server
optimization" work and cannot be untangled without
significant effort. As a result, we decided that this bug would
be known but unfixed in 1.0. The 1.1 branch should emerge
soon thereafter with the fix and the heavy optimization work.
My apologies for the inconvenience. I pushed for us to nail
this one, but MikeO convinced me it would mean significant
delay of 1.0. Another factor in our deciding not to fix this for
1.0 is that there are workarounds, which generally involve
writing functions that add and subtract the "ftss://" at the
places where the bug causes inconsistencies. Evan Lenz
already navigated this and perhaps he has a few quick
pointers on how he worked around it? Once we do fix the
bug, URIs for resource objects will *always* start
with "ftss://". Of course, non-URI uses (e.g. paths specified
on the command line) will just be the plain path (i.e.
no "ftss://").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=371366
In http://lists.fourthought.com/pipermail/4suite/2003-
August/005715.html, Uche says:
MikeO has a fix but it is quite tangled into the other "server
optimization" work and cannot be untangled without
significant effort. As a result, we decided that this bug would
be known but unfixed in 1.0. The 1.1 branch should emerge
soon thereafter with the fix and the heavy optimization work.
My apologies for the inconvenience. I pushed for us to nail
this one, but MikeO convinced me it would mean significant
delay of 1.0. Another factor in our deciding not to fix this for
1.0 is that there are workarounds, which generally involve
writing functions that add and subtract the "ftss://" at the
places where the bug causes inconsistencies. Evan Lenz
already navigated this and perhaps he has a few quick
pointers on how he worked around it? Once we do fix the
bug, URIs for resource objects will *always* start
with "ftss://". Of course, non-URI uses (e.g. paths specified
on the command line) will just be the plain path (i.e.
no "ftss://").
Logged In: YES
user_id=1098276
See Patch: [ 1004040 ] GetUserNsMappings function requires
RepoPathToUri