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 - Need to determine how to implement this. I imagine something similar to adding an External URL on the Mod Form where you can add a new entry and select a Mod (may also need a note property associated with this to include additional information)
• 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)

Is "section" in reference to mod or PDF section? I assume the former, so it should be ModSection"" in that case

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

Agree

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"

This would be STEP Section number ;)

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. 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.

Ok, so we will have a Property called Conflict. I know all of the examples out there are using naming like "Has Author" or "Is part of region", but I prefer to just keep the Propertry name simple as if it were a variable in any other language.

As for STEP, I honestly see no use for storing this semantically.

Mod Type is a label then, not a Property. It should be removed from the list. Stoppingby4now (talk) 09:05, 10 October 2012 (UTC)