I'm quite confused. Trying to get a list of Canadian provinces and territories, i.e. the first-level provinces. So I'm looking for a subclass of Q10864048 (first-level administrative country subdivision), related to Q16 (Canada). The subclass I'm looking for is of course Q11828004 (province of Canada), which is indeed a subclass of Q10864048.
So, let's query the subclasses of Q10864048. This does not yield Q11828004.
Strange. Wikidata says that Q11828004 is a subclass of Q10864048, but query.wikidata.org says it is not. At least, query.wikidata.org finds 264 other direct subclasses of Q10864048.
Checking the SQID tool: https://sqid.toolforge.org/#/view?id=Q11828004. Yes, Q11828004 is a subclass of Q10864048.
Checking the superclass: https://sqid.toolforge.org/#/view?id=Q10864048. "Direct subclasses: none". So the SQID says that Q11828004 is a direct subclass of Q10864048, but Q10864048 has no subclasses?
And, how can a class have 14 total subclasses, when it does not have any direct subclass?
This does not make sense. Three tools, all saying something different, the SQID tool even contradicting itself.
One possibility would be that the tools are operating on different versions, i.e. a different data dump. However, the claim Q11828004 P279 Q10864048 has been in the data since April 2017, so it should be present in all data dumps.
What am I missing?
Note: It seems that query.wikidata.org knows about the relation Q11828004 P279 Q2879, and Q2879 P279 Q10864048. But this still does not explain the differences mentioned above.
Related
I'd like to write a library that's a thin wrapper around some of the functionality in BTreeMap. I'd prefer not to tightly couple it to that particular data structure though. Strictly speaking, I only need a subset of its functionality, something along the lines of the NavigableMap interface in Java. I was hoping to find an analogous trait I could use. I seem to recall that at some point there were traits like Map and MutableMap in the standard library, but they seem to be absent now.
Is there a crate that defines these? Or will they eventually be re-added to std?
No, right now there's only Iterator. MutableMap and Map have been removed somewhere along the road to stabilization of std for Rust 1.0.
There have been various discussions about re-adding traits to std. See these discussions on Rust internals:
Traits that should be in std, but aren’t
or (less recent but more specifically on collections):
Collection Traits, Take 2
Bottom line: everybody wants some form of those traits in std but nobody wants to commit adding and supporting the wrong ones in the standard library until a clearer picture of what is ergonomic emerges.
I am trying to understand how one would choose whether to use a QAbstractListModel or a QObject with a QQmlListProperty.
Given that the QQmlListProperty handles the "roles" functionality that would have to be written using the QAbstractListModel, it seems like the less tedious route.
I can't tell if most people suggest using QAbstractListModel simply because it has been around longer or if it is the better choice for some reason.
Nor have I been able to find any discussion of the trade-offs between the two options. This question was brought up during a Qt Developer Days talk discussing QAbstractListModel, but the answer was along the lines of "that would also work".
A model implementation will generally be more efficient to work with a view. When you expose a "dumb list" to use a model, every time the model changes the whole view is reconstructed, whereas with a model only the changes are updated. If you have a lot of items there will be tangible performance overhead.
You could use a list for a model, and you could use a model for a list, but when you want optimal performance, you should use a list for a list, and a model for a model.
For data normalisation of standard tin can verbs, is it best to use verbs from the tincan registry https://registry.tincanapi.com/#home/verbs e.g.
completed http://activitystrea.ms/schema/1.0/complete
or to use the adl verbs like those defined:
in the 1.0 spec at https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md
this article http://tincanapi.com/2013/06/20/deep-dive-verb/
and listed at https://github.com/RusticiSoftware/tin-can-verbs/tree/master/verbs
e.g.
completed http://adlnet.gov/expapi/verbs/completed
I'm confused as to why those in the registry differ from every other example I can find. Is one of these out of date?
It really depends on which "profile" you want to target with your Statements. If you are trying to stick to e-learning practices that most closely resemble SCORM or some other standard then the ADL verbs may be most fitting. It is a very limited set, and really only the "voided" verb is provided for by the specification. The other verbs were related to those found in 0.9 and have become the de facto set, but aren't any more "standard" than any other URI. If you are targeting statements to be used in an Activity Streams way, specifically with a social application then you may want to stick with their set. Note that there are verbs in the Registry that are neither ADL coined or provided by the Activity Streams specification.
If you aren't targeting any specific profile (or existing profile) then you should use the terms that best capture the experiences which you are trying to record. And we ask that you either coin those terms at our Registry so that they are well formed and publicly available, or if you coin them under a different domain then at least get them catalogued in our Registry so others may find them. Registering a particular term in one or more registries will hopefully help keep the list of terms from exploding as people search for reusable items. This will ultimately make reporting tools more interoperable with different content providers.
is there a way to get the recursive superclass concepts of a concept from freebase? For example, i would call the topic "/games/game_publisher" a concept, and I would like to know if it has any superclasses (e.g., /organization/organization would make sense).
Many thanks!
Freebase Types (the equivalent of your "concept") don't have an inheritance structure. They do however have "included types". One key difference is that an included type only gets added to a topic by when it's main type does by convention of the web client (or other client), but after that it can be removed or re-added independently. For example, Deceased Person has Person as an included type and it's unlikely anyone would ever remove the latter, but Author also has Person as included type because that's the case for the overwhelming majority of authors, but for so-called "corporate authors" one would remove Person and add Organization.
So, the included types does carry some semantic information, but it's not as strong as a super/sub-class relationship.
I'm a (Py)Qt newbie, porting C# GUI code to Qt for a couple of days now. One question that I keep asking myself is why are QAbstractItemModel subclasses required to supply a parent() method, and why are they required to supply, in the resulting QModelIndex, the row of a child in the parent?
This requirement forces me to add another layer over my tree data (because I don't want to call indexOf(item) in parent(), it wouldn't be very efficient) that remembers row indexes.
I ask this because it's the first time I see a model based view require this. For example, NSOutlineViewDataSource in Cocoa doesn't require this.
Trolltech devs are smart people, so I'm sure there's a good reason for this, I just want to know what reason.
The quick answer is, "they thought it best at the time." The Qt developers are people just like you and me -- they aren't perfect and they do make mistakes. They have learned from that experience and the result is in the works in the form of Itemviews-NG.
In their own words from the link above:
Let’s just say that there is room for improvement, lots of room!
By providing a parent that contains a row and column index, they provide one possible way to implement trees and support navigation. They could just as easily have used a more obvious graph implementation.
The requirement is primarily to support trees. I couldn't tell you the reason, since I'm not a Qt dev... I only use the stuff. However, if you aren't doing trees, you could probably use one of the more-tuned model classes and not have to deal with the overhead of supplying a parent. I believe that both QAbstractListModel and QAbstractTableModel handle the parent portion themselves, leaving you free to just worry about the data you want.
For trees, I suspect that one of the reasons they need the parent is that they try to keep to only asking for the information they need to draw. Without knowing all of the items in a tree (if it wasn't expanded, for example), it becomes much harder to provide an absolute position of a given item in a tree.
As for the quandry of using indexOf(item) in the parent function, have you considered using QModelIndex's internalId or internalPointer? I'm assuming they are available in PyQt... they can be used by your model to track things about the index. You might be able to use that to shortcut the effort of finding the parent's index.