@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix orcid: <https://orcid.org/> .
@prefix this: <http://purl.org/np/RAkT8hvQzHp7TcUpR132hwoK4_gPKDUSYntZoHXLWdCMI> .
@prefix sub: <http://purl.org/np/RAkT8hvQzHp7TcUpR132hwoK4_gPKDUSYntZoHXLWdCMI#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix pav: <http://purl.org/pav/> .
@prefix np: <http://www.nanopub.org/nschema#> .
@prefix doco: <http://purl.org/spar/doco/> .
@prefix c4o: <http://purl.org/spar/c4o/> .

sub:Head {
  this: np:hasAssertion sub:assertion;
    np:hasProvenance sub:provenance;
    np:hasPublicationInfo sub:pubinfo;
    a np:Nanopublication .
}

sub:assertion {
  sub:paragraph c4o:hasContent "When analyzing the number of microtasks gener- ated in each stage, the Verify stage seems to produce more tasks than the Find stage. This is a consequence of simplifying the difficulty of the microtasks in the Verify stage, where workers have to assess only one type of quality issue at the time. However, in practice, the number of microtasks generated in the Verify stage is not necessarily larger. For instance, in our experiments with LD experts and crowd workers, we ob- served that large portions of the triples are not anno- tated with quality issues in the Find stage. Since Algorithm 2 prunes triples with no quality issues (consistently with the definition of the Find-Fix-Verify pattern), the subset of triples crowdsourced in the Verify stage is considerably smaller than the original set, hence the number of microtasks to verify is reduced.";
    a doco:Paragraph .
}

sub:provenance {
  sub:assertion prov:hadPrimarySource <http://dx.doi.org/10.3233/SW-160239>;
    prov:wasAttributedTo orcid:0000-0003-0530-4305 .
}

sub:pubinfo {
  this: dcterms:created "2019-11-08T18:05:11+01:00"^^xsd:dateTime;
    pav:createdBy orcid:0000-0002-7114-6459 .
}