RE: ANN: XSLT RDF Parser

Hello.

> Aside: there's a minor problem with that page; missing stylesheet:
> <link rel="stylesheet" href="injektilo.css" type="text/css" /> caused
> Netscape to 404, because of an amusing bug in Netscape where pages with
> bad stylesheet links show up as 404s (not exactly graceful
> degradation...;-)
>

Oops. Sorry, I'm new to CSS and don't use Netscape anymore although I can't
wait for Mozilla.

> So does nybody fancy running some benchmarks? eg. this XSLT in a C++ XSLT
> engine versus SiRPAC, VRP, the Prolog parser etc etc...?
>

I'd probably assume that all other implementations would outperform this
transform. I'm using SAXON for testing and the overhead of just starting the
JVM is ridiculous. (I have a batch file that transforms all the examples so
that I can make sure I haven't broken anything.) This would be a good
candidate for a compiled stylesheet.

My personal choice for developing an application would be to use something
like SiRPAC where I can register myself as a consumer and just receive
callback assertions. That was my original goal but I've obviously gotten
side-tracked.

> One little thing: where you have an ID, eg 'foo', you're outputting '#foo'
> where one might expect 'http://baseuritodocument.../etc#foo'.
>

I figured I would need to do that. I don't think I can get the base URI from
within the transform. It'd have to be a parameter to the stylesheet. Can the
Extraction Service pass those on to whatever XSLT engine you're using?

> Hmm... I've not met anyone who considers this anything but a
> bug. Something needs to be done about that; in the meantime, nobody seems
> to be creating data that uses aboutEachPrefix anyway.
>
> Longer term, we'll want something similar, but that has an RDF model
> representation. There's two aspects: (1) picking out a class of things
> to make statements about, but without laboriously enumerating its members
> (really handy) and (2) doing so through regex matching against URIs
> (sometimes useful).
>

Aren't both of those approaches just as impossible? Even if the human
marking up the RDF decided to use
aboutEachPrefix/aboutEachInstance/aboutEachRegexp how would the parser
generate triples for those sets when it couldn't possibly find every member?
Unless you're talking about restricting it to the set of resources already
defined in the model?

Jason.

Received on Wednesday, 13 September 2000 11:58:14 UTC