Project talk:Data Dictionary

Mod Properties

• 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

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

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

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

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

~z929669Talk 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 (though they often mix styles), I find one that uses a program variable naming style. 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 qualify it as modFullName (I'm using first letter lower 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 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)

- I really think that we ought to prefix all or none of the "Mod Properties" with "Mod". It is currently inconsistent and irrelevant whether or not an attribute will be used elsewhere.

- Need to change "Notes" to "ModRecommendations"

~z929669Talk 14:56, October 16, 2012 (UTC)

- If you want consistency, then I have to say that "Mod" should be dropped. Some of those properties can be used for more than Mod information, and it makes no sense to duplicate Property names that would contain the same relevant information, just for different products.

- Same as above in terms of prefixing with "Mod". As for the name, "Notes" is more generic and can cover use in other "products", but changing is still fine. Just without "Mod".

STEP Guide Properties

• GuideReleaseMajor - Agree, not needed.
• GuideReleaseMinor - [Is minor release] Type=String (the name of the property dictates it as Type Boolean. I don't see how this gains us anything, can you give an example of what you expect to use it for.)
• GuideSection - Based on my previous comments, I don't see this as necessary. The blobs of text that are going to be placed in the Wiki can be identified by Category.
• GuideChangeLog - Prefer to manage this as sub-pages. Refer to Updates for individual Mods as a perfect example.
• GuideRecentChanges - How does this differ from a Change Log?
• GuideImage - Can you expand on what this is to be used for?

I think in some cases you are trying to force data into Semantic Properties when there is no need to. Particularly when you start trying to associate large amounts of data, Semantic Properties are just not efficient enough. There is a lot we can still accomplish with typical Wiki structure. Mod Updates is a perfect example of tying information together without needing to use Symantic Properties on a grand scale (Update date is being used, but only for the purpose of determining the latest update). In other words, don't think of this exercise as creating an application (I was stuck in that mindset in the beginning myself), as the application is already written (MediaWiki). We are just extending it in order to store data in a different way where it makes sense. Stoppingby4now (talk) 21:13, 11 October 2012 (UTC)

OK, we can table these ideas unless/untill it makes sense to revisit down the road. At least we have a data dictionary for reference and to build out if/when things do get more complex. Since we are adding Semantic associations here, it may be worth creating a table of categories we are using and plan to use as well as their purpose. This will be both instructive and constraining (in a good way).

~z929669Talk 23:11, 11 October 2012 (UTC)

-I agree to keep the current items on the page for reference. A few of those I just questioned their use as I'm not sure what you intended them for, but that doesn't mean they may not be useful. As for documenting Categories, I used the main header for Form:Mod to list what is being used, but then it is much simpler than what the PDF structure will be. Do we want to break information out into sub pages? Stoppingby4now (talk) 23:49, 11 October 2012 (UTC)

-I just thought of something that is a good example for Property use even when it's not needed. Technically we don't need ModSection as a Property, as a query constraint can be placed on the Section Category itself. But, it does provide something very useful in that the Property contains "Allows value" declarations which gives us the ability to have a dropdown that can only contain those values. Unfortunately the form still requires an update for the hints to the right of the input, but at least logic is kept to minimum, and forgetting to update the hints list won't prevent successful use of the form. Stoppingby4now (talk) 00:10, 12 October 2012 (UTC)

- You should know that many of my ideas are founded in intuition and instinct. I throw them out there into the blogoshere hoping that they will land somewhere useful or grow into something useful. Surprisingly, this works more than one might think :P

-Allows value is a case in point I suppose, as I can see how this feature would help in the field constraints department. SMW Inferencing has some interesting implications, and I am beginning to wonder if Properties are not almost always better substitutes for Categories, as the former has fewer restrictions. My question is ultimately "when to use a category in a SMW?"

~z929669Talk 04:10, 12 October 2012 (UTC)

- I hear you on intuition. I've learned to follow those gut feelings, and agree that while they don't always lead to the right way, it can cause those A-Ha moments (as I call them) that lead to potential solutions.

- I had read that page early on, and they make some good points. But the points are specific to a very large Wiki (Wikipedia) where Categories have become too lax, and the depth of information is so large that it just doesn't fit well into a tiered Category structure, thus losing useful association. I don't see Properties offering any greater control as long as the Categories have meaning and focus (which is the only time SMW provides any value). I highly doubt we'll ever have the problem that Wikipedia faces today. When to use Categories over Properties? When they share the same meaning, such as the proposed Guide Section Property. Consequently, Categories also have an edge on Properties in that you can navigate the Wiki via Categories. You can't via Properties. The only thing I've found that probably allows getting to data based on Properties is Semantic Drilldown, but it's also a whole different way of getting to the data you want. Some will like it, some won't. Cases can be made either way, I just feel that SMW shouldn't be treated as the holy grail. I'm basing my questions and doubts on proposed Properties, because I ask myself if MW can already handle the intended use. If it can, why not use what is already there instead of adding to the overhead? This extends to the better alternative for Overwrites over using subobjects. It has been stated that they suffer a performance cost, and in general you don't want more than 4 associated properties in an object. I have no idea what the extra overhead is like when you start having multiples of the same object on a page. I just play it safe by asking that key question. The closer you can implement a solution to core MW the better, I say. Stoppingby4now (talk) 07:20, 12 October 2012 (UTC)

- I can buy all of those arguments. Good practice: MW when it works and SMW when MW doesn't cut it. I also think that we should continue to make use of cats and subcats.

~z929669Talk 20:59, 12 October 2012 (UTC)

- Totally agree. We need to figure out what Categories make sense for Sections as far as naming. Would be nice to have the sections for Mod's fit in seamlessly.

Stoppingby4now (talk) 23:22, 12 October 2012 (UTC)