First Steps
Here's a few thoughts for how to structure things:
Classes
I'm inclined to use owl classes for only the most structural things: characters, worlds, equipment and so on. It would be possible to classify things such as agricultural worlds and so on by classes but I'm included to treat them more as instances of a concept hierarchy.
Oh yuk, that sounded too postmodern for comfort. I'll give a concrete example.
It's possible to include an owl class that describes an agricultural world: Atmosphere 4-9, Hydrographics 4-8, Population 5-7. At that point, a reasoner would classify anything that was an agricultural world with that class, even though it's not explicitly stated. In this case, a world description would have something along the lines of
Code:
<http://data.travellerrpg.com/atlas/sector/spinward/subsector/regina/system/regina/world/regina> a <http://data.travellerrpg.com/ontolgies/t5world.owl#AgriculturalWorld>
An alternative model is to have a set of resources (URLs) that are classifiers. They can then be added to a world description along the lines of
Code:
<http://data.travellerrpg.com/atlas/sector/spinward/subsector/regina/system/regina/world/regina> <http://data.travellerrpg.com/ontolgies/t5world.owl#worldClassifier> <http://data.travellerrpg.com/id/world/classfier/agricultural>
This alternative model is how SKOS
http://www.w3.org/2004/02/skos/ works, which is designed for things like taxonomies, thesaurii and the like. It's downside is that you don't get direct access to the reasoning available from using classes. However, it's readily extensible and allows referees to decide to ignore the letter of the rules.
Templates
The other possible use of classes is to do things like give a race to a character or a class to a ship. So you would end up with something like
Code:
<http://www.charavolant.org/traveller/player/Doug/characrer/Fred> a <http://data.travellerrpg.com/ontolgies/t5character.owl#Human>
or
Code:
<http://www.charvolant.org/traveller/ship/ClearAirTurbulence> a <http://data.travellerrpg.com/ontolgies/t5ship.owl#Scout>
I'm really not keen on this approach, because it tends to over-specify things. Eg. Humans have four limbs, except for Shorty over there who got his legs blown off in the war. Similarly, a long-lived ship will undergo numerous changes and may not fit the definition of, say, a Scout any more.
However, there needs to be some way of saying "this X is a Y" to which I want to add "except for the bits I say are different". To do this, I propose templates: descriptions of things that can be describe the general case, which can be overridden by an actual instance. Eg. Fred, above, is a copy of the standard human template, expressed as something like:
Code:
<http://www.charvolant.org/traveller/player/Doug/characrer/Fred> a <http://data.travellerrpg.com/ontolgies/t5.owl#sophontTemplate> <http://data.travellerrpg.com/sophont/Human>.
Deducable Stuff
Things like UPPs are constructs built from more basic information. They're for display, rather than information. I'd like to leave these things out, in the expectation that a half-way decent piece of software can build them on the fly.
URIs
Still working on this. The general pattern I want to follow is something like:
http://data.travellerrpg.com/<type>/<id>/<type>/<id> and so on, so type might be something like "sophont" and id might be something like "Human". A sequence of type/id pairs indicates some sort of containment (eg. sector - subsector - system - world).
I'm using
http://data.travellerrpg.com as an example, but it should be obvious that I expect to set up something, somewhere that will actually deliver data on request.
Some things are not really namable in URIs. For example, there may be multiple characters called Fred floating about the place. A source of unique IDs that can be used to identify a specific Fred will be needed.
Individual campaigns need their own URIs. For purely local stuff, stored on a referee's computer, they could be the "other" URI, the URN, with a structure like: urn:x-traveller:character:Fred but it would be helpful to set up some sort of way of allowing campaigns to set up their own information sources.
Ontology Structure
Ontologies import one another in a horribly tentacular way. There's no good reason for not modularising the ontology and general good practice makes an ontology inherit from an "upper ontology" that describes the more abstract parts of what's going on.
What I have in mind is something like:
Code:
v-- Worlds <-----\
RPG <-- Traveller <-- Characters <- Campaign
^-- Robots <-----/
^-- ...etc ...
So the top onotology just encodes things common to RPGs: the concept of a character (and an NPC), an attribute, a player, a games master, etc.
The Traveller ontology describes the top-level concepts of Traveller: chatacters, worlds, etc. and some specialisation of the RPG ontolgy (eg. the preferred term for a games master is "referee"). I don't know if this is possible, but the idea of this ontology is to describe the relationships between things and leave the detail to:
The Worlds, Characters, etc. ontologies describe those things in detail.
A campaign ontology is a home-brew ontology that describes anything that some bright spark wants to add.
Questions, Comments, Complaints?
Have at it!
Once this is relatively stable, I'll start documenting things.
arent <http://data.travellerrpg.com/atlas/sector/spinward/subsector/regina/system/regina/world/assiniboia>;
rbit 4^^xsd:int;
