[4suite] RDF representation of repo paths

[Uche Ogbuji]

On Wed, 2003-08-13 at 14:52, Matt Gushee wrote:
> Hello, all--
> 
> I have run into trouble with some RDF queries that are supposed to
> retrieve the values of various properties on repo resources. Some of the
> properties are builtin 4Suite metadata, some will be set through other
> means. The problem I'm running into is that sometimes the resource path
> is represented as a plain path, such as
> 
>   /ftss/dav/demo
> 
> while other times it is an ftss:// URI, like
> 
>   ftss:///ftss/dav/demo
> 
> Now, it appears that in the case of builtin metadata statements, the
> plain form is always used, but when the path is the subject of a
> separately added statement, e.g.
> 
>   <rdf:Description about="/ftss/dav/demo" type="&fd;collection">
>     <dav:displayname>WebDAV_Demo</dav:displayname>
>     <dav:getcontentlanguage>en_US.ISO-8859-1</dav:getcontentlanguage>
>     <dav:resourcetype resource="&fd;undefined"/>
>     <dav:source resource="&fd;undefined"/>
>   </rdf:Description>
> 
> then the ftss:// form is used.
> 
> So, I don't suppose there's any way to force the repo to use the plain
> form, is there? Assuming there isn't, have I understood correctly what
> is going on? Are there any other rules, or quirks, I should know about 
> the usage of ftss://?

This is a known bug.  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
inconsisyencies.  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://").


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
XML Data Bindings in Python, Part 2 - http://www.xml.com/pub/a/2003/07/02/py-xml.html
Introducing Examplotron - http://www-106.ibm.com/developerworks/xml/library/x-xmptron/
Charming Jython - http://www-106.ibm.com/developerworks/java/library/j-jython.html
Python, Web services, and XSLT - http://www-106.ibm.com/developerworks/xml/library/ws-pyth13/
A custom-fit career in app development - http://www.adtmag.com/article.asp?id=7744