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)

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

- 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

- RE: Notes - Agree

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

- RE: STEP - This would be STEP Section number ;)

- RE: Mod Attributes - This is mod type and anything else mod specific ... we have this covered already

~z929669

Talk 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)

- RE Section/STEP - STEP Guide "Chapters" correspond to STEP 1, STEP 2, ... STEP n. Under each, we have Section #.A, Section #.B, ... Section #.X. Then we have Sub-Sections like #.X.#, etc. Given all of this, I do see value in semantic annotations for all, as I think that we still need to convey and encourage users to follow each step of the guide sequentially, and it will make interrelating portions of the guide more intuitive by adding those semantics ... this is where it seems intuitive to make use of subobjects (but I admit that this is pure intuition, as I do not yet realize the potential of subobject classification or even the other annotations for that matter!)

- RE Conflicts/Overwrites - respectfully disagree. Specifically "resource conflicts" imply overwrites, while "data conflicts" imply overrides. This is why it is helpful to provide info on install order and plugin order, hence "conflict groups". This allows the user to make educated decisions regarding customization --both in terms of installation and implementation.

- Do you (or anyone else) mind helping me flesh out the page according to these notes? We also need to be mindful of Thunderbolt data assets (@Fri .... hint, hint).

~z929669

Talk 05:24, 11 October 2012 (UTC)

- RE Sections - I have no problem with having the over-arching STEP's in the PDF. My point is that there is no benefit to having Sections available in the PDF as semantic data. The links in the guide will point to specific pages on the Wiki which can use Categories or sub-pages. There is nothing that needs access to this data that can't be accomplished via standard MW methods. In other words, you are talking about blobs of text, not records of data (with the Mod section being the exception).

- RE Conflicts - I respectfully disagree back :P So first off, you are talking about adding a new set of data here. In terms of Overwrites, it is definitely not a group, but a list of Mods that contain files that are overwritten by the Mod in question. This is data stored on each specific Mod page containing the list of mods that it overwrites. For overrides, I don't see the point of storing this information. This is handled by BOSS already, and quite frankly would consume far too much of our time to maintain. Stoppingby4now (talk) 05:28, 11 October 2012 (UTC)