Project talk:Data Dictionary: Difference between revisions
From Step Mods | Change The Game
No edit summary |
No edit summary |
||
Line 34: | Line 34: | ||
:This is mod type and anything else mod specific ... we have this covered already ~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 03:19, 9 October 2012 (UTC) | :This is mod type and anything else mod specific ... we have this covered already ~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk: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. 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. | ::- 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. Example queries would then include: Get the listing of conflicts for a Mod (or Mods). Get a listing of Mods that conflict with a Mod (or Mods). | ||
::As for STEP, I | ::-As for over-arching STEP, I still don't see a use for storing this semantically. | ||
::Mod Type | ::-Mod Type appears to be a label, not a Property. It should be removed from the list. [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 09:05, 10 October 2012 (UTC) |
Revision as of 23:47, October 10, 2012
- 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 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. Example queries would then include: Get the listing of conflicts for a Mod (or Mods). Get a listing of Mods that conflict with a Mod (or Mods).
- -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)