@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix edu: <https://knobit.org/def/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://knobit.org/id/task/mm-metamodel/C3> a edu:Question ;
    rdfs:label "C3 (2 points)"@en ;
    dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
    schema:hasPart <https://knobit.org/id/register/metadata-management#MD-254>,
        <https://knobit.org/id/register/metadata-management#MD-255> ;
    schema:identifier "C3" ;
    schema:position 3 ;
    schema:text "What the sources can fill, 1 each. (a) MC-013 Warehouse object realises the same metadata as MC-004 Table (table) from the same source (MX-001): one class remains (MC-004, or MC-013 with MC-004 retired) with the other's name recorded as its alias, reported as two classes for one thing, and ML-006 points at the surviving class. MC-006 View, harvested by the same scan, is a different thing and stays: merging it too, or retiring both, loses this part. (b) ML-004 report uses column, which UC-001 needs, has no populating source: `populated_by` becomes MX-001 (report-view links from the BI repository) and MX-002 (view-column resolution from SQL parsing) - both, since a report reads views and only the view resolution reaches the columns. MX-001 alone earns 0.5. Retiring ML-004 as unpopulatable, or naming a source that is not in the stage 1 list, earns nothing; replacing it with two relationships (report uses view from MX-001, view reads column from MX-002) earns the point."@en .

edu:Question rdfs:label "Question"@en,
        "Küsimus"@et .

<https://knobit.org/id/register/metadata-management#MD-254> rdfs:label "mm-metamodel C3a: two classes for one table merged, the other name an alias"@en .

<https://knobit.org/id/register/metadata-management#MD-255> rdfs:label "mm-metamodel C3b: report-uses-column relationship given its populating sources"@en .