Project talk:Data Dictionary/Archive 1

Archived Page This page has been archived. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Any additions you make will probably not be read and may be undone without notice. The current version of this page can be found at: Project talk:Data Dictionary

LATEST STUFF

old stuff

[edit]

Updates

(most recent first)

DDSopt Properties

Applies only to texture mods. Propose that we include Section as a Mod Attribute to indicate the STEP Section to which a mod will belong if added. Only Section G will apply to the DDSopt Property set.

• IsOptimized - The textures are already optimized to the appropriate compression format or are necessarily uncompressed.

If IsOptimized is not true, then the following could also apply:

• OptSettings - This might hold the main variable settings suggested for ideal optimization. We could use several separate Properties or group as SubProperties (or possibly as a Record type). I am not sure what the variable settings should be, because that will depend on the definition of the standard settings and this Property could hold only the non-standard settings.
• OptExceptions - This could hold something similar to the previous, but it might also hold the specific texture paths that should be included in the DDSopt INI and how they should be treated there.
• ByteDiff - This would hold the byte diff from the log output.
• VramDiff - This would contain the resulting VRAM change of the pre/post optimized versions.

~z929669Talk 02:44, December 17, 2012 (UTC)

Section is already declared as a property under Template:Mod. The distinction between Mod and ModAttributes is that Mod is for basic info such as the mod's name, section, NexusID, etc. while ModAttributes is based around the ticket/performance data results and will be the kind of stuff that needs some amount of discussion/consensus before declaring.

All of those sub-properties will be great to have. The problematic one will be VramDiff since it will likely be different depending on the rig.

~FarloTalk 04:22, December 17, 2012 (UTC)

* Can you provide examples of data that is needed to store for a DDSOpt ini file. Since I haven't messed with one, I don't know what all is available or needed. Shouldn't be a need for records or subobjects though.

* What does ByteDiff provide you that makes it necessary?

* I don't see VramDiff as being needed either.

Stoppingby4now (talk) 08:37, December 17, 2012 (UTC)

---

Added reference to new Form:Mod Version and Template:Mod Version
Stoppingby4now (talk) 19:51, October 16, 2012 (UTC)

- Looks like Farlo created some more tables to hold our ideas about Form:ModTest, including the properties I set up as well as a couple of 'tentative' templates (thanks)

- Broke out elements of Template:ModTest into Template:PerformanceImpact. Reason being that this is an important multi-faceted variable to track in and of itself. I see this being the info that basically qualifes the Property, 'AffectsPerformance' (sub-properties using 'AffectsPerformance via Internal Objects). Still thinking about designing a simple way to roll up testing results (including performance data) with SystemSpecs into a single form if possible.

~z929669Talk 07:56, November 5, 2012 (UTC)

Associating SystemSpecs with the performance data shouldn't be too difficult. The form will grab the user's name and simply apply their SystemSpecs declarations to the report itself. Basically: "TestReport#34/CPUProperty" = "User:Farlo/CPUProperty". Thus we end up with the reports having a full set of specs themselves which means we don't have to include anything about the users while querying them and they will remain static even if the user updates their specs. ~FarloTalk 08:18, December 17, 2012 (UTC)

---

Need to not turn headings into wiki text, as this breaks "right-click to edit" functionality!

~z929669Talk 06:23, November 21, 2012 (UTC)

Editing the Data Dictionary page is pointless as it is all form based and uses queries to pull everything together. So right-click to edit really doesn't do you any good in this scenario.

Stoppingby4now (talk) 08:28, December 17, 2012 (UTC)

[edit]

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. You also lose the very useful ability to autocomplete based on already entered information.

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

Stoppingby4now (talk) 19:21, October 16, 2012 (UTC)

- OK, I then favor dropping the "Mod" prefix on all, as that adds specificity where generalities may be more useful (it also shortens things up a bit). As long as redundancies in your autocomplete fieds aren't an issue. This is just as good a solution, because the current inconsistency was just bugging me :P

~z929669Talk 20:25, October 16, 2012 (UTC)

- I'll update the main page, Property names, and templates in a few. Already changed "Note" to "Recommendations" on the main page, but I still need to change the Property and template.

Stoppingby4now (talk) 20:34, October 16, 2012 (UTC)

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)

