Quick reply to Denny and Gerard:
@Denny: I think it makes sense to treat qualifiers under a closed-world
semantics. That is: what is not there can safely be assumed to be false.
In this I agree with Gerard. OTOH, I don't think it hurts very much to
add them anyway.
@Gerard: Please note that the use of novalue in qualifiers does not have
any negative effects on tools that rely on the value not being there. We
do not encode "novalue" as a special value, so tools that search for
some arbitrary value will never find novalues (on any level: statement,
qualifier, reference). So, overall, it is not such a big deal if people
add novalue qualifiers in some places. Only tool developers who create
own query services (not based on our RDF exports) must be aware that it
would not be a good idea to treat "novalue" like a value internally. But
that's a very small and rather competent group :-)
Anyway, even if we generally agree that "not stated" means "not true" on
the level of qualifiers, there could be cases where the explicit
"novalue" could be valuable as documentation for other human users.
Regards,
Markus
On 26.04.2015 00:52, Denny Vrandečić wrote:
Actually I think that having "no value" for the end date qualifier
probably means that it has not ended yet. There is no other way to
express whether this information is currently merely incomplete (i.e. it
has ended, but no one bothered to fill it in) or not (i.e. it has not
ended yet). This is pretty much the same use case as for normal claims.
Other qualifiers I could imagine where an explicit "no value" would make
sense is P678, I guess.
In references it might make sense to state explicitly that the source
does not have an issue number or an ISSN, etc., in order for example to
allow cleanup of references and to mark the cases where a reference does
not have a given value from those cases where it is merely incomplete.
I don't have superstrong arguments as you see (I would have much
stronger arguments for "unknown value"), but I would prefer not to
forbid "no value" in those cases explicitly, because it might be useful
and it is already there.
[1] https://www.wikidata.org/wiki/Special:WhatLinksHere/Q18615010
On Thu, Apr 23, 2015 at 1:27 PM, Stas Malyshev <smalys...@wikimedia.org
<mailto:smalys...@wikimedia.org>> wrote:
Hi!
I was lately looking into the use of novalue in wikidata, specifically
in qualifiers and references. While use of novalue in property values is
pretty clear for me, not sure it is as useful in qualifiers and refs.
Example:
https://www.wikidata.org/wiki/Q62#P6
As we can see, Edwin Mah Lee is the mayor of San Francisco, with end
date set to "novalue". I wonder how useful is this - most entries like
this just omit end date, and if we query this in SPARQL, for example, we
would do something like "FILTER NOT EXISTS (?statement q:P582
?enddate)". Inconsistently having novalues there makes it harder to
process both visually (instead of just looking for one having no end
date we need to look for either no end date or end date with specific
"novalue") and automatically. And in overwhelming majority of cases I
feel "novalue" and absence of value model exactly the same fact - it is
a current event, etc. Is there any useful case for using novalue there?
Another example: https://www.wikidata.org/wiki/Q2866#P569
Here we have reference with "stated in":"no value". I don't think I
understand what it means - not stated anywhere? How would we know to
make such claim? Is a lie? Why would we keep confirmed lies in the data?
Does not have confirmed source that we know of? Many things do, why
would we have "stated in" in this particular case?
Summarily, it is unclear for me that novalue in references is ever
useful.
To quantify this, we do not have a lot of such things: on the partial
dump I'm working with for WDQS (which contains at least half of the DB)
there are 14 novalue refs and 13 properties using novalue as qualifier,
leader being P582 with 200+ uses, and overall 422 uses. So volume-wise
it's not a big deal but I'd like to figure out what's the right thing to
do here and establish some guidelines.
Thanks,
--
Stas Malyshev
smalys...@wikimedia.org <mailto:smalys...@wikimedia.org>
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
