Re: List items in SiRPAC - problem and bugfix

On Fri, 20 Aug 1999, Pierre-Antoine CHAMPIN wrote:
> There's a strange thing about list items in SiRPAC.
> In the attached file, I wrote :
> 
>   <rdf:Bag rdf:ID="B01">
>     <rdf:li rdf:resource="#foo1" />
>     <rdf:li rdf:resource="foo2" />
>   </rdf:Bag>
> 
> with resources foo1 & foo2 defined in the same file.
> Which line is right ?
> In my opinion, the first is, the second is not.

Agreed. 'foo2' should (following relative URI rules) be interpreted as
another file in same directory as that file. 


> 
> But in SiRPAC, both are handled in quite a strange way.
> I get the triples :
> B01 -> _1 -> #foo1 (?!...)
> B01 -> _2 -> file:///home/pa/rdf/tmp.bag.rdf#foo2
> 
> So for SiRPAC, the second LI construction IS right,
> and the first is not...
> What do you guys think of it ?

Smells like a bug to me. There are some other complications w.r.t.
SiRPAC's treatment of relative URIs, which I've worked around in part
through feeding these to the java.net.URL class -- an inadequate
approach since it assumes URL==URI, and gets confused by 'urn:' URIs.


> Actually, I keep thinking it's a bug in SiRPAC,
> since somewhere (in method valid(), to be precise)
> "#foo1" is resolved to "file:///home/pa/rdf/tmp.bag.rdf#foo1"
> but valid() doesn't correct the 'resource' attribute -
> it only adds the resolved name as a target,
> which is obviously not sufficient.
> 
> So I corrected it by adding :
> 
>     String sResource = e.getAttribute (RDFMS, "resource");
>     if (sResource != null) {
> 	if (sResource.startsWith ("#"))
> 	    sResource = sResource.substring(1);
> 	Element e2 = (Element)lookforNode(sResource);
> 	if (e2 != null) {
> //-> ADDED by PA
> 		e.resource(e2.name());
> //-> end ADDED by PA
> 	    e.addTarget (e2);
> 	}
>     }
> 
> and I did the same with about (before that) and aboutEach (after that)
> - just in case...
> 
> then both triples point to the right resource.
> 
> 
> I raised a question a few weeks ago, but got no answer.
> Can anybody from the W3C (or anybody aware, anyway)
> tell me if SiRPAC is still maintained ? how about the bugfixes
> published in this list ?

I've volunteered to take over as a temporary holding caretaker for
SiRPAC, though am not really the right person to tend to this code.
Janne has I believe another cycle of bugfixes to roll in. After that, we're
looking for one or more volunteers to help.... [hint hint ;-]

My inclination is to draw a clearer distinction between the SiRPAC APIs
and the actual parser machinery; both are good but we could for example
imagine other Java parsers hooking into a common framework via shared
APIs (eg. my code all uses the java:org.w3c.rdf.* base classes for
Resource etc and the datasoource and consumer interfaces) without using
the parser itself.

A good start will be a 'TODO list' and status page on the W3.org site.
I've just got access to these files so could see about updating them if
Janne doesn't have time.

Dan

Received on Friday, 20 August 1999 07:23:53 UTC