Semantic Data Mappings (intro)

- Please define "sub-headings" as you reference them in the intro.
- Also confused about contexts of "new data structure" and "second-level heading".

Would you care to clarify or elaborate?
~z929669Talk 04:41, October 17, 2012 (UTC)

- Talk about weird. I was gong over the entire main page making updates, and actually just got done updating the intro to clarify things as I too felt it was lacking (made sense to me when I wrote it late at night haha). Then I come into the talk page and read this. :P Great minds think alike. If anything needs to be added or worded differently (have it), or something still isn't clear (let me know).

Stoppingby4now (talk) 10:28, October 17, 2012 (UTC)

- Thanks for cleaning out the confusing elements and adding the org directions for future build-out. This is really a great reference now for getting a grasp of the Semantic relationships and key data elements involved in this process ... I just love good documentation :D

~z929669Talk 15:54, October 17, 2012 (UTC)

- @s4n ... could you define "multiple-instance template" and the relationship of property, sub-properties and internal objects defined by Template:ModOrder?

~z929669Talk 03:45, October 23, 2012 (UTC)

A "multiple-instance template" just means that a template is intended to be callable multiple times within a page. This can be anything from applying formatting to text that would be too tedious to type out for each occurrence, or for maybe producing a list item on each call. In relation to Semantic Forms, a multiple-instance template allows for the mechanism of adding new entries in the Form (such as adding a new Gallery item in Form:Mod). In order to make the form aware of a multiple-instance template, the parameter "multiple" must be added to the form declaration for the given template. Example:

{{{for template:ModList|multiple}}}

This tells the form that the template ModList can exist multiple times in the page, and will add a button for creating another template call in the resulting page.

You can also use a multiple-instance template to feed multiple pieces of data that it returns to another template, which is what I'm doing in all of the Forms that exist currently. If you were to do this manually, it would look something like the following:

 {{ParentTemplate
 |parentfield={{ChildTemplate
 |childfield1=some data}}{{ChildTemplate
 |childfield1=some other data}}
 }}

This is how Form:STEP Version is setup. The field mods in ModOrder is defined to hold a template. The form declaration for ModList is then specified as "multiple" and told that its contents should be placed inside the field ModOrder[mod], which then produces a result similar to the example above when the form is saved.

As for the Internal Object, the first parameter needs to be a Property of type Page which points the object to the page. I labeled the other properties as sub properties as they are set in relation to the Internal Object. This allows querying on the object itself, and then asking for the properties that are associated with it. In terms of ModOrder, this is the only way to be able to query the object that contains say ModName=Skyrim_HD and be able to ask what the Version is, without that property being set on the Skyrim_HD page itself.

Stoppingby4now (talk) 07:15, October 23, 2012 (UTC)

Mod Testing Walkthrough

Assuming that mod testers will have a detailed guide as to how to set up their base system to prepare for mod testing (SIS should be specifically employed so that testers can save their current profiles and set up two additional profiles from scratch as we define then. This should be a strict protocol and prerequisite to begin official testing for STEP.

1. Load up the wiki SystemSpecs Form and system specs (including Skyrim DLC info).
2. Navigate to the mod source
3. Read through the documentation and skim through the associated forum until acquainted with the mod's current status from the perspectives of author and users.
4. Load up a new wiki Form instance in a new browser tab.
5. Enter the mod name and source information.
6. Download the mod and check any additional documentation within the package if any.
7. Check the documentation properties off as they apply (if the documentation property has internal-object sub-properties, can it be set to "auto tick" based upon whether or not all of the sub-property Booleans are ticked or not?)
8. Check the package structure and tick off whether or not it is BAIN compatible (testers will need to understand these criteria ... link to WBG section?), and repack if necessary and create a BCF.
9. Tick off whether or not the mod has scripts.
10. Tick off whether or not the mod has loose files (as opposed to BSA?).
12. Install mod into defined game base using Wrye bash
13. TBC ...