What implications would there be between these two structures?
Name = PROPERTY in the sub-CATEGORY of Woman in the CATEGORY of People
and
Name = sub-PROPERTY of the PROPERTY of Woman in the CATEGORY of People
I am particularly interested in how structuring my data now will affect how I am able to do searches later using Semantic Forms, inline queries, concepts and compound queries etc
SMW largely removes the need for categories. However, categories are still very useful for administrative purposes. As for me, I normally use a category for each page type that uses a unique form. In your case that would translate to a category for people (assuming you have a specific form for people). For querying, it will make no difference.
(Copied svick's answer which seems complete enough.)
While https://www.semantic-mediawiki.org/wiki/Help:Special_property_Subproperty_of states in reference to "Subproperty of":
...a query for pages with the property should also return pages that have the subproperty
...there does not seem to be any equivalent "Category of" for Semantic Mediawiki or Mediawiki, so you may not be able to do nested searches of categories (e.g., if "bread" is a "food" category, a page listed under "bread" won't be found by a "food" category search unless under "food" also).
I recall some extension allowing this (though it was expensive), but I can't find it now. Scribunto does allow pagesInCategory and using the DynamicPageList extension, our site defined a module for listed out (as opposed to searching) categories within a category: https://me-pedia.org/index.php?title=Module:CategoryList , but there unfortunately seems to be no built in way to search through categories.
Related
I'm currently working on a Publishing Bounded Context. The main players in this context are Product and Listing.
Product : can be listed in multiple marketplaces. One Product Many Listing.
Listing : can have many products because some marketplace support variation listing. One Listing Many Product.
Based on the above I have a Many-To-Many relationship between Listing and Product.
I created an aggregate for both. The Product aggregate which contains listings and the Listing Aggregate which contains products.
Is it acceptable to have Listing defined in both aggregates or should I define Listing once to be used in both aggregates?
First Listing would be within the product aggregate because the product AR has a factory method that enforces rules when creating Listing(such as avoid duplicate listing in same marketplace and ensure we have stock qty for listing)
Second Listing would be an aggregate root which can contains info from many Product needed at the moment of publishing. This way I can create method on Listing to map it to a schema definition provided by different marketplaces (such as Ebay and Amazon). Also I want to be able to persist Listing independently from Listings within the same Product.
Do the two aggregates have too much overlap with duplicate definitions ? Is this to be expected within one bounded context?
Also how can I keep the duplicate representation of Listing synchronize with each other?
First Listing would be within the product aggregate because the product AR has a factory method that enforces rules when creating Listing(such as avoid duplicate listing in same marketplace and ensure we have stock qty for listing)
Should a product know its own stock, its own marketplaces, its own listings and create listings too? This is too much responsibility for an entity! I would suggest to let a ListingFactory check the stock and the marketplces with other services or repositories that hold this information.
Is it acceptable to have Listing defined in both aggregates or should I define Listing once to be used in both aggregates? Also how can I keep the duplicate representation of Listing synchronize with each other?
Avoid cyclic dependency between Product and Listing and a mess by maintaining a single list (have a look at this question for a similar tangle: How to design many-to-many relationships on deletion?). Seems to me you should have an aggregate of marketplaces, which contains your listings. You could setup a marketplace service or repository that gets all Listings if you need to access all listings based on a product (like in the ListingFactory I proposed).
Do the two aggregates have too much overlap with duplicate definitions ?
Your definition of product "can be listed in multiple marketplaces" is not a very satisfying definition, because after reading this definition the question still remains: What is it then that can be listed? At its core a product can be defined without knowledge of listings, but within this context it probably would still be better to explicitly name the relationship. Since a (product) listing can not be defined without a product, but a product can be defined without a listing. They need not be duplicates. I would expect your product to be completely listing-unaware, but related to listings within the context.
Is this to be expected within one bounded context?
All definitions build on each other, so within any context you can expect overlap, duplication, synonyms, extensions, near similarity, cross-referencing, different types of relationships, etc. It requires quite a bit of investigatory consciousness to separate the primary from the secondary, the predicates from the subjects and objects, the nucleus from the membrane. However, this is also what makes it so much fun :)
definition of word: "A single distinct meaningful element of speech or writing, used with others (or sometimes alone) to form a sentence.."
definition of sentence: "A set of words that is complete in itself, typically containing a subject and predicate, conveying a statement, question, exclamation.."
I am searching for a guideline on how to set up my database for a auction side.
My problem is, that there is a lot of different product types - let's say paintings, clothes, computers etc. They have different specifications, and it should be possible to set just Product A in size L on auction - or the whole stock of Product B e.g.
How should I build my database for optimal performance - and coding - in this case?
I would suggest the following database/object structure:
[Auction] n..1 [Category] 1..n [Variation Attribute] 1..n [Attribute Value]
An auction then has a category and several attribute values referring the variation attribute as well:
[Auction] = [Category], [Name], [Description]
[Auction_AttrVal] = [AuctionID], [VarAttrID], [AttrValID]
First of all you can have some kind of category table, which holds items like "Paintings", "Clothes", "Computers". An auction / product is assigned to one category.
Each category then defines variation attributes for this specific category. An example would be "Size" for the category "Clothes" or "CPU" for the category "Computers". You can also add predefined values for the variation attributes to limit the number of variations and avoid differentiations like "3GhZ" vs "3 GhZ".
This mechanism also allows for easy filtering of search results. You select a category and simply load all variation attributes as filters (or add a flag to an attribute to declare it as such) and offer the values for filtering to the end-user.
Furthermore you can make variation attributes for a category mandatory to force users who create the auctions (I'm assuming it's Consumer-to-Consumer) to provide sufficient information for their auction.
The code will probably be quite generic and simple. The database structure is highly flexible and extensible. Performance is much better than having all in one table. You probably should create an index (for the field AuctionID) for the Auction_AttrVal table. Please let me know if the database structure is not explained properly.
I've inherited a site with a very big hierarchical taxonomy:
Vocabulary name: categories
--term: company name
---- many child terms
-- term: country
---- many child terms
-- term: issue
---- many child terms
I realized it would be easier to create Search facets and Views with appropriate content if I set up each of these parent terms as their own Vocabularies:
company
country
issue
So I created the new Vocabularies and used Taxonomy Manager to shift all the sub-terms to their new vocabularies. I then updated the Article node content type to be associated with these 3 vocabularies.
Unfortunately I also noticed the term relationship between the Article nodes (all 4,000 of them) and the Terms was now lost in the display. I thought this relationship would have been maintained by the Taxonomy Manager module.
I've been searching for a way to update the vocabulary references for the Article nodes, but I'm still not sure how the vocabulary is associated with the node. I see new field_data_field_vocabulary-machine-name tables are created for each new vocabulary - and this is where the termID and node/entity ID are associated. However I don't know how to update the Vocabulary for a node automatically when I move a term from one vocabulary to another.
I've recently move this site from Drupal 6 to 7 so it doesn't help that there are a lot of dead tables from D6 cluttering up the database.
--
I've now set up a new standard D7 install and am looking at the db default tables trying to figure out where the Vocabulary/Node relationship gets defined. On my old db the TermIDs still seem to be correctly associated with the Nodes in the Node table... but I don't see where the VocabularyID/TermID/NodeIDs are stored/updated.
Please try this module: http://drupal.org/project/taxonomy_manager
This module provides a powerful interface for managing taxonomies. A vocabulary gets displayed in a dynamic tree view, where parent terms can be expanded to list their nested child terms or can be collapsed.
The Taxonomy Manager has following operations and key features:
dynamic treeview
mass deleting
mass adding of new terms
moving of terms in hierarchies
merging of terms (using the Term merge module in 7.x)
fast weight changing with up and down arrows (and AJAX saving)
AJAX powered term editing form
simple search interface
CSV Export of terms
i18n support for multilingual vocabularies (per language terms)
Double Tree interface for moving terms in hierarchies, adding new translations and switching terms between different vocabularies
For using the Taxonomy Manager you should have JavaScript and automatically load of images enabled in your browser.
-> but I'm still not sure how the vocabulary is associated with the node
In Drupal 7 taxonomy references are done very differently than they were in Drupal 6. If you want to associate a vocabulary with a node in Drupal 7, you have to add that term as a field on the content type:
Go to admin/structure/types/manage/article/fields where you can add/delete/modify fields for your article content type
Add a new field, name it whatever you'd like, and make sure you choose type 'Term reference' from the drop-down
Make sure you choose the correct vocabulary for it to pull from
Repeat this step (add two more fields) for the remaining two vocabularies.
Go to admin/structure/types/manage/article/display and modify whether you want these new fields to be displayed on the node or to be hidden
=============== Addition ==================
In Drupal 7, since terms are just like any other field, you'll see the relationship in the DB (of course -- only once you add the appropriate term reference field to your content type) in a newly created table that stores the information about that field. For example, it may be called field_data_field_tags for the standard 'tags' vocabulary that comes with Drupal 7 by default. In that table you'll see the columns entity_id (that's the node's id) and field_tags_id (that's the term's id), but that column may have a different name for your specific term. So you would have three separate tables for each of your terms' relationships to your node, since they would be three separate fields in Drupal 7.
Does that help a little more?
I think you should :
Create new vocabularies
Add fields with term reference to new vocabularies
After you connect content type with new vocabularies, then you
should move terms to new locations
I tested and it works for me with this order.
So, it may be best to just try it out and see through some trial and error, but I'm trying to figure out the best way to migrate a pretty simple structure from mysql to mongodb. Let's say that I have a main table in mysql called 'articles' and I have two other tables, one called 'categories' and the other 'category_linkage'. The categories all have an ID and a name. The articles all have an ID and other data. The linkage table relates articles to categories, so that you can have unlimited categories related to each article.
From a MongoDB approach, would it make sense to just store the article data and category ID's that belong to that article in the same collection, thus having just 2 data collections (one for the articles and one for the categories)? My thinking is that to add/remove categories from an article, you would just update($pull/$push) on that particular article document, no?
In my opinion, a good model would look like this:
{"article_name": "name",
"category": ["category1_name", "category2_name", ...],
"other_data": "other data value"
}
So, to embed the category names directly to the article document. Updating article categories is easy, but removing a category altogether requires modifying all articles belonging to the category. If removing categories is frequent, then keeping them separate might be a good idea performance-wise.
This approach makes it also easy to make queries on the category name (no need to map name to id with a separate query).
Thus, the "correct" way to model the data depends on the assumed use case, as is typically the case with mongodb and other nosql databases.
If you have access to a Mac computer, you could give the MongoHub GUI a try. It has an "Import from MySQL" feature.
I need to create 2 more tables with purpose: one table will store tags and categories data (categories can have a hierarchy but tags are not) and another table store relationship between tag, category and content. But I so confused about name of those 2 tables. I'm really a newbie in web development. After googling a bit, I found some words like term, taxonomy terms and vocabulary from drupal and wordpress. But I have no idea what they mean. Can you explain those words and help me give a name for my two tables. Of course if those tables are not well design for my purpose please guide me too.
content{
content_id
...
}
table_A{
type (tag, category, ...)
name
parent_id
}
table_B{
table_A_id
content_id
}
With relevance to wordpress, those words are indeed confusing. If you are using wordpress to build a site, you shouldn't need to worry about the database tables for storing taxonomies and terms as it has built in methods to handle all that.
You'll notice when you're in the wordpress admin panel editing a page or post that there is by default a box on the right which calls itself "Categories" and allows you to create new categories. Once one is created, you can add your posts or pages to any "Categories" you've created. I'm sure you understand that already.
As wordpress releases were built, people started asking for more customizing control over categorizing their content. So developers added "custom taxonomies" to wordpress. For clarity, I should mention that "Categories" is the name of a default "Taxonomy" built into wordpress.
A taxonomy is a group of terms. So when you create a "Category" in the right hand box of the admin panel (say "news" for example), you are creating a "term" named "news" which belongs to the "Categories" taxonomy.
This allows a developer to define their own taxonomy (let's say "products") and associate it with pages, posts or any other "post type". So if it's associated with just plain regular "posts" in the admin panel. A box exactly like the existing "categories" box would show up upoon editing but would call itself "products" instead. Anything added to that list would be a term under the "products" taxonomy.
Hope this clarifies things a bit for using wordpress. These terms can be used differently in different contexts so nothing I've said necessarily applies to anything outside of the wordpress package. Unfortunately there is often no universal "web development" meaning for a given word you may see thrown around in discussion.
Taxonomy, last time ago, means categorize life organisms. Similarly, in computer engineering, taxonomy means categorize terms, can be substantive(three, car, cat), verbs(go, be, do). Taxonomy and terms can be mens anything, but the concept is a data structure and hierarchy