3 ms·
("Occupations" -> "Writers") seem wrong why would you do this? same for ("Categories with more than 100 entries" -> "Writers"). This seems like trying to put
by skyde 4y ago
("Occupations" -> "Writers") seem wrong why would you do this?
same for ("Categories with more than 100 entries" -> "Writers").
This seems like trying to put tag on category entity instead of creating a tag hierarchy.
Those 2 should be stored using different relationship type mechanisms.
("categoryTag", <SourceTag>, <DestinationTag>)
ex: ("categoryTag", "Occupations", "Writers")
and
("parentTag",<tagName1>, <tagName2>)
ex: (("parentTag", "American writers" , "19th century American writers")
- xg15 4y agoIndeed. It's a bit like if a programming language was trying to represent base classes and meta classes using the same mechanism. My guess is that no one realized the need for "meta" categories when the system was implemented, so later the existing hierarchy was simply co-opted instead of implementing a new functionality for that use case. As long as the categories are only used by human editors and use is only within some small subcommunity, it can work quite well. The problem starts if you want to combine categories used by different communities or if you (or your program) lack the domain knowledge to understand which nodes represent "meta" categories. As another poster said, the better approach to use Wikipedia data for automated processing is using infoboxea or the explicitly machine-readable Wikidata repository. The category system looks machine-readable on first glance but really isn't.