Project talk:Data Dictionary

• Unique ID - Not needed, as the Wiki page is the Unique ID.
• Status - Not needed on the Wiki unless we wanted to implement bug tracking on the Wiki itself. Interesting to note that I have come across a really good example of using Semantic data and forms to do such a thing.
• Reason Rejected - Directly tied to use of Status above.
• Active - Not needed, as setting a section to "blank" effectively marks the mod as not active.
• Short Mod Name - Not needed, as the Wiki page name is the short mod name.
• Section ID - Already being used (current name is Section )
• Section Name - Already being used (current name is SectionDescription )
• Core - Already being used.
• Baseline - Already being used.
• Impact - Already being used.
• Notes - Need to add this, but we need to decide if we only need the notes for the current release, or if we want to retain notes for all releases. I vote for current release only so it can be implemented in the Mod Form (should be marked to be editable by administrators only).

BUILDER NOTES

• Nexus ID - Already being used, but needs to change (reference)
• Forum Thread ID - Already being used.
• Install Order - Implementation in the works.
• Conflicts - Now implemented in a bare-bones form, but not using the property yet. The property should name should be changed to Overwrites (needs to be finished)
• STEP - No idea what this is intended for.
• Mod Attributes - No idea what this is intended for.
• Nexus Link - Not needed, already determined by Nexus ID (implementation will change to account for multiple external sources).
• STEP Forum Link - Not needed, already determined by Forum Thread ID.
• Mod Name - Needs to be added, but should be changed to Full Mod Name.

Additional

• Mod Site Name - This or similar to identify the name of the primary site for downloading the Mod (primarily used for labels and/or link text).
• Mod Site ID - The ID of the Mod on the Mod Site Name.

Stoppingby4now (talk) 22:20, 8 October 2012 (UTC)

---

1. RE: Status - Is "section" in reference to mod or PDF section? I assume the former, so it should be ModSection"" in that case
2. RE: Section Name - That sounds like a great idea. I vote to track status in a "Semanticized" manner and teach our mod testers how to update ;) ... however, I see this datum as labels like "Accepted" "Denied", etc
3. RE: Notes - Agree
4. RE: Conflicts - I definitely see use for a property, [[Member of conflict group::X]] Conflict groups are mod groups that share overlapping/associated conflicts and who "wins"
5. RE: STEP - This would be STEP Section number ;)
6. RE: Mod Attributes - This is mod type and anything else mod specific ... we have this covered already

~z929669Talk 03:19, 9 October 2012 (UTC)

---

- In relation to "Section", mod section and PDF section are the same thing as a direct relation based on mod. This serves as a mapping specifically to section 2.X as it stands today. So as an example, Section=A is a direct mapping between the PDF (Section 2.A), and the Wiki (Category:Section_A). Semantically, it's the only section we care about, but it could be changed to ModSection to increase it's descriptiveness.

- Conflicts aren't a group. Each individual Mod will have a list of mods that they conflict with, to mean that they overwrite some portion of that Mod. In fact, this should be changed to Overwrites. You can then query to answer questions like: What mods does ModA Overwrite? What mods overwrite ModA? (example)

- As for over-arching STEP, I still don't see a use for storing this semantically.

- Mod Type appears to be a label, not a Property. It should be removed from the list.

Stoppingby4now (talk) 09:05, 10 October 2012 (UTC)