Product database
> I'm still not sure how to design the subobjects holding the individual variants. Actually I have not yet found an way to visualize the values of the record datatype as I would like
There are always different ways to accomplish things, in the given example I used to declare subobjects to represent a product variation that relates to a subject (lets called the super product).
In my understanding, products and each different variations of it would represent a different entity and are therefore distinguishable from the rest hence can be queried individually.
> However my question is different now. Have to be defined all properties of a subobject using the {{#subobject so1 |...}} tag or is there a way to add additional values later on?
Using #subobject to be declared within a wiki-page (== subject) and having {{#subobject:ABC declared on top of the page and later on within the same page you try the extend #subobject:ABC that is not possible because, SMW only sees a page in its entirety. (This not completely true for named subobjects but the would stretch this thread)
Further more, declaring a #subobject:ABC on Page A and declaring a #subobject:ABC and Page B are two totally different entities that can be linked to each other but do not represent the same thing (or knowledge, or data, or fact). Remember that we interpret a data by Subject A (== Page A) posses an object value (property value) described by an attribute (the property itself), so that it reads as "A has something of X value".
As named subobject, Page A + #subobject:ABC|has something of=Foo !== Page B + #subobject:ABC|has something of=Foo
As anonymous (or hashed) subobject, Page A + #subobject: |has something of=Foo !== Page B + #subobject: |has something of=Foo
> I tried adding second {{#subobject so1 |}}, but saving the page resulted in a critical error of MWException type.
I would be interested to see what sort of issue you encountered together with a stack trace.
PS: Don't try to build Rome in a day, finding the right data model may take some time but with more practice (just use the sandbox) things should get clearer.
- Build a simple product without variations, query its component and understand what can and cannot be done.
- Build the same simple product but this time using the #subobject and query it.
- ...
Thanks again for your detailed description and help. Exactly as you have suggested, I'm now researching what SMW can and what data model is best to use to solve my product catalogue. For that I'm using both SMW sandbox and my own sandbox installation. I think that defining product attributes is pretty clear for me now but I'm still not happy with the product variants. I try to make it as simple as possible, so I tend to use templates to add and display data.
I know that subobjects defined in different pages will create different entities even they have same name. Anyway I was interested, if it would be possible to add more information to subobject on the SAME PAGE using second, third etc. subobject with the same name. Exactly the same way I can add attributes using #set. I have just tried it on SMW sandbox and it seems to work :-) Maybe there is some improvement over SMW 2.3.1 I'm using.
Additionally I tried subproperty and it does not seem to work - please look at the demo [[1]]
Thanks!
