Meta-sector Data Exchange Structure

[robject]

Sector Metadata Exchange structure (SME?)

This is basically wrapper data for a SEC 2.0 file, containing meta-data that's important to a sector.

Regardless of the format (here I'm using XML), structure is important for data exchange.

Also important is intelligibility of course. Does it make sense? If you look at a structure 6 months from now and go "huh??" then it's a failure. If others look at your structure and wonder what you've been smoking, then it's a failure.

So, my current preference is here. The reason I use XML here is that most people speaks it. We can fight over interchange formats later, elsewhere. Internally there's no difference, and popular formats have readers and writers that operate directly on internal memory structures, so it's a non-issue as far as I'm concerned.

I'll insert comments.

All elements can take attribution attributes and/or sub-elements. For example:

• allegiance - e.g. "Zh". This makes sense with anything that can be "owned".
• lang - This is used to tag alternate names for things. Uses allegiance codes.
• author - e.g. "Joe Fugate, HIWG, CotI Cleanup Crew"
• source - e.g. "Atlas of the Imperium, Travellers' Digest #8, #9, #10, GEnie (corrected)"
• publisher - e.g. "GDW, DGP, HIWG"
• copyright - e.g. "Copyright 1977-2009 Far Future Enterprises"
• ref - URL, e.g. "http://traveller.my.org/archive/General/sectors/core.sec"
• milieu - i.e. M0, M1100, TNE, Rebellion, ? (there is a published list; I just need to find it)
• year - precise year (Imperial) for that data item. This may be distinct from the era of the file overall (which we also need to capture). E.G. "this route was known to exist in 1118" or "1248" even if the file is ostensibly 1105.

Some sources are de facto standards already; if you can assume these are comprehensible, then by all means assume them. Example: TTB, LBB4, AOTI, TD#8. Likewise publishers (GDW, DGP, HIWG, SJG).

[color=red]
Sector Metadata Exchange (SME?) informal proposal version 0.6
[/color]

[color=blue]
# There's lots of sector-related data that the old SEC 2.0 format 
# doesn't encode and we can't just derive.  Border information, 
# for example, and route information -- including routes which
# cross sector borders.  This is an attempt to represent those.
#
# This document starts out by defining allegiance codes... or, 
# more exactly, defining abbreviations for polities which we
# use in our data.  We have a core set of pre-defined codes,
# and by using the "base" attribute we can subclass them here.
# Standardizing other polities is beyond the scope of this document...
#
# But first, let's allow people to define a custom sector size/offset.
[/color]

<sector [color=red]minrow="1" mincol="1" maxrow="40" maxcol="32"[/color]>

<allegiances>
      <allegiance code="Se">Steaak'heafera</allegiance>
      <allegiance code="As">Aslan Heirate</allegiance>
      <allegiance code="KO" base="Kk">K'Kree Outpost</allegiance>
      <allegiance code="Sy" base="Im">Sylean Federation</allegiance>
      <allegiance code="IU" base="Im">Imperial, Ursa world</allegiance>  
      ...
</allegiances>

[color=red]
# If you're using less-known sources for your data, perhaps you'd like
# to define them to help us apply some context to your data:
[/color]
<sources>
   <source code="MTR4">My Traveller Resource #4</source>
   <source code="IMTU3">In My Traveller Universe #3</source>
</sources>

<borders>
   <border allegiance="Zh">
 0000 0100 0200 0300 0400 0500 0600 0700 0800 0900 1000 1100 1200 1300 1400
 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000
 3100 3200 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313
 3314 3315 3316 3317 3318 3218 3217 3117 3016 2916 2816 2716 2715 2714 2613 2612
 2512 2511 2510 2509 2408 2407 2406 2306 2205 2106 2006 1907 1807 1707 1606 1506
 1405 1305 1205 1106 1006 1007 0908 0808 0809 0710 0711 0712 0713 0714 0715 0716
 0616 0617 0518 0519 0520 0420 0321 0221 0220 0120 0019 0018 0017 0016 0015 0014
 0013 0012 0011 0010 0009 0008 0007 0006 0005 0004 0003 0002 0001 0000
   </border>
</borders>

[color=blue]
# As Joshua (of travellermap.com) has mentioned, 
# the old plaintext fixed-width SEC 2.0 isn't going
# away.  And this is a good place to reference it,
# either embedded (shown here) or as a reference
# to a .sec file.
#
# For the SEC 2.0 content type, we use one of:
#
#   * application/x-vnd.farfuture.net-traveller-sector-v2
#   * text/x-vnd.farfuture.net-traveller-sector-v2
#
# x- is temporary. Once we have a specification published 
# we can apply for a real Internet Media Type (i.e. drop #the x-). 
# If you have a published spec it's a rubber stamp to get "vnd." 
# types.
[/color]

<data type="application/x-vnd.farfuture.net-traveller-sector-v2">
Irkigkhan       0103 E470100-4    De Lo                   920 Im M V
Shana Ma        0104 E324610-5    Ni                      111 Im F V
Niizediju       0106 B850864-9 N  De Po                   924 Im F V M V
Azimuth         0202 B797300-7 N  Lo                      720 Im M V
</data>

[color=red]
#  Some boilerplate metadata.  Ring/Ray is from hex 0101 of the sector.
#  Maybe we need better tag names for x and y, as in sector offset 
#  (in the OTU, this means from Core).
[/color]

<sectorName>Alpha Crucis</sectorName>
<milieu>Second Survey</milieu>
<x>-1</x>
<y>0</y>
<ray>62864</ray>
<ring>10080</ring>

[color=blue]
# J. Greely's route data is handy, and lets us annotate every leg if we need to.
# I'm not sure how he handles crossing a sector border, so I added optional
# endpoint sector "x" and "y" offsets.
[/color]

<routes>
      <route type="trade">
        <start>0123</start>
        <end xOffset="-1" yOffset="0">3224</end>
      </route>
</routes>

[color=blue]
# Joshua suggested a nice flexible format, which 
# allows reference fields -- great for quoting your
# sources.
#
# While we're here, let's allow people to define their own
# subsector size.  And, if you really want more than 26
# subsectors in your sector, I guess you can use double
# letters, or numbers.
[/color]

<subsectors [color=red]rows="10" cols="8">
      <A>Detsiaiem</A>
      <B>Ienji</B>
      <C>Naianch</C>
      <D>Qiedrkia</D>
      <E>Pia</E>
      <F>Retan</F>
      <G>Dalesabandagh</G>
      <H>Zezhpae</H>
      <I>Antideluvia </I>
      <J>Alsas</J>
      <K>Taemerlyk</K>
      <L>Inverness</L>
      <M>Wulfek</M>
      <N>Cabala</N>
      <O>Jungleblut</O>
      <P>Mnemosyne</P>[/color]
</subsectors>

<world_reference>
   <ref name="Ansenz" hex="2425" source="SM">Traveller News Service</ref>
   <ref name="Antares" hex="2421" source="VV">Vilani Space: Then and Now</ref>
   <ref name="Depot" hex="2021" source="RS">Imperial Navy Depots</ref>
   <ref name="Githiaski" hex="2406" source="JTAS">Contact: The Githiaskio</ref>
   <ref name="Sabmiqys" hex="2117" source="WBH">Using World Data</ref>
</world_reference>
</sector>

 

[inexorabletash]

"Meta-sector" - this makes me think of regions larger than a sector. For example, I partition my site data into "charted space" and "zhodani core route" collections. These are effectively a <Sectors> tag around a bunch of <Sector> tags. Anyway... I'd suggest a different name. But I can't think of one offhand.


All elements should be able to take attribution attributes and/or sub-elements. So I would excise these from the examples, and just have a section on that in the specification document. FWIW, my site uses:

• Author - e.g. "Joe Fugate, HIWG, CotI Cleanup Crew"
• Source - e.g. "Atlas of the Imperium, Travellers' Digest #8, #9, #10, GEnie (corrected)"
• Publisher - e.g. "GDW, DGP, HIWG"
• Copyright - e.g. "Copyright 1977-2009 Far Future Enterprises"
• Ref - URL, e.g. "http://traveller.my.org/archive/General/sectors/core.sec"

I also include this, although it's questionable:

• Era - precise year (Imperial) that the data item. Note that this may be distinct from the era of the file overall (which we also need to capture). I'm iffy on this one, but I like to capture it as "this route was known to exist in 1118" or "1248" even if the file is ostensibly 1105.

Again, all of these fields are extra. They should be completely optional. If we want to feel brave about namespaces we could consider using Dublin Core Metadata or another standard, or just tagging them with meta:source, metaublisher and (later on as we evolve this standard) identify what namespace meta maps to.

Presentation should NOT be included. For example, Color and ShowLabel are inappropriate in a data file. Either these should be added using an extensibility mechanism by specific applications (e.g. travellermap:color="..." or

Please forgive my site for using UpperCase tags. There's no standard (see http://my.safaribooksonline.com/0321150406/ch06) but we should be consistent. My suggestions would be either hyphen-separated or mixedCase. (Also, be verbose, avoid abbreviations - these files will be primarily written and read by machines, rather than typed by hand, so make manual inspection easy. We're already saying that a 10x increase in markup-to-data is okay, let's not fall into the MathML trap.)


I would move the <meta> fields to the top level. Deeper nitpicks:

• <name> is fine, but we need to support multiple names. I allow any number of names, with the "preferred" name first, and a lang="" attribute (where lang is an allegiance code; I'm not going to go ISO-639 on y'all!). Note that some sectors have multiple names in the same language. I also use this to make the primary name for Ley "Ley Sector", but just "Ley" matches in searches. (But maybe I'm weird that way...)

Example:

                <Name Lang="va">Gvurrdon</Name>
                <Name Lang="zh">Briakqra'</Name>

• <alt> - this has no meaning to me. Is it supposed to be an alternate name?
• <coord> - the two-letter code isn't enough. I use explicit <X> <Y> tags.

Tangent: my philosophy of elements vs. attributes - you can only ever have one instance of an attribute and it can have no additional metadata about it. If you have data that matches that requirement, use an attribute since they're more concise. Otherwise use an element. For example, the x/y coordinates of a sector need no additional data (unless you want multiple coordinate systems...) so I'd make those attributes of the sector element itself.

However, in the spirit of saying "syntax, shmintax" and realizing we might switch to any of XML/JSON/YAML/YFML later on, let's play with the structure first then "try on" different formats.

I use X and Y offsets from Core as whole numbers (and I think Y is Coreward but I can never remember what I chose), but I don't particularly care since it's all just a transform away.

• <dos> - not sure anyone will consume this. This is not critical for proper interop with the file, so we should figure out who would read/write it and where to put it that makes sense. Is there a table of these? Does it represent the GEnie upload name? Is it just a unique ID for the sector? Do we end up with a list of these "reference IDs" for sectors?
• <milieu> - I'd prefer either explicit Imperial Year (e.g. 990, 1105, 1116) or milieu code (M1000, M0), but we might want to support both.
• <ring>/<ray> specify what coordinate of the sector exactly? Either this is redundant with coord or... ?

Routes:

• Greely's code indicates the outsector routes are not fully implemented, but what you have is similar to his plan and what I use.
• I also support "cheat" hexes (0000 - 3341) for outsector routes that extend only one hex beyond a sector.
• Again, we should not have color and other presentation artifacts. however, we may want to allow for a stylesheet mechanism to be embedded. (More specifically, a general embedding mechanism, and stylesheet interop can be defined later).
• I definitely want Allegiance and Type in there tho so my Imperial Xboat routes can be green.

Things you're missing that we need:

<Allegiances>
  <Allegiance Code="Se">Steaak'heafera</Allegiance>
  <Allegiance Code="As">Aslan Heirate</Allegiance>
  <Allegiance Code="KO" Base="Kk">K'Kree Outpost</Allegiance>
  <Allegiance Code="Sy" Base="Im">Sylean Federation</Allegiance>
  <Allegiance Code="IU" Base="Im">Imperial, Ursa world</Allegiance>  
  ...
</Allegiances>

The

Base=""

attribute accomodates sector files that call out cultural attributes within the primary allegiance. In particular, for the purposes of computing borders, I map these to the base Allegiance. (I believe I have special cases for Aslan clans and Julian Protectorate worlds.) I'm not married to the name.

No, allegiances can't be universal - the same codes get re-used across sectors.

BTW, for the SEC 2.0 content type, we should use one of these:

• application/x-vnd.farfuture.net-traveller-sector-v2
• text/x-vnd.farfuture.net-traveller-sector-v2

x- is temporary. Once we have a specification published we can apply for a real Internet Media Type (i.e. drop the x-). If you have a published spec it's a rubber stamp to get "vnd." types.

 

[BeRKA]

Very interesting. I hope You can agree on something, and I hope it also will fit in Hemdian's new Universe 2.0.

 

[Hemdian]

I've just realised something. One of the 'critisisms' of Universe1 was it was too highly tied to the OTU. Some people have even requested support for non-standard sector/subsector sizes. I haven't had a chance to test it yet but Universe2 does support this in theory. What that means is that a new SEC format should identify its coordinate structure somehow. The specter of non-standard UPP codes has also been raised but I think that should be rejected.

 

[Hemdian]

<name> is fine, but we need to support multiple names. I allow any number of names, with the "preferred" name first, and a lang="" attribute (where lang is an allegiance code; I'm not going to go ISO-639 on y'all!). Note that some sectors have multiple names in the same language. I also use this to make the primary name for Ley "Ley Sector", but just "Ley" matches in searches. (But maybe I'm weird that way...)

Example:

                <Name Lang="va">Gvurrdon</Name>
                <Name Lang="zh">Briakqra'</Name>

• <alt> - this has no meaning to me. Is it supposed to be an alternate name?
• <coord> - the two-letter code isn't enough. I use explicit <X> <Y> tags.

Language isn't the only reason for a sector to have a different name. There can be historical differences too. Some sectors of the 3I had different names under the ROM and before.

 

[aramis]

I'd suggest a

#! xxyy bounds line... for .sec files
the hash because most count it as a comment, the bang because it's posix for comment as directive.

for .sxml
<bounds><sx>99</sx><sy>99</sy><sz>0</sz></bounds>
<boundss><ssx>99</ssx><ssy>99</ssy><ssz>0</ssz></boundss>

 

[robject]

I'd suggest a

#! xxyy bounds line... for .sec files
the hash because most count it as a comment, the bang because it's posix for comment as directive.

for .sxml
<bounds><sx>99</sx><sy>99</sy><sz>0</sz></bounds>
<boundss><ssx>99</ssx><ssy>99</ssy><ssz>0</ssz></boundss>

Probably something like this for nonstandard map sizes.

 

[robject]

Is this bad form?

I realize this may be somewhat unusual, but I'm thinking of an alternate format for subsectors. I need XML experts to tell me why this is a bad idea.

Beyond that, I suggest that this could be a place for bounds information. For example, the attributes I've put in red text:

    <subsectors [color=red]rows="10" cols="8"[/color]>
      <A>Detsiaiem</A>
      <B>Ienji</B>
      <C>Naianch</C>
      <D>Qiedrkia</D>
      <E>Pia</E>
      <F>Retan</F>
      <G>Dalesabandagh</G>
      <H>Zezhpae</H>
      <I>Antideluvia </I>
      <J>Alsas</J>
      <K>Taemerlyk</K>
      <L>Inverness</L>
      <M>Wulfek</M>
      <N>Cabala</N>
      <O>Jungleblut</O>
      <P>Mnemosyne</P>
    </subsectors>

 

[Hemdian]

Okay. Then next we need to add something to the subsector tag to say where it is within the sector. Or is it enough to say that the index attribute is applied in order from left to right and then top down? I'm thinking adding coordinate attributes to the subsector tag is less ambiguous.

 

[Hemdian]

Re: the source attribute. It occurs to me that having a big long string is potentially error prone. More scope for typos. Should we start to compile a list of sources and assign recognisable mnemonics to them? For example I'm thinking that Traveller's Chronical 3 would be batter as "TC3", and so on.

 

[robject]

Re: the source attribute. It occurs to me that having a big long string is potentially error prone. More scope for typos. Should we start to compile a list of sources and assign recognisable mnemonics to them? For example I'm thinking that Traveller's Chronical 3 would be batter as "TC3", and so on.

We can do this in a manner similar to the way Allegiances are done. That could help, and we can postpone having to define codes "for all Traveller".

<sources>
   <source code="TC3">Traveller's Chronicle #3</source>
   <source code="TD1">Traveller's Digest #1</source>
   <source code="TTB">The Traveller Book</source>   
   <source code="LBB1">Classic Traveller, Book 1</source>
</sources>

On the other hand, these examples are pretty universally recognized by abbreviation, aren't they? Maybe we don't need the mechanism I proposed here after all... new sources would get non-standard codes and a text disambiguator.