Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Phil Dawes
Is this you? Claim Profile »
4 years ago
in Implementing graphs as triple ranges on Phil Dawes' Stuff
Cool - will take a look. Many thanks!
4 years ago
in How to disambiguate tag senses? on Phil Dawes' Stuff
Cool - I'll check it out, Thanks
4 years ago
in can we remove the need for ordered collections? on Phil Dawes' Stuff
Jimmy Cerra Writes:
Yet, it is the directed graph intepretation which makes RDF more useful for some types of data modeling than plain-old XML.
Definately, but retaining statement order doesn't mean ditching the directed-graph interpretation.
it is too late to change RDF significantly. Too many applications already depend on the current interpretation.
Of course you're right, but it's interesting to explore the idea.
Yet, it is the directed graph intepretation which makes RDF more useful for some types of data modeling than plain-old XML.
Definately, but retaining statement order doesn't mean ditching the directed-graph interpretation.
it is too late to change RDF significantly. Too many applications already depend on the current interpretation.
Of course you're right, but it's interesting to explore the idea.
4 years ago
in Time to deprecate RDF/XML? on Phil Dawes' Stuff
Hi Micheal,
Thanks for the comments - I agree that trix/rxr aren't likely to become success stories in the XML world. I was really thinking of the times when some application/agent wants to interchange some RDF within an XML document.
RDF/XML is a lot harder to parse than trix/rxr, and I suppose that's the appeal for me. Although thinking about it, that's not a good argument to replace rdf/xml as the defacto xml choice for machines talking to each other, since there's only a small number (few 10s) of implementations anyway.
I'm not keen on using XSLT for xml to triples. The primary reason is because XSLT is complicated, and I'm assuming you'd be using the XSLT to tranform XML into RDF/XML to import it.
Also, I suspect that it'll be easier to transform xml directly into triples given the right toys. This is a hunch though.
The bottom line is one of numbers - there are a small number of RDF implementations, and there are a small number of important web based xml dialects. There are in contrast so many xml users out there that I think it would be much easier to supply transforms, than to try and convince XML people to use a complex RDF serialisation format in its place. (Esp when it doesnt off them much value, as is the case at present).
Cheers,
Phil
Thanks for the comments - I agree that trix/rxr aren't likely to become success stories in the XML world. I was really thinking of the times when some application/agent wants to interchange some RDF within an XML document.
RDF/XML is a lot harder to parse than trix/rxr, and I suppose that's the appeal for me. Although thinking about it, that's not a good argument to replace rdf/xml as the defacto xml choice for machines talking to each other, since there's only a small number (few 10s) of implementations anyway.
I'm not keen on using XSLT for xml to triples. The primary reason is because XSLT is complicated, and I'm assuming you'd be using the XSLT to tranform XML into RDF/XML to import it.
Also, I suspect that it'll be easier to transform xml directly into triples given the right toys. This is a hunch though.
The bottom line is one of numbers - there are a small number of RDF implementations, and there are a small number of important web based xml dialects. There are in contrast so many xml users out there that I think it would be much easier to supply transforms, than to try and convince XML people to use a complex RDF serialisation format in its place. (Esp when it doesnt off them much value, as is the case at present).
Cheers,
Phil
4 years ago
in Suffix array performance problems on Phil Dawes' Stuff
Have implemented the changes in veudastore - released version 0.3.
To use this with veudas, replace the cgi-bin/veudas-0.6/veudastore directory with this release
To use this with veudas, replace the cgi-bin/veudas-0.6/veudastore directory with this release
4 years ago
in Suffix array performance problems on Phil Dawes' Stuff
Cool - think I've cracked it. The solution was to remove the original suffix and links tables, and replace them with a single suffixes table that just maps char(4) suffixes to literals.
This reduces the accuracy of the suffix match (meaning that substring searches > 4 chars need to join and filter with the nodes table (containing the literals). The width of the suffix field could be increased if this becomes a bottleneck, trading off more space for speed.
Have got the query down to 30ms on my laptop (down from 82.61 seconds on the original scheme). Other queries are looking good as well (mostly in the 10-30ms mark). Should fly on the 10GB 8 proc box at work :-)
The reason this is so much faster is that the mysql query optimiser gets a better view of the number of literals each substring will match, and so correctly identifies the best match order. Also, by indexing the new suffix table both ways (suffix-literal and literal-suffix), the query analyser can chose to impose other constraints in between substring filtering
(e.g. reducing the literal matches to those that are rdfs:labels).
Now I just need to update the veudastore code to use the new scheme...
This reduces the accuracy of the suffix match (meaning that substring searches > 4 chars need to join and filter with the nodes table (containing the literals). The width of the suffix field could be increased if this becomes a bottleneck, trading off more space for speed.
Have got the query down to 30ms on my laptop (down from 82.61 seconds on the original scheme). Other queries are looking good as well (mostly in the 10-30ms mark). Should fly on the 10GB 8 proc box at work :-)
The reason this is so much faster is that the mysql query optimiser gets a better view of the number of literals each substring will match, and so correctly identifies the best match order. Also, by indexing the new suffix table both ways (suffix-literal and literal-suffix), the query analyser can chose to impose other constraints in between substring filtering
(e.g. reducing the literal matches to those that are rdfs:labels).
Now I just need to update the veudastore code to use the new scheme...
