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).
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.
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. This is information stored on each specific Mod page containing the list of mods that it overwrites. Overwrites is also the only piece of data we need to aid in determining Mod Install Order. For Overrides, I don't see the point of storing this information. Plugin order is already handled by BOSS, and quite frankly would consume far too much of our time to maintain.

Stoppingby4now (talk) 05:28, 11 October 2012 (UTC)

- Good points all. I have been working on a thought exercise after having read some info on SemanticForms. Take a look at the new Page.

~z929669

Talk 06:09, 11 October 2012 (UTC)

- Like the new layout and org notes. I just wonder why we are not using the conventional/recommended property nomenclature (e.g., "Mod created by" rather than "Author"). As I understand, this is done to remind users of the context of query results. My feeling is that the SMW gurus that recommend this methodology have insights that we do not, and I am inclined to trust them.

- What about Changelogs and recent changes? Since these are also mod properties, handling them as Record-Type Properties just makes sense to me.

~z929669

Talk 16:06, 11 October 2012 (UTC)

-For starters, their recommendation to name Properties to fit a natural query language is primarily with respect to article management where a wider user base will be maintaining those articles. That can be fine to use them in that case, but they also introduce problems requiring many variables to answer questions. As a small example, for Author, you would most likely have a "Has Author" Property to contain the name, and a "Is Author" Property of type boolean. Wiki authors would need to remember to set both on the appropriate pages concerning an Author. Secondly, we don't fit into the article management mold. We are using these to maintain records of data that are handled by forms, so the naming honestly doesn't matter from a user base perspective. For every example I find out there that uses a natural language naming style, I find one that uses a program variable naming style, and their use is typically in relation to what the data is being used for (article management or records of data to generate pages(. There is no hard and fast rule. We can have a group discussion on this if you like, but for our purposes, I'm not a fan.

-To expand on the above, I prefer to have template field names as concise as possible. As an example, we could keep the semantic Property ModFullName, but for the template we don't need to quality it as modFullName (I'm using camel case to distinguish between template and Semantic Properties btw), as it's already given that it's the Full Name of a Mod based on it's association with the Template:Mod.

-Changelogs/recent changes are already handled by the Updates structure as subpages. A query already exists to pull this information into the page, as well as provide a link to get the entire list. I had forgot to add the template that is being used to the list, but just added it. Stoppingby4now (talk) 19:38, 11 October 2012 (UTC)