31 Aug 2007 18:34
Fwd: Exporting sql data to n3/rdf
I have updated http://wiki.thesoftworld.com/ConvertSRDTablesToN3 to discuss requirements a little more clearly.
On 8/29/07,
Stephen Thorne <stephen.thorne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
That's putting it mildly. No relations. Columns that require complex recursive-descent parsers to analyze. Typos and junk text everywhere.
I don't need to do it myself, but I want it to take into account the requirements of Goonmill.
To make Goonmill work at all, I had to write parsers for a number of columns in the SQL data, getting skills and special abilities out in a form that I could use as objects, since they have to be reformatted and may appear in other contexts in the statblocks.
I want to be sure that, for example, the "attack" column is actually parsed out into distinct attack objects. If you look at this column and then look at the output of Goonmill for, say, an erinyes; they are *quite* different because of all the work that went into attackparser.py and its 54-line BNF. The goal of transforming the SQL into RDF/N3 is not simply one of standardizing on a new data format; it's also critically important that the fairly opaque data originally found in the SRD be turned into something flexible and granular that apps can use without a ton of work for each and every attribute.
Having looked at the other tables, it seems that "monster" was the worst of the bunch. I think the others can be converted with relatively little work on parsers. Still, it must be asked of each and every column, whether this column is granular enough for an application to use after the conversion.
C
I've had a stab at exporting the rdf data in the srd35.db sqlite
database into n3. The data in that database is really shonky,
That's putting it mildly. No relations. Columns that require complex recursive-descent parsers to analyze. Typos and junk text everywhere.
but it seems to work. I have the code in the playtools repository and the
filename is playtools/rdfify.py
You end up with Skills that look like this beauty:
:sleightOfHand a :Skill;
a :TrainedSkill;
a :ArmorCheck;
rdfs:label """Sleight of Hand""";
:keyAbility c:dex;
.
Definitely on the right track here! The parser should probably extract all the columns from the tables. The goal is to get rid of the tables, so we don't have to go in later and pull out more data.
In order to accommodate games like d20 Modern, I'd also like to move most of the stuff created by the classes() function into characteristic.n3 or property.n3 so that we can host a schema of skills but not force people to take the skills themselves.
In order to accommodate games like d20 Modern, I'd also like to move most of the stuff created by the classes() function into characteristic.n3 or property.n3 so that we can host a schema of skills but not force people to take the skills themselves.
and while I've had a crack at monsters, cory has said that he wants to
do them himself, but mine come out looking somewhat like this (not all
the data is available yet):
:thoughtEater a :Monster;
p:family :thoughtEater;
rdfs:label """Thought Eater""";
p:size c:small;
a :Aberration;
:descriptor :psionic;
p:hitPoints """3d8""";
p:initiative 8;
p:armorClass [ a :ACGroup; :ac 17; :touch 15; flat 13 ];
.
I don't need to do it myself, but I want it to take into account the requirements of Goonmill.
To make Goonmill work at all, I had to write parsers for a number of columns in the SQL data, getting skills and special abilities out in a form that I could use as objects, since they have to be reformatted and may appear in other contexts in the statblocks.
I want to be sure that, for example, the "attack" column is actually parsed out into distinct attack objects. If you look at this column and then look at the output of Goonmill for, say, an erinyes; they are *quite* different because of all the work that went into attackparser.py and its 54-line BNF. The goal of transforming the SQL into RDF/N3 is not simply one of standardizing on a new data format; it's also critically important that the fairly opaque data originally found in the SRD be turned into something flexible and granular that apps can use without a ton of work for each and every attribute.
Having looked at the other tables, it seems that "monster" was the worst of the bunch. I think the others can be converted with relatively little work on parsers. Still, it must be asked of each and every column, whether this column is granular enough for an application to use after the conversion.
C
RSS Feed