discontinued / server · Files

index.html 223 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head> 
    <title>The PROV Data Model and Abstract Syntax Notation</title> 
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
    <!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
<!-- PM -->
    <style type="text/css">
      .note { font-size:small; margin-left:50px }
     </style>

     
    <script src="toggles.js" type="text/javascript"></script>  

     
  <style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  1px dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID, .idlDictionaryID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType, .idlMemberType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName, .idlMemberName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a, .idlMemberName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code, .dictionary-members dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
    }
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

/* --- EDITORIAL NOTES --- */
.pending {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #BFEFFF;
}

.pending::before {
    content:    "Pending Review";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}


.resolved {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #9BCD9B;
}

.resolved::before {
    content:    "Resolved";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}


.inference {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #fff;
}

.inference::before {
    content:    "Inference";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.unamedconstraint {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #00f;
    background: #fff;
}


.unamedconstraint::before {
    content:    "Constraint";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #00f;
    background: #fff;
    padding:    3px 1em;
}



.constraint {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #00f;
    background: #fff;
}

.constraint[id]::before {
    content:    "Constraint: " attr(id);
    width:  380px;  /* How can we compute the length of "Constraint: " attr(id) */
}


.constraint::before {
    content:    "Constraint";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #00f;
    background: #fff;
    padding:    3px 1em;
}



.interpretation {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #00f;
    background: #fff;
}

.interpretation[id]::before {
    content:    "Interpretation: " attr(id);
    width:  380px;  /* How can we compute the length of "Interpretation: " attr(id) */
}


.interpretation::before {
    content:    "Interpretation";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #00f;
    background: #fff;
    padding:    3px 1em;
}


.deprecatedconstraint {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #00f;
    background: #fff;
}

.deprecatedconstraint[id]::before {
    content:    "Deprecated: " attr(id);
    width:  380px;  /* How can we compute the length of "Deprecatedconstraint: " attr(id) */
}


.deprecatedconstraint::before {
    content:    "Deprecated";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #00f;
    background: #fff;
    padding:    3px 1em;
}



.conditional {
    color: blue;
}

.grammar {
    margin-top: 1ex;
    margin-bottom: 1ex;
    padding-left: 1ex;
    padding-right: 1ex;
    padding-top: 1ex;
    padding-bottom: 0.6ex;
    border: 1px dashed #2f6fab;
}
.nonterminal {
    font-weight: bold;
    font-family: sans-serif;
    font-size: 95%;
}

.name {
    font-family: monospace;
}


.xmpl {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #fff;
}

.xmpl::before {
    content:    "Example";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.anexample:before {
    content: "Example:";
    font-family: sans-serif;
    font-size: 1.6ex;
    font-weight: bold;
}
.anexample {
    margin-top: 1ex;
    margin-bottom: 1ex;
    padding-left: 1ex;
    padding-right: 1ex;
    padding-top: 1ex;
    padding-bottom: 0.6ex;
    border: 1px dashed #2f6fab;
    background-color: #f9f9f9;
}
.anexample table {
    background-color: #f9f9f9;
}

div[class="grammar"] span[class="name"]:before {
    content: "'";
}

div[class="grammar"] span[class="name"]:after {
    content: "'";
}


div[class="grammar"] span[class="optional"]:before {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: "(";
}

div[class="grammar"] span[class="optional"]:after {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: ")?";
}


div[class="grammar"] span[class="plus"]:before {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: "(";
}

div[class="grammar"] span[class="plus"]:after {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: ")+";
}


div[class="grammar"] span[class="star"]:before {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: "(";
}

div[class="grammar"] span[class="star"]:after {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: ")*";
}

div[class="grammar"] span[class="group"]:before {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: "(";
}

div[class="grammar"] span[class="group"]:after {
    font-weight: normal;
    font-size:130%;
    font-family: monospace;
    content: ")";
}

</style><link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head> 
  <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">The PROV Data Model and Abstract Syntax Notation</h1><h2 id="w3c-working-draft-15-december-2011"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 15 December 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215/">http://www.w3.org/TR/2011/WD-prov-dm-20111215/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html">http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111018/">http://www.w3.org/TR/2011/WD-prov-dm-20111018/</a></dd><dt>Editors:</dt><dd><a href="http://www.ecs.soton.ac.uk/~lavm/">Luc Moreau</a>, University of Southampton</dd>
<dd><a href="http://www.cs.ncl.ac.uk/people/Paolo.Missier">Paolo Missier</a>, Newcastle University</dd>
<dt>Contributors:</dt><dd><a href="http://semanticweb.org/wiki/Khalid_Belhajjame">Khalid Belhajjame</a>, University of Manchester</dd>
<dd><span>Stephen Cresswell</span>, legislation.gov.uk</dd>
<dd><a href="http://www.isi.edu/~gil/">Yolanda Gil</a>, Invited Expert</dd>
<dd><span>Ryan Golden</span>, Oracle Corporation</dd>
<dd><a href="http://www.few.vu.nl/~pgroth/">Paul Groth</a>, VU University of Amsterdam</dd>
<dd><span>Graham Klyne</span>, University of Oxford</dd>
<dd><a href="http://tw.rpi.edu/web/person/JamesMcCusker">Jim McCusker</a>, Rensselaer Polytechnic Institute</dd>
<dd><a href="http://www.inf.kcl.ac.uk/staff/simonm/">Simon Miles</a>, Invited Expert</dd>
<dd><a href="http://www.rpi.edu/research/ccni/">James Myers</a>, Rensselaer Polytechnic Institute</dd>
<dd><a href="http://cci.case.edu/cci/index.php/Satya_Sahoo">Satya Sahoo</a>, Case Western Reserve University</dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div> 

    <div id="abstract" class="introductory section"><h2>Abstract</h2>
<p>
PROV-DM is a data model for provenance for building
representations of the entities, people and activities involved in
producing a piece of data or thing in the world. PROV-DM is
domain-agnotisc, but with well-defined extensibility points allowing
further domain-specific and application-specific extensions to be
defined.  It is accompanied by PROV-ASN, a technology-independent
abstract syntax notation, which allows serializations of PROV-DM
instances to be created for human consumption, which facilitates its
mapping to concrete syntax, and which is used as the basis for a
formal semantics.
</p>
    </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>

This document is part of a set of specifications aiming to define the various aspects that are necessary to achieve the vision of inter-operable interchange of provenance information in heterogeneous environments such as the Web.   This document defines  the PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption. Three other documents are: 1) a normative serialization of PROV-DM in RDF, specified by means of a mapping to the OWL2 Web Ontology Language; 2)
the mechanisms for accessing and querying provenance; 3) a primer for the provenance data model.
<p>This document was published by the <a href="http://www.w3.org/2011/prov/">Provenance Working Group</a> as a Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-prov-wg@w3.org">public-prov-wg@w3.org</a> (<a href="mailto:public-prov-wg-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-prov-wg/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/46974/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction<br>
</a><ul class="toc"><li class="tocline"><a href="#structure-of-this-document" class="tocxref"><span class="secno">1.1 </span>Structure of this Document</a></li><li class="tocline"><a href="#prov-dm-namespace" class="tocxref"><span class="secno">1.2 </span>PROV-DM Namespace</a></li><li class="tocline"><a href="#conventions" class="tocxref"><span class="secno">1.3 </span>Conventions</a></li></ul></li><li class="tocline"><a href="#preliminaries" class="tocxref"><span class="secno">2. </span>Preliminaries</a><ul class="toc"><li class="tocline"><a href="#conceptualization" class="tocxref"><span class="secno">2.1 </span>A Conceptualization of the World</a><ul class="toc"><li class="tocline"><a href="#section-entity-activity-agent" class="tocxref"><span class="secno">2.1.1 </span>Entity, Activity, Agent</a></li><li class="tocline"><a href="#section-time-event" class="tocxref"><span class="secno">2.1.2 </span>Time and Event</a><ul class="toc"><li class="tocline"><a href="#types-of-events" class="tocxref"><span class="secno">2.1.2.1 </span>Types of Events</a></li><li class="tocline"><a href="#event-ordering" class="tocxref"><span class="secno">2.1.2.2 </span>Event Ordering</a></li></ul></li></ul></li><li class="tocline"><a href="#prov-asn--the-provenance-abstract-syntax-notation" class="tocxref"><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</a></li><li class="tocline"><a href="#representation--assertion--and-inference" class="tocxref"><span class="secno">2.3 </span>Representation, Assertion, and Inference</a></li><li class="tocline"><a href="#grammar-notation" class="tocxref"><span class="secno">2.4 </span>Grammar Notation</a></li></ul></li><li class="tocline"><a href="#prov-dm-overview" class="tocxref"><span class="secno">3. </span>PROV-DM: An Overview </a></li><li class="tocline"><a href="#prov-dm-example" class="tocxref"><span class="secno">4. </span>Example</a><ul class="toc"><li class="tocline"><a href="#a-file-scenario" class="tocxref"><span class="secno">4.1 </span>A File Scenario</a></li><li class="tocline"><a href="#example-prov-asn-encoding" class="tocxref"><span class="secno">4.2 </span>Encoding using PROV-ASN</a></li><li class="tocline"><a href="#graphical-illustration" class="tocxref"><span class="secno">4.3 </span>Graphical Illustration</a></li></ul></li><li class="tocline"><a href="#data-model-concepts" class="tocxref"><span class="secno">5. </span>PROV-DM Core</a><ul class="toc"><li class="tocline"><a href="#PROV-DM-record" class="tocxref"><span class="secno">5.1 </span>Record</a></li><li class="tocline"><a href="#record-element" class="tocxref"><span class="secno">5.2 </span>Element</a><ul class="toc"><li class="tocline"><a href="#record-Entity" class="tocxref"><span class="secno">5.2.1 </span>Entity Record</a></li><li class="tocline"><a href="#record-Activity" class="tocxref"><span class="secno">5.2.2 </span>Activity Record</a></li><li class="tocline"><a href="#record-Agent" class="tocxref"><span class="secno">5.2.3 </span>Agent Record</a></li><li class="tocline"><a href="#record-note" class="tocxref"><span class="secno">5.2.4 </span>Note Record</a></li></ul></li><li class="tocline"><a href="#record-relation" class="tocxref"><span class="secno">5.3 </span>Relation</a><ul class="toc"><li class="tocline"><a href="#activity-entity-relation" class="tocxref"><span class="secno">5.3.1 </span>Activity-Entity Relation</a><ul class="toc"><li class="tocline"><a href="#record-Generation" class="tocxref"><span class="secno">5.3.1.1 </span>Generation Record</a></li><li class="tocline"><a href="#record-Usage" class="tocxref"><span class="secno">5.3.1.2 </span>Usage Record</a></li></ul></li><li class="tocline"><a href="#activity-agent-relation" class="tocxref"><span class="secno">5.3.2 </span>Activity-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-ActivityAssociation" class="tocxref"><span class="secno">5.3.2.1 </span>Activity Association Record</a></li><li class="tocline"><a href="#record-Start-End" class="tocxref"><span class="secno">5.3.2.2 </span>Start and End Records</a></li></ul></li><li class="tocline"><a href="#entity-entity-agent-agent-relation" class="tocxref"><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</a><ul class="toc"><li class="tocline"><a href="#record-responsibility" class="tocxref"><span class="secno">5.3.3.1 </span>Responsibility Record</a></li><li class="tocline"><a href="#Derivation-Relation" class="tocxref"><span class="secno">5.3.3.2 </span>Derivation Record</a></li><li class="tocline"><a href="#record-complement-of" class="tocxref"><span class="secno">5.3.3.3 </span>Complementarity Record</a></li></ul></li><li class="tocline"><a href="#record-annotation" class="tocxref"><span class="secno">5.3.4 </span>Annotation Record</a></li></ul></li><li class="tocline"><a href="#bundle" class="tocxref"><span class="secno">5.4 </span>Bundle</a><ul class="toc"><li class="tocline"><a href="#record-Account" class="tocxref"><span class="secno">5.4.1 </span>Account Record</a></li><li class="tocline"><a href="#RecordContainer" class="tocxref"><span class="secno">5.4.2 </span>Record Container</a></li></ul></li><li class="tocline"><a href="#sub-record" class="tocxref"><span class="secno">5.5 </span>Further Terms in Records</a><ul class="toc"><li class="tocline"><a href="#record-attribute" class="tocxref"><span class="secno">5.5.1 </span>Attribute</a></li><li class="tocline"><a href="#record-identifier" class="tocxref"><span class="secno">5.5.2 </span>Identifier</a></li><li class="tocline"><a href="#record-literal" class="tocxref"><span class="secno">5.5.3 </span>Literal</a></li><li class="tocline"><a href="#record-Time" class="tocxref"><span class="secno">5.5.4 </span>Time</a></li><li class="tocline"><a href="#record-Asserter" class="tocxref"><span class="secno">5.5.5 </span>Asserter</a></li><li class="tocline"><a href="#record-NamespaceDeclaration" class="tocxref"><span class="secno">5.5.6 </span>Namespace Declaration</a></li><li class="tocline"><a href="#record-RecipeLink" class="tocxref"><span class="secno">5.5.7 </span>Recipe Link</a></li><li class="tocline"><a href="#record-Location" class="tocxref"><span class="secno">5.5.8 </span>Location</a></li></ul></li></ul></li><li class="tocline"><a href="#common-relations" class="tocxref"><span class="secno">6. </span>PROV-DM Common Relations</a><ul class="toc"><li class="tocline"><a href="#record-Collection" class="tocxref"><span class="secno">6.1 </span>Collections</a></li><li class="tocline"><a href="#record-traceability" class="tocxref"><span class="secno">6.2 </span>Traceability Record</a></li><li class="tocline"><a href="#record-OrderingOfActivities" class="tocxref"><span class="secno">6.3 </span>Activity Ordering Record</a></li><li class="tocline"><a href="#record-Revision" class="tocxref"><span class="secno">6.4 </span>Revision Record</a></li><li class="tocline"><a href="#attribution-record" class="tocxref"><span class="secno">6.5 </span>Attribution Record</a></li><li class="tocline"><a href="#quotation-record" class="tocxref"><span class="secno">6.6 </span>Quotation Record</a></li><li class="tocline"><a href="#summary-record" class="tocxref"><span class="secno">6.7 </span>Summary Record</a></li><li class="tocline"><a href="#original-source-record" class="tocxref"><span class="secno">6.8 </span>Original Source Record</a></li></ul></li><li class="tocline"><a href="#extensibility-section" class="tocxref"><span class="secno">7. </span>PROV-DM Extensibility Points</a></li><li class="tocline"><a href="#resource-section" class="tocxref"><span class="secno">8. </span>Resources, URIs, Entities, Identifiers, and Scope</a></li><li class="tocline"><a href="#changes-since-first-public-working-draft" class="tocxref"><span class="secno">A. </span>Changes Since First Public Working Draft</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div> 




<div class="buttonpanel"> 
<form action="#"><p> 
<input id="hide-bnf" onclick="set_display_by_class('div','grammar','none'); set_display_by_id('hide-bnf','none');  set_display_by_id('show-bnf','');" type="button" value="Hide Grammar"> 
<input id="show-bnf" onclick="set_display_by_class('div','grammar',''); set_display_by_id('hide-bnf','');  set_display_by_id('show-bnf','none');" style="display: none" type="button" value="Show Grammar"> 
<input id="hide-examples" onclick="set_display_by_class('div','anexample','none'); set_display_by_id('hide-examples','none'); set_display_by_id('show-examples','');" type="button" value="Hide Examples"> 
<input id="show-examples" onclick="set_display_by_class('div','anexample',''); set_display_by_id('hide-examples',''); set_display_by_id('show-examples','none');" style="display: none" type="button" value="Show Examples"> 
</p> 
</form> 
</div>     


    <div id="introduction" class="section"> 
      <!--OddPage--><h2><span class="secno">1. </span>Introduction<br>
</h2> 

<p> 
For the purpose of this specification, provenance is defined as a record that describes the people,
institutions, entities, and activities, involved in producing,
influencing, or delivering a piece of data or a thing in the world.
In particular, the provenance of information is crucial in deciding
whether information is to be trusted, how it should be integrated with
other diverse information sources, and how to give credit to its
originators when reusing it.  In an open and inclusive environment
such as the Web, users find information that is often contradictory or
questionable: provenance can help those users to make trust judgments.
</p>


<p>
The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows  domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>

<p>Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance <em>interchange</em> model across such systems.</p>

<p>A set of specifications define the various aspects
that are necessary to achieve this vision in an inter-operable
way, the first of which is contained in this document:</p>
<ul>
<li>  The PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
<li> A normative serialization of PROV-DM in RDF [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>], specified by means of a mapping to the OWL2 Web Ontology Language [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>];</li>
<li> The mechanisms for accessing and querying provenance [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>];</li>
<li> A Primer for the PROV approach [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].</li>
</ul>


<p>
The PROV-DM data model for provenance consists of a set of core
concepts, and a few common relations, based on these core concepts.  PROV-DM is a domain-agnotisc model, but with well-defined extensibility points allowing further domain-specific and application-specific extensions to be defined.</p>

<p>This specification also introduces
PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
serializations of PROV-DM instances to be written in a technology independent manner,
it facilitates its mapping to concrete syntax, and it is used as the basis for a
formal semantics. This specification uses instances of provenance written in PROV-ASN 
to illustrate the data model. 
</p>

    <div id="structure-of-this-document" class="section"> 
<h3><span class="secno">1.1 </span>Structure of this Document</h3>

<p>In <a href="#preliminaries">section 2</a>, a set of preliminaries are introduced, including concepts that underpin PROV-DM and motivations for the PROV-ASN notation.</p>

<p><a href="#prov-dm-overview">Section 3</a> provides an overview of PROV-DM listing its core types and their relations.</p>

<p>In <a href="#prov-dm-example">section 4</a>, PROV-DM is
applied to a short scenario, encoded in PROV-ASN, and illustrated
graphically.</p>

<p><a href="#data-model-concepts">Section 5</a> provides the normative definition of PROV-DM and the notation PROV-ASN.</p>

<p><a href="#common-relations">Section 6</a> introduces common relations used in PROV-DM, including relations for data collections and common domain-independent common relations.</p>

<p><a href="#extensibility-section">Section 7</a> summarizes PROV-DM extensibility points.</p>

<p><a href="#resource-section">Section 8</a> discusses how PROV-DM can be applied to the notion of resource.</p>


    </div> 

<div id="prov-dm-namespace" class="section">
 <h3><span class="secno">1.2 </span>PROV-DM Namespace</h3>


<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>

<p> All the elements, relations, reserved names and attributes introduced in this specification belong to the PROV-DM namespace.</p>

<div class="note">
There is a desire to use a single namespace that all specs can share to refer to common provenance terms.
</div>

</div>


    <div id="conventions" class="section"> 
<h3><span class="secno">1.3 </span>Conventions</h3>



<p>The key words "<em class="rfc2119" title="must">must</em>", "<em class="rfc2119" title="must not">must not</em>", "<em class="rfc2119" title="required">required</em>", "<em class="rfc2119" title="shall">shall</em>", "<em class="rfc2119" title="shall
      not">shall
      not</em>", "<em class="rfc2119" title="should">should</em>", "<em class="rfc2119" title="should not">should not</em>", "<em class="rfc2119" title="recommended">recommended</em>",  "<em class="rfc2119" title="may">may</em>", and
      "<em class="rfc2119" title="optional">optional</em>" in this document are to be interpreted as described in
      [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>
    </div> 

</div> 


<div id="preliminaries" class="section">
<!--OddPage--><h2><span class="secno">2. </span>Preliminaries</h2>

    <div id="conceptualization" class="section"> 
<h3><span class="secno">2.1 </span>A Conceptualization of the World</h3>



    <div id="section-entity-activity-agent" class="section"> 
<h4><span class="secno">2.1.1 </span>Entity, Activity, Agent</h4>




<p>This specification is based on a conceptualization of the world
that is described in this section. In the world (whether real or not),
there are things, which can be physical, digital, conceptual, or
otherwise, and activities involving things.  </p>

<p>When we talk about things in the world in natural language and even when we assign identifiers, we are often imprecise in ways that make it difficult to clearly and unambiguously report provenance: a resource with a URL may be understood as referring to a report available at that URL, the version of the report available there today, the report independent of where it is hosted over time, etc.</p>

<p>Hence, to accommodate different perspectives on things and their situation in the world as perceived by us, we introduce the idea of a characterized thing, which refers to a thing and its situation in the world, as characterized by someone. We then define an <dfn id="concept-entity">entity</dfn> as an identifiable characterized thing. An entity <em>fixes some aspects</em> of a thing and its situation in the world, so that it becomes possible to express its provenance, and what causes these specific aspects to be as such. An alternative entity may fix other aspects, and its provenance may be different.</p>

<div class="anexample">
Different users may take different perspectives on a resource with
a URL. These perspectives in this conceptualization of the world are
referred to as entities. Three such entities may be
expressed:
<ul>
<li>a report available at  URL: fixes the nature of the thing, i.e. a document, and its location; </li>
<li>the version of the report available there today: fixes its version number, contents, and its date;</li>
<li>the report independent of where it is hosted and of its content over time: fixes the nature of the thing as a conceptual artifact.</li></ul>
The provenance of these three entities may differ, and may be along the following lines: 
<ul>
<li>the provenance of a report available at  URL may include: the act of publishing it and making it available at a given location, possibly under some license and access control;</li>
<li>the provenance of the version of the report available there today may include: the authorship of the specific content, and reference to imported content;</li>
<li>the provenance of the report independent of where it is hosted over time may include: the motivation for writing the report, the overall methodology for producing it, and the broad team involved in it.</li>
</ul>
</div>

<!--
<div class='paolo'>can we follow through from the example. thare three perspectives, possibly by just one observer or multiple ones. but <strong>why is it so important for reporting provenance</strong> that this distinction is made?  I feel we need to connect this approach to provenance recording strongly and right away</div>
-->

<p>We do not assume that any characterization is more important than any other, and in fact, it is possible to describe the processing that occurred for the report to be commissioned, for individual versions to be created, for those versions to be published at the given URL, etc., each via a different entity that characterizes the report appropriately.</p>

<p>In the world, <dfn id="concept-activity">activities</dfn> involve
entities in multiple ways: they consume them, they process them, they
transform them, they modify them, they change them, they relocate
them, they use them, they generate them, they are controlled by them,
etc.</p>


<p>An <dfn id="concept-agent">agent</dfn> is a type of entity that takes an active role in an activity such that it can be assigned some degree of responsibility for the activity taking place.
This definition intentionally stays away from using concepts such as enabling, causing, initiating, affecting, etc, because any entities also enable, cause, initiate, and affect in some way the activities.  So the notion of having some degree of responsibility is really what makes an agent. </p>

<p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say that the Text Editor was responsible for crashing the laptop.  If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well).  So when someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.
</p>
<p> In this specification, the qualifier 'identifiable' is implicit whenever a reference is made to an activity, agent, or an entity.</p>

</div>


    <div id="section-time-event" class="section"> 
<h4><span class="secno">2.1.2 </span>Time and Event</h4>

<p>Time is critical in the context of provenance, since it can help corroborate provenance claims. For instance, if an entity is claimed to be obtained by transforming another, then the latter must have existed before the former. If it is not the case, then there is something wrong in such a provenance claim. </p>

<p> Although time is critical, we should also recognize that provenance can be used in many different contexts: in a single system, across the Web, or in spatial data management, to name a few. Hence, it is a design objective of PROV-DM to minimize the assumptions about time, so that PROV-DM can be used in varied contexts.  </p>


<p>Furthermore, consider two activities that started at the same time
instant. Just by referring to that instant, we cannot distinguish
which activity start we refer to. This is particularly relevant if we
try to explain that the start of these activities had different
reasons.  We need to be able to refer to the start of an activity as a
first class concept, so that we can talk about it and about its
relation with respect to other similar starts. </p>


<p>Hence, in our conceptualization of the world, an instantaneous event, or <dfn id="dfn-event">event</dfn> for short, happens in the world and marks a change in the world, in its activities and in its entities.  
The term "event" is commonly used in process algebra with a similar meaning. For instance, in CSP [<cite><a class="bibref" rel="biblioentry" href="#bib-CSP">CSP</a></cite>], events represent communications or interactions; they are assumed to be atomic and instantaneous.</p>




<div id="types-of-events" class="section">
<h5><span class="secno">2.1.2.1 </span>Types of Events</h5>

<p>Four kinds of events underpin the PROV-DM data model. The <strong>activity start</strong> and <strong>activity end</strong>  events demarcate the beginning and the end of activities, respectively. The <strong>entity generation</strong> and <strong>entity usage</strong> events demarcate the characterization interval for entities. More specifically:

</p>

<p>An <dfn id="dfn-generation-event">entity generation event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the  final instant of an entity's creation timespan, after which it becomes available for use.</p>

<p>An <dfn id="dfn-usage-event">entity usage event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the first instant of an entity's consumption timespan by an activity.</p>

<p>An <dfn id="dfn-start-event">activity start event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity starts.</p>

<p>An <dfn id="dfn-end-event">activity end event</dfn> is the <a href="#dfn-event" class="internalDFN">event</a> that marks the instant an activity ends.</p>

</div>

<div id="event-ordering" class="section">
<h5><span class="secno">2.1.2.2 </span>Event Ordering</h5>

<p>To allow for minimalistic clock assumptions, like Lamport
[<cite><a class="bibref" rel="biblioentry" href="#bib-CLOCK">CLOCK</a></cite>], PROV-DM relies on a notion of relative ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a>,
without using physical clocks. This specification assumes that a partial order exists between <a title="event" href="#dfn-event" class="internalDFN">events</a>.
</p>


<p>Specifically, <dfn id="dfn-follows">follows</dfn> is a partial
order between <a title="event" href="#dfn-event" class="internalDFN">events</a>, indicating that an <a href="#dfn-event" class="internalDFN">event</a> occurs after another.
For symmetry, <dfn id="dfn-precedes">precedes</dfn> is defined as
the inverse of follows. </p>


<p> How such partial order is realized in practice is beyond the scope
of this specification.  This specification only assumes that
each <a href="#dfn-event" class="internalDFN">event</a> can be mapped to an instant in some form of
timeline. The actual mapping is not in scope of this
specification. Likewise, whether this timeline is formed of a single
global timeline or whether it consists of multiple Lamport's style
clocks is also beyond this specification.  It is anticipated
that <a href="#dfn-follows" class="internalDFN">follows</a> and <a href="#dfn-precedes" class="internalDFN">precedes</a> correspond to some ordering
over this timeline.
</p>


<p>This specification introduces a set of "temporal interpretation"
rules allowing to derive <a href="#dfn-event" class="internalDFN">event</a> ordering constraints from
provenance records.  According to such temporal interpretation,
provenance records <em class="rfc2119" title="must">must</em> satisfy such constraints.  We note that the
actual verification of such temporal constraints is also outside the
scope of this specification. </p>

<p>PROV-DM also allows for time observations to be inserted in specific
provenance records, for each recognized <a href="#dfn-event" class="internalDFN">event</a> introduced
in this specification.  The presence of a time observation for a
given <a href="#dfn-event" class="internalDFN">event</a> fixes the mapping of this <a href="#dfn-event" class="internalDFN">event</a> to the
timeline. It can also help with the verification of associated
temporal constraints (though, again, this verification is outside the
scope of this specfication).

</p>



</div>

    </div> 

    </div> 

    <div id="prov-asn--the-provenance-abstract-syntax-notation" class="section"> 
<h3><span class="secno">2.2 </span>PROV-ASN: The Provenance Abstract Syntax Notation</h3>

<p>This specification defines PROV-DM, a data model for provenance, consisting of records describing how people, entities, and activities, were involved in producing,
influencing, or delivering a piece of data or a thing in the world.</p>

<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
<em>instances</em> of that data model. 
For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>





<p>PROV-ASN is an abstract syntax, whose goals are:
</p><ul>
<li>to allow serializations of PROV-DM instances in a technology independent manner, which makes it more readable for human consumption;
</li><li>to facilitate the mapping of PROV-DM to concrete syntax;
</li><li>to provide the basis for a formal semantics.
</li></ul>

<p>This specification provides a grammar for PROV-ASN. Each record of the PROV-DM data model is explained 
in terms of the production of this grammar.</p>



<p>The formal semantics of PROV-DM is defined at
[<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-SEMANTICS">PROV-SEMANTICS</a></cite>] and its encoding in the OWL2 Web Ontology Language at [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>].
</p>






    </div> 

    <div id="representation--assertion--and-inference" class="section"> 
<h3><span class="secno">2.3 </span>Representation, Assertion, and Inference</h3>

<p>
PROV-DM is a provenance data model designed to express <em>representations</em> of the world. 
</p>

<div class="anexample">
A file at some point during its lifecycle, which includes multiple edits by multiple people, can be represented by its location in the file system, a creator, and content.  
</div>


<p>
These representations are relative to an asserter, and in that sense constitute assertions stating properties of the world, as represented by an asserter. Different asserters will normally contribute different representations.
This specification does not define a notion of consistency between different sets of assertions (whether by the same asserter or different asserters).
The data model provides the means to associate attribution to assertions.  
</p>

<div class="anexample">
An alternative representation of the above file is a set of blocks in a hard disk.
</div>


<p>The data model is designed to capture activities that happened in the past, as opposed to activities
that may or will happen. 
However, this distinction is not formally enforced.
Therefore, all PROV-DM assertions <em class="rfc2119" title="should">should</em> be interpreted as a record of what has happened, as opposed to what may or will happen.</p>



<p> 
This specification does not prescribe the means by which an asserter arrives at assertions; for example, assertions can be composed on the basis of observations, reasoning, or any other means. 
</p>


<p>
Sometimes, inferences about the world can be made from representations
conformant to the PROV-DM data model. When this is the case, this
specification defines such inferences, allowing new provenance records
to be inferred from existing ones. Hence, representations of the world
can result either from direct assertions by asserters or from
application of inferences defined by this specification.
</p>



</div>
    <div id="grammar-notation" class="section"> 
<h3><span class="secno">2.4 </span>Grammar Notation</h3>

<p>This specification includes a grammar for PROV-ASN expressed using the Extended  Backus-Naur Form (EBNF) notation.</p>

<div class="grammar">
<p> Each rule in the grammar defines one symbol, in the form:</p>
<p>
<span class="nonterminal">E</span>&nbsp;::= <em>expression</em>
</p>


Within the expression on the right-hand side ofa rule, the follwoing expressions are used to match strings of one or more characters:
<ul>
<li> 
<span class="nonterminal">E</span>: matches term satisfying rule for symbol E.
</li>

<li> 
<span class="name">abc</span>: matches the literal string inside the single quotes.
</li>


<li> 
<span class="optional"><em>expression</em></span>: matches <em>expression</em> or nothing; optional <em>expression</em>.
</li>

<li> 
<span class="plus"><em>expression</em></span>: matches one or more occurrences of <em>expression</em>.
</li>

<li> 
<span class="star"><em>expression</em></span>: matches zero or more occurrences of <em>expression</em>.
</li>

</ul>
</div>

</div>
</div>

    <div id="prov-dm-overview" class="section"> 
<!--OddPage--><h2><span class="secno">3. </span>PROV-DM: An Overview </h2>

<p>
The following ER diagram provides a high level overview of the <strong>structure of PROV-DM records</strong>. Examples of provenance assertions that conform to this schema are provided in the next section.</p>

<div style="text-align: center;">
  <img src="overview.png" alt="PROV-DM overview">
</div>

<div class="note"> Overview diagram does not represent the sub-relations -- proposal to use a UML notation instead of ER.</div>


<p>The model includes the following elements:</p>
<ul>
  <li>An <a title="entity record" href="#dfn-entity" class="internalDFN">Entity Record</a> (noted <samp>entity</samp> in the diagram, to reflect the term used in the ASN) is a representation of an <em>entity</em>. 

  </li><li>An <a title="activity record" href="#dfn-activity" class="internalDFN">Activity Record</a>(noted <samp>activity</samp> in the diagram) represents an activity that has an effect on entities, namely it either <em>generates</em> or <em>uses</em> one or more entities. Usage and generation are modelled by means of the <a title="usage record" href="#dfn-Use" class="internalDFN">used</a> and the <a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a> relationships.  Activities may include not only computations, but also any other type of activity that can be described in terms of their effect on <samp>entities</samp>.
Note that multiple <samp>activities</samp> may <em>use</em> the same <samp>entity</samp>, and each activity may use multiple <samp>entities</samp>. Finally, entities can be derived from other entities, and this is specified using the <a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a> relation.</li>
  
  <li>An <a title="agent record" href="#dfn-Agent" class="internalDFN">Agent Record</a> represents a particular <samp>entity</samp> that can be associated to activities, meaning that it can be assigned some degree of responsibility for an <samp>activity</samp> taking place.
  Agents have a rather generic connotation: their  association with an activity is  represented by the <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> relationship, which can take up various meanings (attribution, responsibility, supervision, management, etc.), which are not individually specified in the model. Relations <a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a> and <a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a> are specializations of <a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a> that can optionally be used to carry additional meaning. Furthermore, it is recognized that agents can act on behalf of others: hence, the relation <a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a> allows for chains of responsibility to be stated.
</li>



</ul>

<p> A set of attribute-value pairs can be associated to elements and relations of the PROV model in order to further characterize
their nature. 
The       <a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a> relationship is used to denote that two <samp>entities</samp> <em>complement</em> each other, in the sense that they each represent a partial, but mutually compatible characterization of the same thing.
The attributes <a title="prov:role" href="#dfn-role" class="internalDFN">role</a> and <a title="prov:type" href="#dfn-type" class="internalDFN">type</a> are pre-defined.  
</p>


<p>The set of relations presented here forms a core, which is further extended with additional relations, defined in Section <a href="#common-relations">Common Relations</a>.</p>


<p>
The model includes a further additional element: <a title="note record" href="#dfn-note" class="internalDFN">notes</a>. These are also structured as sets of attribute-value pairs.  Notes are used to provide additional, "free-form" information regarding <em>any</em> identifiable construct of the model, with no prescribed meaning. Notes are described in detail <a href="#record-note">here</a>. 
</p>
   
<p> 
Attributes and notes are the main <em>extensibility points</em> in the model: individual interest groups  are expected to extend PROV-DM by introducing new attributes and notes as needed to address applications-specific provenance modelling requirements. </p>
    
</div> 


    <div class="informative section" id="prov-dm-example"> 
<!--OddPage--><h2><span class="secno">4. </span>Example</h2><p><em>This section is non-normative.</em></p>

<div class="issue"> There is a suggestion that a better example should be adopted for this document. Possibly, several shorter examples. This is <a href="http://www.w3.org/2011/prov/track/issues/132">ISSUE-132</a></div>


To illustrate PROV-DM, this section presents an example encoded according to PROV-ASN.  For more detailed explanations of how PROV-DM should be used, and for more examples, we refer the reader to the Provenance Primer [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>].





<div class="pending">Comments on section 3.2. This is <a href="http://www.w3.org/2011/prov/track/issues/71">ISSUE-71</a></div>

    <div id="a-file-scenario" class="section"> 
<h3><span class="secno">4.1 </span>A File Scenario</h3>


<p>This scenario is concerned with the evolution of a crime statistics
file (referred to as e0) stored on a shared file system and which
journalists Alice, Bob, Charles, David, and Edith can share and
edit. We consider various <a title="event" href="#dfn-event" class="internalDFN">events</a> in the evolution of file e0;
<a title="event" href="#dfn-event" class="internalDFN">events</a> listed below follow each other, unless otherwise specified.</p>



<p>
<a href="#dfn-event" class="internalDFN">Event</a> evt1: Alice creates (a0) an empty file in /share/crime.txt.  We denote this file e1.
</p>

<p>
<a href="#dfn-event" class="internalDFN">Event</a> evt2: Bob appends (a1) the following line to /share/crime.txt:</p>
<pre>There was a lot of crime in London last month.
</pre>
<p>We denote the revised file e2.</p>

<p><a href="#dfn-event" class="internalDFN">Event</a> evt3: Charles emails (a2) the contents of /share/crime.txt, as an
attachment, which we refer to as e4. (We specifically refer to a copy of the file that is uploaded on the mail server.)
</p>

<p>
<a href="#dfn-event" class="internalDFN">Event</a> evt4: David edits (a3) file /share/crime.txt as follows.</p>
<pre>There was a lot of crime in London and New-York last month.
</pre>
<p>
We denote the revised file e3.
</p>

<p><a href="#dfn-event" class="internalDFN">Event</a> evt5: Edith emails (a4) the contents of /share/crime.txt as an attachment, referred to as e5.
</p>

<p><a href="#dfn-event" class="internalDFN">Event</a> evt6: between <a title="event" href="#dfn-event" class="internalDFN">events</a> evt4 and evt5, someone (unspecified) runs a spell checker (a5) on the file /share/crime.txt.
 The file after spell checking is referred to as e6.
</p>

</div> 

    <div id="example-prov-asn-encoding" class="section"> 
<h3><span class="secno">4.2 </span>Encoding using PROV-ASN</h3>

In this section, the example is encoded according to the provenance data model (specified in section <a href="#data-model-concepts">PROV-DM: The Provenance Data Model</a>) and expressed in PROV-ASN. 
<p>
Entity Records (described in <a href="#record-Entity">Section Entity</a>). The file in its various forms and its copies are modelled as entity records, corresponding to multiple characterizations, as per scenario. The entity records are identified by  <span class="name">e0</span>, ..., <span class="name">e6</span>.</p>
<pre>entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
entity(e2, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London last month."])
entity(e3, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month."])
entity(e4)
entity(e5)
entity(e6, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="There was a lot of crime in London and New York last month.", ex:spellchecked="yes"])
</pre>



<p>These entity records list attributes that have been given values during intervals delimited by <a title="event" href="#dfn-event" class="internalDFN">events</a>; such intervals are referred to as <em>characterization intervals</em>. The following table lists all entity identifiers and their corresponding characterization intervals. When the end of the characterization interval is not delimited by an <a href="#dfn-event" class="internalDFN">event</a> described in this scenario, it is marked by "...".</p>
<blockquote>
<table>
<tbody><tr><td>Entity</td><td>Characterization Interval</td></tr>
<tr><td>e0</td><td>evt1 - ...</td></tr>
<tr><td>e1</td><td>evt1 - evt2</td></tr>
<tr><td>e2</td><td>evt2 - evt4</td></tr>
<tr><td>e3</td><td>evt4 - ...</td></tr>
<tr><td>e4</td><td>evt3 - ...</td></tr>
<tr><td>e5</td><td>evt5 - ...</td></tr>
<tr><td>e6</td><td>evt6 - ... </td></tr>
</tbody></table>
</blockquote>



<p>
Activity Records (described in <a href="#record-Activity">Section Activity</a>) represent activities in the scenario.</p>
<pre>activity(a0, create-file,          2011-11-16T16:00:00,)
activity(a1, add-crime-in-london,  2011-11-16T16:05:00,)
activity(a2, email,                2011-11-16T17:00:00,)
activity(a3, edit-London-New-York, 2011-11-17T09:00:00,)
activity(a4, email,                2011-11-17T09:30:00,)
activity(a5, spellcheck,,)
</pre>


<p>
Generation Records (described in <a href="#record-Generation">Section Generation</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> at which a file is created in a specific form. Attributes are used to describe the modalities according to which a given entity is generated by a given activity.  The interpretation of attributes is application specific. Illustrations of such attributes for the scenario are: no attribute is provided for <span class="name">e0</span>;
<span class="name">e2</span> was generated by the editor's  save function;  <span class="name">e4</span> can be found on the smtp port, in the attachment section of the mail message; <span class="name">e6</span> was produced on the standard output of <span class="name">a5</span>. Two identifiers <span class="name">g1</span> and <span class="name">g2</span> identify the generation records referenced in derivations introduced below.</p>
<pre>wasGeneratedBy(e0, a0)
wasGeneratedBy(e1, a0, [ex:fct="create"])
wasGeneratedBy(e2, a1, [ex:fct="save"])     
wasGeneratedBy(e3, a3, [ex:fct="save"])     
wasGeneratedBy(g1, e4, a2, [ex:port="smtp", ex:section="attachment"])  
wasGeneratedBy(g2, e5, a4, [ex:port="smtp", ex:section="attachment"])    
wasGeneratedBy(e6, a5, [ex:file="stdout"])
</pre>



<p>
Usage Records (described in <a href="#record-Usage">Section Usage</a>) represent the <a href="#dfn-event" class="internalDFN">event</a> by which a file is read by an activity. 

Likewise, attributes describe the modalities according to which the various entities are used by activities.  Illustrations of such attributes are: 
<span class="name">e1</span> is used in the context of  <span class="name">a1</span>'s <span class="name">load</span> functionality; <span class="name">e2</span> is used by <span class="name">a2</span> in the context of its attach functionality; <span class="name">e3</span> is used on the standard input by <span class="name">a5</span>. Two identifiers <span class="name">u1</span> and <span class="name">u2</span> identify the Usage records referenced in derivations introduced below.</p>
<pre>used(a1,e1,[ex:fct="load"])
used(a3,e2,[ex:fct="load"])
used(u1,a2,e2,[ex:fct="attach"])
used(u2,a4,e3,[ex:fct="attach"])
used(a5,e3,[ex:file="stdin"])
</pre>


<p>
Derivation Records (described in <a href="#Derivation-Relation">Section Derivation Relation</a>) express that an entity is derived from another.  The first two are expressed in their compact version, whereas the following two are expressed in their full version, including the activity underpinning the derivation, and associated  usage (<span class="name">u1</span>, <span class="name">u2</span>) and generation (<span class="name">g1</span>, <span class="name">g2</span>) records.</p>
<pre>wasDerivedFrom(e2,e1)
wasDerivedFrom(e3,e2)
wasDerivedFrom(e4,e2,a2,g1,u1)
wasDerivedFrom(e5,e3,a4,g2,u2)
</pre>



<p>
wasComplementOf:   (this relation is described in <a href="#record-complement-of">Section wasComplementOf</a>). The crime statistics file (<span class="name">e0</span>) has various contents over its existence (<span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span>); the entity records identified by <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">e3</span> complement <span class="name">e0</span> with an attribute <span class="name">content</span>.  Likewise, the one denoted by <span class="name">e6</span> complements the record denoted by <span class="name">e3</span> with an attribute <span class="name">spellchecked</span>.</p>
<pre>wasComplementOf(e1,e0)
wasComplementOf(e2,e0)
wasComplementOf(e3,e0)
wasComplementOf(e6,e3) 
</pre>



<p>
Agent Records (described at <a href="#record-Agent">Section Agent</a>): the various users are represented as agents, themselves being a type of entity.</p>
<pre>agent(ag1, [ prov:type="prov:Person" %% xsd:QName, ex:name="Alice" ])

agent(ag2, [ prov:type="prov:Person" %% xsd:QName, ex:name="Bob" ])

agent(ag3, [ prov:type="prov:Person" %% xsd:QName, ex:name="Charles" ])

agent(ag4, [ prov:type="prov:Person" %% xsd:QName, ex:name="David" ])

agent(ag5, [ prov:type="prov:Person" %% xsd:QName, ex:name="Edith" ])
</pre>



<p>
Activity Assocation Records (described in <a href="#record-ActivityAssociation">Section Activity Association</a>): the association of an agent with an activity is expressed with , and the nature of this association is described by attributes.  Illustrations of such attributes include the role of the participating agent, as creator, author and communicator (role is a reserved attribute in PROV-DM).</p>
<pre>wasAssociatedWith(a0, ag1, [prov:role="creator"])
wasAssociatedWith(a1, ag2, [prov:role="author"])
wasAssociatedWith(a2, ag3, [prov:role="communicator"])
wasAssociatedWith(a3, ag4, [prov:role="author"])
wasAssociatedWith(a4, ag5, [prov:role="communicator"])
</pre>
</div> 


    <div id="graphical-illustration" class="section"> 
<h3><span class="secno">4.3 </span>Graphical Illustration</h3>


<p>
Provenance assertions can be <em>illustrated</em> graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance assertions.  Therefore, it cannot be seen as an alternate notation for expressing provenance.</p>

<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and half-hexagonal shapes, respectively.  Usage, Generation, Derivation, Activity Association, and Complementarity are represented as directed edges.</p>

<p>Entities are layed out according to the ordering of their generation event.  We endeavor to show time progressing from left to right.  This means that edges for Usage, Generation and Derivation typically point from right to left.</p>


<div style="text-align: center;">
<img src="example-graphical.png" alt="example">
</div>
<br>
<div style="text-align: center;">
<img src="timeline.png" alt="example">
</div>
</div> 

</div> 



<div id="data-model-concepts" class="section"> 

<!--OddPage--><h2><span class="secno">5. </span>PROV-DM Core</h2>

<p>This section contains the normative specification of PROV-DM core, the core of the PROV data model.</p>

<div class="note">
In a next iteration of this document, it is proposed to reorganize
section 5 as follows.  First, the presentation of the data model
alone. Second, its temporal interpretation. Third, the constraints and
inferences associated with well-formed accounts.  
</div>

   <div id="PROV-DM-record" class="section"> 
      
<h3><span class="secno">5.1 </span>Record</h3>

<p>PROV-DM consists of a set of constructs, referred to as <em>records</em>, to formulate representations of the world and constraints that must be satisfied by them.</p>

<p>
Furthermore,  PROV-DM includes a "house-keeping construct", a record container,
 used to wrap PROV-DM records and facilitate their interchange.</p>

<p>In PROV-ASN, such representations of the world <em class="rfc2119" title="must">must</em> be conformant with the toplevel production <span class="nonterminal">record</span> of the grammar. These <span class="nonterminal">record</span>s are grouped in three categories:
<span class="nonterminal">elementRecord</span> (see section <a href="#record-element">Element</a>),
<span class="nonterminal">relationRecord</span>  (see section <a href="#record-relation">Relation</a>), and
<span class="nonterminal">accountRecord</span> (see section <a href="#record-Account">Account</a>).</p>


<div class="grammar">
<span class="nonterminal">record</span>&nbsp;::=  
<span class="nonterminal">elementRecord</span> 
| <span class="nonterminal">relationRecord</span> 
| <span class="nonterminal">accountRecord</span> 
<br>
<!-- -->
<br>
<span class="nonterminal">elementRecord</span>&nbsp;::=  
<span class="nonterminal">entityRecord</span> 
| <span class="nonterminal">activityRecord</span> 
| <span class="nonterminal">agentRecord</span>
| <span class="nonterminal">noteRecord</span> <br>
<!-- -->
<br>
<span class="nonterminal">relationRecord</span>&nbsp;::=  
<span class="nonterminal">generationRecord</span> 
| <span class="nonterminal">usageRecord</span> 
| <span class="nonterminal">derivationRecord</span> 
| <span class="nonterminal">activityAssociationRecord</span> 
| <span class="nonterminal">responsibilityRecord</span> 
| <span class="nonterminal">startRecord</span> 
| <span class="nonterminal">endRecord</span> 
| <span class="nonterminal">complementRecord</span> 
| <span class="nonterminal">annotationRecord</span> 
</div>


<p>In PROV-ASN, a record container is compliant with the production <span class="nonterminal">recordContainer</span> (see section <a href="#RecordContainer">Record Container</a>). </p>

</div>

   <div id="record-element" class="section"> 
<h3><span class="secno">5.2 </span>Element</h3>

<p>This section describes all the PROV-DM records referred to as element records. (They are conformant to the <span class="nonterminal">elementRecord</span> production of the grammar.)</p>



   <div id="record-Entity" class="section"> 
      
<h4><span class="secno">5.2.1 </span>Entity Record</h4>

<p>In PROV-DM, an  <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>


<p>Examples of entities include a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web,  and meta-data embedded in a document.</p>

<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; the identifier of the entity record is defined to be the same as the identifier of the entity; </li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
</ul>


<p>
The assertion of an entity record, <span class="name">entity(id, [ attr1=val1, ...])</span>, states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world. 
</p>

<p>
In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
</p>

<div class="grammar">
<span class="nonterminal">entityRecord</span>&nbsp;::=  
<span class="name">entity</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br><br>
<!-- -->
<span class="nonterminal">optional-attribute-values</span>&nbsp;::= 
<span class="optional"><span class="name">,</span>
<span class="name">[</span>
<span class="nonterminal">attribute-values</span>
<span class="name">]</span>
</span><br>
<span class="nonterminal">attribute-values</span>&nbsp;::=  
<span class="nonterminal">attribute-value</span>
| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
<br>
<span class="nonterminal">attribute-value</span>&nbsp;::=  
<span class="nonterminal">attribute</span>
<span class="name">=</span>
<span class="nonterminal">Literal</span>
<br>
</div>

<div class="anexample">
<p>
The following entity record,</p>
<pre class="codeexample">entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
</pre>
states the existence of an entity, denoted by identifier <span class="name">e0</span>,  with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the file system,  and creator alice The  attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span class="name">type</span> is reserved in the PROV-DM namespace.
</div>

Further considerations:
<ul>
<li>If an asserter wishes to characterize an entity  with the same attribute-value pairs over several intervals, then they are required to assert multiple entity records, each with its own identifier (so as to allow potential dependencies between the various entity records to be expressed).  </li>

<li>There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.</li>

<li>A characterization interval may collapse into a single instant.</li>

<li>An entity assertion
 is about a thing, whose  situation in the world may be variant.
 An entity record is asserted at a particular point and is invariant, in the sense that 
its attributes are given a value as part of that assertion.
</li>

<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
</ul>






<div class="note">The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define wasComplementOf more precisely. It would also allow us to address 
<a href="http://www.w3.org/2011/prov/track/issues/108">ISSUE-108</a>.
Beginning and end of characterization interval could be expressed by attributes (similarly to activities). </div>


 

    </div> 

    <div id="record-Activity" class="section"> 
      
<h4><span class="secno">5.2.2 </span>Activity Record</h4>
<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>


<p>An activity, represented by an activity record, is delimited by its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> and its <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> events; hence, it occurs over an interval delimited by two <a title="event" href="#dfn-event" class="internalDFN">events</a>. However, an activity record need not mention time information, nor duration, because they may not be known.</p>

<p>Such start and end times constitute <em>attributes</em> of an activity, where the interpretation of attribute in the context of an activity record is the same as the interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents.  Further characteristics of the activity in the world can be represented by other attribute-value pairs, which <em class="rfc2119" title="must">must</em> also remain unchanged during the activity duration.</p>

<p>
Examples of activities include assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>

<p> An activity record, written <span class="name">activity(id, rl, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity; the identifier of the activity record is defined to be the same as the identifier of the activity;</li>
<li><em>recipeLink</em>: an <em class="rfc2119" title="optional">optional</em> <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>
<li><em>startTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">st</span> indicating the start of the activity;</li>
<li><em>endTime</em>: an <em class="rfc2119" title="optional">optional</em> time <span class="name">et</span> indicating the end of the activity;</li>
<li><em>attributes</em>:  a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole duration.</li>
</ul>

<p>In PROV-ASN, an activity record's text matches the <span class="nonterminal">activityRecord</span> production of the grammar defined in this specification document.</p>



<div class="grammar">
<span class="nonterminal">activityRecord</span>&nbsp;::=  
<span class="name">activity</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="optional"><span class="name">,</span>
<span class="nonterminal">recipeLink</span> </span>
<span class="name">,</span>
<span class="optional"><span class="nonterminal">time</span></span>
<span class="name">,</span>
<span class="optional"><span class="nonterminal">time</span></span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br>
</div>

<div class="anexample">
<p>
The following activity assertion</p>
<pre class="codeexample">activity(a1,add-crime-in-london,2011-11-16T16:05:00,2011-11-16T16:06:00,[ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
</pre>
<p>identified by identifier <span class="name">a1</span>, states the existence of an activity with recipe link <span class="name">add-crime-in-london</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix <span class="name">ex</span>).  The attribute <span class="name">host</span> is application specific, but <em class="rfc2119" title="must">must</em> hold for the duration of activity.  The attribute <span class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
</div>

<p>The mere existence of an activity assertion entails some <a href="#dfn-event" class="internalDFN">event</a> ordering in the world, since an <a href="#dfn-start-event" class="internalDFN">activity start event</a> always <a href="#dfn-precedes" class="internalDFN">precedes</a> the corresponding <a href="#dfn-end-event" class="internalDFN">activity end event</a>.  This is expressed by constraint <a href="#start-precedes-end">start-precedes-end</a>.</p> 

<div class="interpretation" id="start-precedes-end"> The following temporal constraint holds for any activity record: the
<a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a>.</div> 

<p>An activity record is not an entity record.
Indeed, an entity record represents an entity that exists in full at
any point in its characterization interval, persists during this
interval, and preserves the characteristics that makes it
identifiable.  Alternatively, an activity in something that happens,
unfolds or develops through time, but is typically not identifiable by
the characteristics it exhibits at any point during its duration. 
This distinction is similar to the distinction between 
'continuant' and 'occurrent' in logic [<cite><a class="bibref" rel="biblioentry" href="#bib-Logic">Logic</a></cite>].</p>


</div> 

<div id="record-Agent" class="section">
<h4><span class="secno">5.2.3 </span>Agent Record</h4>



<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>

<p>Many agents can have an association with a given activity.  An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it, another agent may run it, etc.  
As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>

<p>
From an inter-operability perspective, it is useful to define some basic categories of agents since
it will improve the use of provenance records by applications.  
There should be very few of these basic categories to keep the model simple and accessible. 
There are three types of agents in the model:
</p><ul>
<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li> 
<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization" [<cite><a class="bibref" rel="biblioentry" href="#bib-FOAF">FOAF</a></cite>])</li> 
<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
</ul>
<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>

<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent; the identifier of the agent record is defined to be the same as the identifier of the agent;</li>
<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
</ul>

<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
</p>


<div class="grammar">
<span class="nonterminal">agentRecord</span>&nbsp;::= 
<span class="name">agent</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>




<div class="anexample">
<p>With the following assertions,</p>
<pre class="codeexample">agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])

entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])

entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
</pre>
<p>the agent record identified by <span class="name">e1</span> is an explicit agent assertion that holds irrespective of activities it may be associated with. On the other hand, from the entity records identified  by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
</div>

<p>One can assert an agent record or alternatively, one can infer an agent record
by its association with an activity.  </p>

<div class="constraint" id="association-agent">
<span class="conditional">If</span> the records <span class="name">entity(e,attrs)</span>
and
<span class="name">wasAssociatedWith(a,e)</span> hold for some identifiers 
<span class="name">a</span>, <span class="name">e</span>, and attribute-values <span class="name">attrs</span>, then
the record <span class="name">agent(e,attrs)</span> also holds.
</div>

</div>

   <div id="record-note" class="section"> 
      
<h4><span class="secno">5.2.4 </span>Note Record</h4>

<p>As provenance records are exchanged between systems, it may be useful to add extra-information about such records. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the assertions made. Likewise, an interactive visualization component may want to enrich a set of provenance records with information helping reproduce their visual representation. To help with inter-operability, PROV-DM introduces a simple annotation mechanism allowing any identifiable record to be associated with notes.</p>

<p>An <dfn id="dfn-note">note record</dfn> is a set of attribute-value pairs, whose meaning is application specific. It may or may not be a representation of something in the world.</p> 

<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
</p>


<div class="grammar">
<span class="nonterminal">noteRecord</span>&nbsp;::= 
<span class="name">note</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="name">,</span>
<span class="nonterminal">attribute-values</span>
<span class="name">)</span><br>
<!-- -->
</div>

<p>A separate PROV-DM record is used to associate a note with an identifiable record (see <a href="#record-annotation">Section on annotation</a>). A given note may be associated with multiple records.
</p>


<div class="anexample">
<p>
The following note record</p>
<pre class="codeexample">note(ann1,[ex:color="blue", ex:screenX=20, ex:screenY=30])
</pre>
<p>consists of a set of application-specific attribute-value pairs, intended
to help the rendering of the record it is associated with, by
specifying its color and its position on the screen.  In this example,
these attribute-value pairs do not constitute a representation of something
in the world; they are just used to help render provenance.
</p>
</div>

<p>
Attribute-value pairs occurring in notes differ from attribute-value pairs occurring in entity records and activity records.  In entity and activity records, attribute-value pairs <em class="rfc2119" title="must">must</em> be a representation of something in the world, which remain constant for the duration of the characterization interval (for entity record) or the activity duration (for activity records). In note records, it is <em class="rfc2119" title="optional">optional</em> for attribute-value pairs to be representations  of something in the world. If they are a representation of something in the world, then it <em class="rfc2119" title="may">may</em> change value for the corresponding duration. If attribute-value pairs of a note record are a representation of something in the world that does not change, they are not regarded as determining characteristics of an entity or activity, for the purpose of provenance. 
</p>


   </div> 

</div>


<div id="record-relation" class="section">
<h3><span class="secno">5.3 </span>Relation</h3>

<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not binary,  they all involve two primary elements. They can be summarized as follows. </p>


<div style="text-align: center;">
<table border="1" style="margin-left: auto; margin-right: auto;">
<caption>PROV-DM Core Relation Summary</caption>
<tbody><tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr> 
<tr><td>Entity</td><td><a title="derivation record" href="#dfn-Derivation" class="internalDFN">wasDerivedFrom</a><br><a title="complementarity record" href="#complementOf" class="internalDFN">wasComplementOf</a></td><td><a title="generation record" href="#dfn-Generation" class="internalDFN">wasGeneratedBy</a></td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
<tr><td>Activity</td><td><a title="usage record" href="#dfn-Use" class="internalDFN">used</a></td><td>-</td><td><a title="start record" href="#dfn-Start" class="internalDFN">wasStartedBy</a><br><a title="end record" href="#dfn-End" class="internalDFN">wasEndedBy</a><br><a title="activity association record" href="#dfn-activity-association" class="internalDFN">wasAssociatedWith</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
<tr><td>Agent</td><td>-</td><td>-</td><td><a title="responsibility record" href="#dfn-responsibility" class="internalDFN">actedOnBehalfOf</a></td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
<tr><td>Note</td><td>-</td><td>-</td><td>-</td><td><a title="annotation record" href="#dfn-annotation" class="internalDFN">hasAnnotation</a></td></tr>
</tbody></table>
</div>


<p>In PROV-ASN, all these relation records are  conformant to the <span class="nonterminal">relationRecord</span> production of the grammar.</p>

<div id="activity-entity-relation" class="section">
<h4><span class="secno">5.3.1 </span>Activity-Entity Relation</h4>

<div id="record-Generation" class="section">
<h5><span class="secno">5.3.1.1 </span>Generation Record</h5>


<p>In PROV-DM, a <dfn id="dfn-Generation">generation record</dfn> is a representation of a world <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">event</a>, the creation of a new entity by an activity. This entity did not exist before creation. 
The representation of this <a href="#dfn-event" class="internalDFN">event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>

<p>A <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> may be, for example, the creation of a file by a program, the creation of a linked data set, the production of a new version of a document, and the sending of a value on a communication channel.</p>

<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,attrs,t)</span> in PROV-ASN, has the following components:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the generation record;</li> 
<li><em>entity</em>:  an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
<li><em>activity</em>:  an identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>

<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "generation time" <span class="name">t</span>, the time at which the entity was created;</li>

<li><em>attributes</em>:  an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>

</ul>

<p>In PROV-ASN, a generation record's text matches the <span class="nonterminal">generationRecord</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">generationRecord</span>&nbsp;::=  
<span class="name">wasGeneratedBy</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>
<span class="name">,</span> </span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">aIdentifier</span>
<span class="optional"><span class="name">,</span>
<span class="nonterminal">time</span></span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br>
</div>


<p>
A generation record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be used when annotating generation records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).
</p>


<div class="anexample">
<p>
The following generation assertions</p>
<pre class="codeexample">  wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
  wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
</pre>
<p>state the existence of two <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an activity, itself represented by an activity record identified by <span class="name">a1</span>.
The first one is available as the first value on port p1, whereas the other is the second value on port p1.  The semantics of <span class="name">port</span> and <span class="name">order</span> in these records are application specific.
</p>
</div>



<p>The assertion of a generation record implies ordering of <a title="event" href="#dfn-event" class="internalDFN">events</a> in the world.</p>


<div class="interpretation" id="generation-activity-ordering"><span class="conditional">If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class="conditional">then</span> the following temporal constraint also holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of the entity denoted by <span class="name">x</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a>
of <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> of <span class="name">a</span>. 
</div> 



<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
The rationale for this constraint is as follows.
If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation events</a>, then they generate distinct entities. Alternatively,  for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this synchronization would constitute the actual generation of the entity, but is performed by a single activity. This unicity constraint is formalized as follows.

</p><div class="constraint" id="generation-unicity">Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
<span class="conditional">if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given account,
<span class="conditional">then</span> <span class="name">a1</span>=<span class="name">a2</span>  and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
</div> 

<div class="note">TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>


</div>


<div id="record-Usage" class="section">
<h5><span class="secno">5.3.1.2 </span>Usage Record</h5>



<p>In PROV-DM, a <dfn id="dfn-Use">usage record</dfn> is a representation of a world <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">event</a>: the consumption of an entity by an activity. The representation includes a description of the modalities of usage of this entity by this activity.</p>

<p>
A <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage event</a> may be the consumption of a parameter by a procedure, the reading of a value on a port by a service, the reading of a configuration file by a program, or the adding of an ingredient, such as eggs, in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>


<p>A usage record, written <span class="name">used(id,a,e,attrs,t)</span> in PROV-ASN, has the following constituent:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the usage record;</li> 
<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
<li><em>time</em>: an <em class="rfc2119" title="optional">optional</em> "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
<li><em>attributes</em>: an OPTIONIAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
</ul>

<p>In PROV-ASN, a usage record's text matches the <span class="nonterminal">usageRecord</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">usageRecord</span>&nbsp;::=  
<span class="name">used</span>
<span class="name">(</span>
<span class="optional">
<span class="nonterminal">identifier</span>
<span class="name">,</span>
</span>
<span class="nonterminal">aIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="optional">
<span class="name">,</span>
 <span class="nonterminal">time</span>
</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br>
</div>


<p>
A usage record's id is <em class="rfc2119" title="optional">optional</em>, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
</p>


<div class="anexample">
<p>The following usage records</p>
<pre class="codeexample">  used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
  used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
</pre>
<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and  <span class="name">2011-11-16T16:00:01</span>, respectively; the first one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>.  The semantics of <span class="name">parameter</span> in these records is application specific.</p>
</div>





<p>
A usage record's id is <em class="rfc2119" title="optional">optional</em>. It <em class="rfc2119" title="must">must</em> be present when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining precise-1 derivations (see <a href="#Derivation-Relation">Derivation Record</a>).</p>

<p>
A reference to a given entity record <em class="rfc2119" title="may">may</em> appear in multiple usage records that share
 a given activity record identifier. 
</p>





<div class="interpretation" id="usage-generation-ordering">For any entity, the following temporal constraint holds: the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of an entity always <a href="#dfn-precedes" class="internalDFN">precedes</a> any of its <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usages</a>.
</div>


<div class="interpretation" id="usage-activity-ordering">Given an activity record identified by <span class="name">a</span>, an entity record identified by <span class="name">e</span>, a set of attribute-value pairs <span class="name">attrs</span>, and optional time <span class="name">t</span>, <span class="conditional">if</span>
 assertion <span class="name">used(a,e,attrs)</span> or <span class="name">used(a,e,attrs,t)</span> holds, <span class="conditional">then</span> the following temporal constraint holds:
 the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a> of the entity represented by entity record identified by <span class="name">e</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end</a> of activity represented by record identified by <span class="name">a</span> and <a href="#dfn-follows" class="internalDFN">follows</a> its <a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a>. 
</div>




<div class="issue">Should we define a taxonomy of use? This is <a href="http://www.w3.org/2011/prov/track/issues/23">ISSUE-23</a>.</div>

</div>
</div>





<div id="activity-agent-relation" class="section">
<h4><span class="secno">5.3.2 </span>Activity-Agent Relation</h4>

<div id="record-ActivityAssociation" class="section">
<h5><span class="secno">5.3.2.1 </span>Activity Association Record</h5>

<p>The key purpose of agents in PROV-DM is to assign responsibility
for activities.  It is important to reflect that there is a degree in
the responsibility of agents, and that is a major reason for
distinguishing among all the agents that have some association with an
activity and determine which ones are really the originators of the
entity.  For example, a programmer and a researcher could both be
associated with running a workflow, but it may not matter what
programmer clicked the button to start the workflow while it would
matter a lot what researcher told the programmer to do so.  Another
example: a student publishing a web page describing an academic
department could result in both the student and the department being
agents associated with the activity, and it may not matter what
student published a web page but it matters a lot that the department
told the student to put up the web page.  So there is some notion of
responsibility that needs to be captured. </p>

<p>To this end, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent and an activity; the second, introduced in <a href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>

<p>Examples of activity association  include designing, participation, initiation and termination, timetabling or sponsoring. </p>

<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(a,ag2,attrs)</span> in PROV-ASN, has the following constituents:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the activity association record;</li> 
<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent;</li>
<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity.</li>

</ul>

<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">activityAssociationRecord</span>&nbsp;::= 
<span class="name">wasAssociatedWith</span>
<span class="name">(</span>
<span class="optional"><span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">aIdentifier</span>,
<span class="nonterminal">agIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>

<div class="anexample">
In the following example, a programmer and a researcher agents are asserted to be associated with an activity.
<pre class="codeexample">activity(a,[prov:type="workflow"])
agent(ag1,[prov:type="programmer"])
agent(ag2,[prov:type="researcher"])
wasAssociatedWith(a,ag1,[prov:role="loggedInUser", ex:how="webapp"])
wasAssociatedWith(a,ag2,[prov:role="designer", ex:context="phd"])
</pre>
</div>



</div>

<div id="record-Start-End" class="section">
<h5><span class="secno">5.3.2.2 </span>Start and End Records</h5>

<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
 An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain attributes describing the modalities of acting/ending activities.</p>



<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the start record;</li> 
<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
</li></ul>

<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the end record;</li> 
<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
</li><li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
</li></ul>

<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this specification document.
</p>


<div class="grammar">
<span class="nonterminal">startRecord</span>&nbsp;::= 
<span class="name">wasStartedBy</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">aIdentifier</span>,
<span class="nonterminal">agIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br>
<span class="nonterminal">endRecord</span>&nbsp;::= 
<span class="name">wasEndedBy</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">aIdentifier</span>,
<span class="nonterminal">agIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>


<div class="anexample">
<p>
The following assertions</p>
<pre class="codeexample">wasStartedBy(a,ag,[ex:mode="manual"])
wasEndedby(a,ag,[ex:mode="manual"])
</pre>
<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
was started and ended by an agent, represented by record denoted by  <span class="name">ah</span>, in "manual" mode, an application specific characterization of these relations.
</p>
</div>
</div>

<div class="note">Temporal constraints for these relations remain to be
written. The temporal constraints should ensure that the agent started
its existence before the effect it may have on the activity. </div>



<!--

<section id="record-Participation">
<h4>Participation Record</h4>

<p>A <dfn id="dfn-Participation">participation record</dfn> is a representation of the involvement of an entity in an activity. A participation record can be asserted or inferred.</p>


<p>In PROV-ASN, a participation record's text matches the <span class="nonterminal">participationRecord</span> production of the grammar defined in this specification document.</p>


<div class='grammar'>
<span class="nonterminal">participationRecord</span>&nbsp;::= 
<span class="name">hadParticipant</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="name">,</span>
<span class="nonterminal">identifier</span>
<span class="name">)</span>
</div>



<p> A participation record,
written <span class="name">hadParticipant(pe,e)</span> in PROV-ASN:
<ul> 
<li> contains to identifier <span class="name">pe</span> identifying an activity record representing an activity;
<li> contains an identifier  <span class="name">e</span>  identifying an entity record, which is 
a representation of an entity involved in this activity.
</ul>

<p>An entity's participation in an activity can be by direct usage or direct control. But also, if an entity and situation are characterized in two complementary manners (and are represented by two entity records related by <span class="name">isComplementOf</span>), if one of them participates in an activity,  so does the other.  The following captures the definition of participation.</p>

<div class='constraint' id='participation'>
Given two identifiers <span class="name">pe</span> and  <span class="name">e</span>, respectively identifying  an activity record and an entity record, the record <span class="name">hadParticipant(pe,e)</span> holds <span class='conditional'>if and only if</span>:
<ul> 
<li> <span class="name">used(pe,e)</span> holds, or</li>
<li> <span class="name">wasControlledBy(pe,e)</span> holds, or</li>
<li>  <span class="name">wasComplementOf(e1,e)</span> holds for some entity record identified by <span class="name">e1</span>, and 
 <span class="name">hadParticipant(pe,e1)</span> holds  some activity record  identified by <span class="name">pe</span>.</li>
</ul>
</div>


<div class='pending'>Suggested definition for participation. This is <a href="http://www.w3.org/2011/prov/track/issues/49">ISSUE-49</a>.</div>

</section>

-->

</div>

<div id="entity-entity-agent-agent-relation" class="section">
<h4><span class="secno">5.3.3 </span>Entity-Entity or Agent-Agent Relation</h4>

<div id="record-responsibility" class="section">

<h5><span class="secno">5.3.3.1 </span>Responsibility Record</h5>

<p>To promote take-up, PROV-DM offers a mild version of responsibility
in the form of a relation to represent when an agent acted on another
agent's behalf.  So in the example of someone running a mail program,
the program is an agent of that activity and the person is also an
agent of the activity, but we would also add that the mail software
agent is running on the person's behalf.  In the other example, the
student acted on behalf of his supervisor, who acted on behalf of the
department chair, who acts on behalf of the university, and all those
agents are responsible in some way for the activity to take place but
we don't say explicitly who bears responsibility and to what
degree. </p>

<p>We could also say that an agent can act on behalf of several other
agents (a group of agents).  This would also make possible to
indirectly reflect chains of responsibility.  This also indirectly
reflects control without requiring that control is explicitly
indicated.  In some contexts there will be a need to represent
responsibility explicitly, for example to indicate legal
responsibility, and that could be added as an extension to this core
model.  Similarly with control, since in particular contexts there
might be a need to define specific aspects of control that various
agents exert over a given activity.</p>

<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the responsibility record;</li> 
<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent;</li>
<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span> acts;</li>
<li><em>activity</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
</ul>


<div class="grammar">
<span class="nonterminal">responsibilityRecord</span>&nbsp;::= 
<span class="name">actedOnBehalfOf</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">agIdentifier</span>,
<span class="nonterminal">agIdentifier</span>,
<span class="optional"><span class="nonterminal">aIdentifier</span></span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>

<div class="anexample">
In the following example, a programmer, a researcher and a funder agents are asserted.  The porgrammer and researcher are associated with a workflow activity.  The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher.
<pre class="codeexample">activity(a,[prov:type="workflow"])
agent(ag1,[prov:type="programmer"])
agent(ag2,[prov:type="researcher"])
agent(ag3,[prov:type="funder"])
wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
wasAssociatedWith(a,ag2)
actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
</pre>
</div>


</div>

<div id="Derivation-Relation" class="section">
<h5><span class="secno">5.3.3.2 </span>Derivation Record</h5>

<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world.  </p>


<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New-York, the transformation of a relational table into a linked data set, and the melting of ice into water.</p>


<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some underpinning activities performing the necessary actions resulting in such a derivation.  
However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or less precise records of derivation to be asserted.  Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>

<p>The  lack of precision may come from two sources:</p>
<ul>
<li> the number of activities that underpin a derivation is not asserted or known, or</li>
<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
</ul>


<!--
Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities <span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span class="name">e2</span>.    This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
-->


<p>Hence, given a precision axis, with values <em>precise</em> and <em>imprecise</em>, and an activity axis, with values  <em>one activity</em> and <em>n activities</em>, we can then form a matrix of possible derivations, precise or imprecise, or corresponding to one activity or  n activities.
Out of the four possibilities, PROV-DM offers three forms of derivation, while the  fourth one is not meaningful.  The following table summarises names for the three kinds of derivation, which we then explain.</p>

<div style="text-align: center;">
<table border="1" style="margin-left: auto; margin-right: auto;">
<caption>PROV-DM Derivation Type Summary</caption>
<tbody><tr><td colspan="2" rowspan="2"></td><td colspan="2">precision axis</td></tr>
<tr><td>precise</td><td>imprecise</td></tr> 
<tr><td rowspan="2">activity<br>axis</td><td>one activity</td><td><a href="#dfn-precise-1-derivation-record" class="internalDFN">precise-1 derivation record</a></td><td><a href="#dfn-imprecise-1-derivation-record" class="internalDFN">imprecise-1 derivation record</a></td></tr> 
<tr><td>n activities</td><td>---</td><td><a href="#dfn-imprecise-n-derivation-record" class="internalDFN">imprecise-n derivation record</a></td></tr> 
</tbody></table>
</div>

<ul>
<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
<li> The asserter asserts that derivation is due to exactly one activity, but other details,  whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
<li> The asserter does not know how many activities are involved in the derivation, and other details, whether known or unknown, are also not asserted. We call this an imprecise-n derivation record.</li>
</ul>

<p> We note that the fourth theoretical case of a precise derivation, where the number of activities is not known or asserted cannot occur. </p>


<p>The three kinds of derivation records are successively introduced.  To minimize the number of relation types in PROV-DM, we introduce a PROV-DM reserved attribute <span class="name">steps</span>, which allows us to distinguish the various derivation types. </p>

<p>A <dfn id="dfn-precise-1-derivation-record">precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the derivation record;</li> 
<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of  an entity record, which is a representation of the generated entity;</li>
<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of  an entity record, which is a representation of the used entity;</li>
<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
<li><em>generation</em>: an identifier  <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li> 
<li><em>usage</em>: an identifier  <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li> 
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
</ul>
<p>It is <em class="rfc2119" title="optional">optional</em> to include  the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the derivation.</p>


<p>An <dfn id="dfn-imprecise-1-derivation-record">imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the derivation record;</li> 
<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of  an entity record, which is a representation of the generated entity;</li>
<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of  an entity record, which is a representation of the used entity.</li>
<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it <em class="rfc2119" title="must">must</em> include the attribute-value pair <span class="name">prov:steps="1"</span>.</li>
</ul>
<p>An imprecise-1 derivation <em class="rfc2119" title="must">must</em> include the attribute <span class="name">prov:steps</span>,  since it is the only means to distinguish this record from an imprecise-n derivation record.</p>


<p>An <dfn id="dfn-imprecise-n-derivation-record">imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the derivation record;</li> 
<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of  an entity record, which is a representation of the generated entity;</li>
<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of  an entity record, which is a representation of the used entity.</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="n"</span>.</li>
</ul>
<p>It is <em class="rfc2119" title="optional">optional</em> to include  the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="n"</span>.</p> 


<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property holds.</p>


<p>In PROV-ASN, a derivation record's text matches the <span class="nonterminal">derivationRecord</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">derivationRecord</span>&nbsp;::= 
<span class="nonterminal">precise-1-derivationRecord</span>
| <span class="nonterminal">imprecise-1-derivationRecord</span>
| <span class="nonterminal">imprecise-n-derivationRecord</span><br>
<br>
<span class="nonterminal">precise-1-derivationRecord</span>&nbsp;::=  
<span class="name">wasDerivedFrom</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">aIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">gIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">uIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span><br>
<span class="nonterminal">imprecise-1-derivationRecord</span>::=  
<span class="name">wasDerivedFrom</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">attribute-values</span>
<span class="name">)</span>
<br>
<span class="nonterminal">imprecise-n-derivationRecord</span>::=  
<span class="name">wasDerivedFrom</span>
<span class="name">(</span>
<span class="optional"> <span class="nonterminal">identifier</span>,</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>
<div class="note">
The grammar should make it clear that attribute <span class="name">prov:steps="1"</span> is required for imprecise-1-derivationRecord.<br>
  PM: suggestion -- remove the distinction between imprecise-1 and imprecise-n in the grammar and instead explain that the qualification (1 vs n) is through attribute prov:steps.
</div>

<div class="anexample">
<p>The following assertions state the existence of derivations.</p>
<pre class="codeexample">wasDerivedFrom(e5,e3,a4,g2,u2,[])
wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="1"])

wasDerivedFrom(e3,e2,[prov:steps="1"])

wasDerivedFrom(e2,e1,[])
wasDerivedFrom(e2,e1,[prov:steps="n"])
</pre>
<p>
The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
 derived the
entity denoted by <span class="name">e5</span> and generated it according to generation record
 <span class="name">g2</span>. 

The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between  <span class="name">e2</span> and  <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation.
</p>
</div>


<p>An precise-1  derivation record is richer  than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications hold.</p>
<div class="constraint" id="derivation-implications">
Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class="conditional">if</span> the assertion  <span class="name">wasDerivedFrom(e2, e1, a, g2, u1, attrs)</span>
 holds for some generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, then <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> also holds.<br>

Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class="conditional">if</span> the assertion  <span class="name">wasDerivedFrom(e2, e1, [prov:steps="1"] ∪ attrs)</span>
 holds, then <span class="name">wasDerivedFrom(e2,e1,attrs)</span> also holds.<br>
 </div>



<p>
</p><p>If a derivation record holds for <span class="name">e2</span> and <span class="name">e1</span>, then 
this means that the entity represented by entity record identified by <span class="name">e1</span> has an influence on the entity represented entity record identified by <span class="name">e2</span>,
  which at the minimum implies temporal ordering, specified as follows.
First, we consider one-activity derivations.</p>

<div class="interpretation" id="derivation-usage-generation-ordering">Given an activity record identified by <span class="name">a</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, generation record identified by <span class="name">g2</span>, and usage record identified by <span class="name">u1</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,a,g2,u1,attrs)</span>
or <span class="name">wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs)</span> holds, <span class="conditional">then</span>
the following temporal constraint holds:
the <a title="entity usage event" href="#dfn-usage-event" class="internalDFN">usage</a>
of entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation</a> of
the entity denoted by <span class="name">e2</span>.
</div>

<p>Then, imprecise-n derivations.</p>

<div class="interpretation" id="derivation-generation-generation-ordering">
Given two entity records denoted by <span class="name">e1</span> and <span class="name">e2</span>, <span class="conditional">if</span> the record <span class="name">wasDerivedFrom(e2,e1,[prov:steps="n"] ∪ attrs)</span>
 holds, <span class="conditional">then</span> the following temporal constraint holds:
the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of the entity denoted by <span class="name">e1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="entity generation event" href="#dfn-generation-event" class="internalDFN">generation event</a> of
the entity  denoted by <span class="name">e2</span>.
  </div>

<p>Note that temporal ordering is between generations of <span class="name">e1</span>
and <span class="name">e2</span>, as opposed to precise-1 derivation,
which implies temporal ordering between the usage of <span class="name">e1</span> and
generation of <span class="name">e2</span>.  Indeed, in the case of
imprecise-n derivation, nothing is known about the usage of <span class="name">e1</span>,
since there is no associated activity.</p>




<p>The imprecise-1 derivation has the same meaning as the  precise-1
 derivation, except that an activity  
 is known to exist, though it does not need to be 
asserted.  This is formalized by the following inference rule,
referred to as <em>activity introduction</em>:</p>
<div class="constraint" id="activity-introduction">
<span class="conditional">If</span> <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class="conditional">then</span> there exist an activity record identified by <span class="name">a</span>, a usage record identified by <span class="name">u</span>, and a generation record identified by <span class="name">g</span>
such that:
<pre class="codeexample">activity(a,aAttrs)
wasGeneratedBy(g,e2,a,gAttrs)
used(u,a,e1,uAttrs)
</pre>
for sets of attribute-value pairs <span class="name">gAttrs</span>, <span class="name">uAttrs</span>, and <span class="name">aAttrs</span>.
</div>





<p>
Note that inferring derivation from usage and generation does not hold
in general. Indeed, when a generation <span class="name">wasGeneratedBy(g, e2, a, attrs2)</span>
<a href="#dfn-precedes" class="internalDFN">precedes</a> <span class="name">used(u, a, e1, attrs1)</span>, for
some <span class="name">e1</span>, <span class="name">e2</span>, <span class="name">attrs1</span>, <span class="name">attrs2</span>, and <span class="name">a</span>, one
cannot infer derivation <span class="name">wasDerivedFrom(e2, e1, a, g, u)</span>
or <span class="name">wasDerivedFrom(e2,e1)</span> since 
of <span class="name">e2</span> cannot possibly be determined by
of <span class="name">e1</span>, given the creation of <span class="name">e2</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the use
of <span class="name">e1</span>.
</p>

<div class="note">The following property holds for account where
generation-unicity applies. Move it to separate section with all
related material. </div>

<p>A further inference is permitted from the imprecise-1 derivation record: </p>
<div class="constraint" id="derivation-use">
<p>Given an activity record identified by <span class="name">pe</span>, entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and set of attribute-value pairs <span class="name">attrs2</span>,
<span class="conditional">if</span> <span class="name">wasDerivedFrom(e2,e1, [prov:steps="1"])</span> and <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> hold, <span class="conditional">then</span> <span class="name">used(pe,e1,attrs1)</span> also holds
for some set of attribute-value pairs <span class="name">attrs1</span>.
</p></div>
<p>This inference is justified by the fact that the entity represented by entity record identified by <span class="name">e2</span> is generated by at most one activity in a given account (see <a href="#generation-unicity">generation-unicity</a>). Hence,  this activity record is also the one referred to in the usage record of <span class="name">e1</span>. 
</p>



<p>We note that the converse inference, does not hold.
From <span class="name">wasDerivedFrom(e2,e1)</span> and <span class="name">used(pe,e1)</span>, one cannot
derive <span class="name">wasGeneratedBy(e2,pe,attrs2)</span> because identifier <span class="name">e1</span> may occur in usage records referring to 
many activity records, but they may not be referred to in generation records containing identifier <span class="name">e2</span>.</p>




<div class="issue">Should derivation have a time? Which time? This is   <a href="http://www.w3.org/2011/prov/track/issues/43">ISSUE-43</a>.</div>

</div>


<div id="record-complement-of" class="section">

<h5><span class="secno">5.3.3.3 </span>Complementarity Record</h5>

<div class="note">While the working group recognizes the importance of the complementarity record concept, its name and its exact semantics are still being discussed.  
</div>


<p>A <dfn id="complementOf">complementarity record</dfn> is a relationship between two entities stated to have compatible characterization over some continuous interval between two events.</p>

<!-- PAOLO, which event do you refer to? <a>event</a>??  -->


<p>
The rationale for introducing this relationship is that in general, at any given time, for an entity in the world, there may be multiple ways of characterizing it, and hence multiple representations can be asserted by different asserters. In the example that follows, suppose thing "Royal Society" is represented by two asserters, each using a different set of attributes. If the asserters agree that both representations refer to "The  Royal Society", the question of whether any correspondence can be established between the two representations arises naturally. This is particularly relevant when (a) the sets of attributes used by the two representations overlap partially, or (b) when one set is subsumed by the other. In both these cases, we have a situation where each of the two asserters has a partial view of "The  Royal Society", and establishing a correspondence between them on the shared attributes is beneficial, as in case (a) each of the two representation <em>complements</em> the other, and in case (b) one of the two (that with the additional attributes) complements the other.</p>

<p>This intuition is made more precise by considering the entities that form the representations of entities at a certain point in time. 

An entity record represents, by means of attribute-value pairs, a thing and its situation in the world, which remain constant over a characterization interval.
As soon as the thing's situation changes, this marks the end of the characterization interval for the entity record representing it. The thing's novel situation is represented by an attribute with a new value, or an entirely different set of  attribute-value pairs, embodied in another entity record, with a new characterization interval. Thus, if we overlap the timelines (or, more generally, the sequences of value-changing events) for the two entities, we can hope to establish correspondences amongst the entity records that represent them at various points along that events line. The figure below illustrates this intuition.</p>

<div style="text-align: center;">
<img src="complement-of.png" alt="illustration complementOf">
</div>

<p>
Relation <em>complement-of</em> between two entity records is intended to capture these correspondences, as follows. Suppose entity records A and B share a set P of attributes, and each of them has other attributes in addition to P. If the values assigned to each attribute in P are <em>compatible</em> between A and B, then we say that <em>A is-complement-of B</em>, and <em>B is-complement-of A</em>, in a symmetrical fashion. In the particular case where the set P of attributes of B is a strict superset of A's attributes, then we say that <em>B is-complement-of A</em>, but in this case the opposite does not hold. In this case, the relation is not symmetric.  (as a special case, A and B may not share any attributes at all, and yet the asserters may still stipulate that they are representing the same thing "Royal Society". The symmetric relation may hold trivially in this case).</p>

<p>The term <em>compatible</em> used above means that a mapping can be established amongst the values of attributes in P and found in the two entity expession. This generalizes to the case where attribute sets P1 and P2 of A, and B, respectively, are not identical but they can be mapped to one another. The simplest case is the identity mapping, in which A and B share attribute set P, and furthermore the values assigned to attributes in P match exactly.</p>

<p>It is important to note that the relation holds only for the characterization intervals of the entity expessions involved As soon as one attribute changes value in one of them, new correspondences need to be found amongst the new entities. Thus, the relation has a validity span that can be expressed in terms of the event lines of the entity.</p>

<!--
The "IVP of" relationship is designed to represent pairs of entities that correspond to each other. By their own nature, an entity remains valid only as long as all of its attributes do not change their value. It follows that the correspondence "B IVP of A" is only valid within the time interval during which such invariance attribute holds for both A and B. When any of the attribute values change in either A or B, those entities are replaced by new ones, and a new correspondence may be established. Thus, "IVP of" is defined relative to the intersection of the temporal intervals for which A and B are valid.
-->



<p>A complementarity record is written <span class="name">wasComplementOf(e2,e1)</span>, where <span class="name">e1</span> and <span class="name">e2</span> are  two identifiers denoting entity records.</p>


<div class="anexample">
<p>The following example illustrates the entity "Royal Society"and its perspectives at various points in time.</p>
<pre class="codeexample">entity(rs,[ex:created=1870])

entity(rs_l1,[prov:location="loc2"])
entity(rs_l2,[prov:location="The Mall"])

entity(rs_m1,[ex:membership=250, ex:year=1900])
entity(rs_m2,[ex:membership=300, ex:year=1945])
entity(rs_m3,[ex:membership=270, ex:year=2010])

wasComplementOf(rs_m3, rs_l2)
wasComplementOf(rs_m2, rs_l1)
wasComplementOf(rs_m2, rs_l2)
wasComplementOf(rs_m1, rs_l1)

wasComplementOf(rs_m3, rs)
wasComplementOf(rs_m2, rs)
wasComplementOf(rs_m1, rs)
wasComplementOf(rs_l1, rs)
wasComplementOf(rs_l2, rs)
</pre>
</div>



<div class="constraint" id="wasComplementOf-necessary-cond">
An assertion "wasComplementOf(B,A)" holds over the temporal intersection of A and B, <span class="conditional">only if</span>: 
<ol>
<li> if a mapping can be established from an attribute X of entity record identified by B to an attribute Y of entity record identified by A, then the values of A and B must be consistent with that mapping;</li>
<li>entity record identified by B has some attribute that entity record identified by A does not have.</li>
</ol>
 </div>

<p>The complementarity relation is not transitive. Let us consider identifiers <span class="name">e1</span>, <span class="name">e2</span>, and <span class="name">e3</span> identifying three entity records such that 
 <span class="name">wasComplementOf(e3,e2)</span> and <span class="name">wasComplementOf(e2,e1)</span> hold.  The record <span class="name">wasComplementOf(e3,e1)</span> may not hold because the characterization intervals of the denoted entity records may not overlap.</p>


<p>In PROV-ASN, a complementarity record's text matches the <span class="nonterminal">complementarityRecord</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">complementarityRecord</span>&nbsp;::=  
<span class="name">wasComplementOf</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span> 
<span class="name">,</span> 
<span class="nonterminal">eIdentifier</span> 
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> <br>
|
<span class="name">wasComplementOf</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span> 
<span class="name">,</span>
<span class="nonterminal">accIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">eIdentifier</span> 
<span class="name">,</span> 
<span class="nonterminal">accIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>


<p>
An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to link two entity record identifiers that are appear in different accounts. (In particular, the entity record identifiers in two different account are allowed to be the same.). When account identifiers are not available, then the linking of entity records through complementarity can only take place within the scope of a single account.
</p>


<div class="anexample">
<p>In the following example, the same description of the Royal Society is structured according to two different accounts.   In the second account, we find a complementarity record linking <span class="name">rs_m1</span>  in account <span class="name">ex:acc2</span>  to
<span class="name">rs</span>  in account <span class="name">ex:acc1</span>.
</p><pre class="codeexample">account(ex:acc1,
        http://example.org/asserter1, 

    ...
    entity(rs,[ex:created=1870])
    ...
    )


account(ex:acc2,
        http://example.org/asserter2, 

    ...
    entity(rs_m1,[ex:membership=250, ex:year=1900])
    ...
    wasComplementOf(rs_m1, ex:acc2, rs, ex:acc1)

)
</pre>
</div>



<div class="note">It is suggested that the name 'wasComplementOf' does not capture the meaning of this relation adequately. No concrete suggestion has been made so far.
Furthermore, there is a suggestion that an alternative relation that is transitive may also be useful.
This is raised in the following <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Sep/0315.html">email</a>.</div>



<div class="issue">A discussion on alternative definition of wasComplementOf has not reached a satisfactory conclusion yet. This is <a href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a></div>



<div class="pending"> Comments on ivpof in <a href="http://www.w3.org/2011/prov/track/issues/57">ISSUE-57</a>.</div>


</div>
</div>


<!-- 
<section>
<h4>Transitive Derivation Record</h4>


<p>
If <span class="name">wasDerivedFrom(e2,e1)</span> holds because attribute <span class="name">a2.1</span> of <span class="name">e2</span> is determined by attribute <span class="name">a1.1</span> of <span class="name">e1</span>,
and if <span class="name">wasDerivedFrom(e3,e2)</span> holds because attribute <span class="name">a3.1</span>of <span class="name">e3</span> is determined by  attribute <span class="name">a2.2</span> of <span class="name">e1</span>, it is not necessarily the case that an attribute of <span class="name">e3</span> is determined by an attribute of <span class="name">e1</span>; so, an asserter may not be able to assert <span class="name">wasDerivedFrom(e3,e1)</span>, since it would fail to satisfy constraint <a href="#derivation-attributes">derivation-attributes</a>.  Hence, the constraint on attributes as expressed in <a href="#derivation-attributes">derivation-attributes</a> invalidates transitivity in the general case.
</p>

<p>However, there is sense that <span class="name">e3</span> still depends on <span class="name">e1</span>, since <span class="name">e3</span> could not be generated without <span class="name">e1</span> existing. Hence, we introduce a weaker notion of derivation record, which is transitive.</p>

A transitive derivation record, written <span class="name">dependedOn(e2, e1)</span> in PROV-ASN:
<ul>
<li> contains an identifier <span class="name">e2</span>, denoting an entity record, which represents the entity that is the result of the derivation;
<li> contains an identifier <span class="name">e1</span>, denoting an entity record, which represents the entity that the derivation relies upon.
</ul>
<p>The record <span class="name">dependedOn</span> can only be inferred; in other words, it cannot be asserted. It is
transitive by definition and relies on the previously defined derivation assertions for its
base case.</p>

<div class='constraint' id='transitive-derivation'>
<ul> 
<li><span class='conditional'>If</span> <span class="name">wasDerivedFrom(e2,e1)</span> or <span class="name">wasDerivedFrom(e2,e1,pe,attrs2,attrs1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
<li><span class='conditional'>If</span> <span class="name">wasEventuallyDerivedFrom(e2,e1)</span> holds, <span class='conditional'>then</span> <span class="name">dependedOn(e2,e1)</span> holds.</li>
<li><span class='conditional'>If</span> <span class="name">dependedOn(e3,e2)</span> and <span class="name">dependedOn(e2,e1)</span> hold, <span class='conditional'>then</span> <span class="name">dependedOn(e3,e1)</span> holds.</li>
</ul>
</div>

</section>
-->







<div id="record-annotation" class="section">
<h4><span class="secno">5.3.4 </span>Annotation Record</h4>


<p>An <dfn id="dfn-annotation">annotation record</dfn> establishes a link between an identifiable PROV-DM record and a note record referred to by its identifier.  Multiple note records can be associated with a given PROV-DM record; symmetrically, multiple PROV-DM records can be associated with a given note record.  Since note records have identifiers,  they can also be annotated. The annotation mechanism (with note record and the annotation record) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p> 

<p>An annotation record, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN, has the following constituents:</p>
<ul>
<li><em>record</em>: an identifier <span class="name">r</span> of the record being annnotated;</li>
<li><em>note</em>: an identifier <span class="name">n</span> of a note record;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>


<p>In PROV-ASN, a note record's text matches the <span class="nonterminal">noteRecord</span> production of the grammar defined in this specification document.
</p>

<div class="grammar">
<span class="nonterminal">annotationRecord</span>&nbsp;::=  
<span class="name">hasAnnotation</span>
<span class="name">(</span>
<span class="nonterminal">identifier</span>
<span class="name">,</span>
<span class="nonterminal">nIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>

<p>The interpretation of notes is application-specific. See Section <a href="#record-note">Note</a> for a discussion of the difference between note attributes and other records attributes. We also note the present tense in this term to indicate that it may not denote something in the past.</p>

<div class="anexample">
<p>
The following records</p>
<pre class="codexample">entity(e1,[prov:type="document"])
entity(e2,[prov:type="document"])
activity(a,transform,t1,t2,[])
used(u1,a,e1,[ex:file="stdin"])
wasGeneratedBy(e2, a, [ex:file="stdout"])

note(n1,[ex:icon="doc.png"])
hasAnnotation(e1,n1)
hasAnnotation(e2,n1)

note(n2,[ex:style="dotted"])
hasAnnotation(u1,n2)
</pre>
<p>assert the existence of two  documents in the world  (attribute-value pair: <span class="name">prov:type="document"</span>) represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these records with a note indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>. It also asserts an activity, its usage of the first entity, and its generation of the second entity. The <span class="name">usage</span> record is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage record was provided with an identifier <span class="name">u1</span>, which was then referred to in <span class="name">hasAnnotation(u1,n2)</span>.
</p>
</div>


</div>
</div>

<div id="bundle" class="section">
<h3><span class="secno">5.4 </span>Bundle</h3>

<p>In this section, two constructs are introduced to group
PROV-DM records.  The first
one, <a href="#dfn-Account" class="internalDFN">account record</a> is itself a
record, whereas the second
one <a href="#dfn-RecordContainer" class="internalDFN">record container</a> is not.
</p>


<div id="record-Account" class="section">
<h4><span class="secno">5.4.1 </span>Account Record</h4>

<p>In PROV-DM, an <dfn id="dfn-Account">account record</dfn> is a wrapper of records with a dual purpose:  </p> 
<ul>
<li> It is the mechanism by which attribution of provenance can be assserted; it allows asserters to bundle up their assertions, and assert suitable attribution;
</li><li> It provides a scoping mechanism for record identifiers and for some contraints (such as
   <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>).
</li></ul>



<p>An account record, written <span class="name">account(id, assertIRI, recs, attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>id</em>: an identifier <span class="name">id</span>  that identifies this account globally;</li>
<li><em>asserter</em>: an IRI, denoted by <span class="name">assertIRI</span>, to identify an asserter; such IRI has no specific interpretation in the context of PROV-DM;</li>
<li><em>records</em>: a set <span class="name">recs</span> of provenance records;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>

<p>In PROV-ASN, an account record's text matches the <span class="nonterminal">accountRecord</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">accountRecord</span>&nbsp;::=  
<span class="name">account</span> 
<span class="name">(</span> 
<span class="nonterminal">identifier</span> 
<span class="name">,</span> 
<span class="nonterminal">asserter</span> 
<span class="name">,</span> 
<span class="plus">
<span class="nonterminal">record</span> </span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>

<div class="note">
Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI and its interpretation is outside PROV-DM. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM assertions.  The editors seek inputs on how to resolve this issue. </div>

<div class="anexample">
<p>
The following account record</p>
<pre class="codeexample">account(ex:acc0,
        http://example.org/asserter, 
          entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
          ...
          wasDerivedFrom(e2,e1)
          ...
          activity(a0,create-file,t)
          ...
          wasGeneratedBy(e0,a0,[])     
          ...
          wasAssociatedWith(a4, ag5, [prov:role="communicator"])  )
</pre>
<p>contains the set of provenance records of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://example.org/asserter</span>, and is identified by identifier <span class="name">ex:acc0</span>.
</p>
</div>

<p>Account records constitue a scope for record identifiers. A record identifier within the scope of an account is intended to denote a single record. However, nothing prevents an asserter from asserting an account containing, for example,  multiple entity records with a same identifier but different attribute-values. In that case, they should be understood as a single entity record with this identifier and the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>

<div class="constraint" id="identified-entity-in-account">
Given an entity record identifier <span class="name">e</span>,  two sets of attribute-values denoted by <span class="name">av1</span> and <span class="name">av2</span>, 
 two entity records  <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account  are equivalent to the entity record <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set of attribute-value pairs formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
</div>

<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity records with a same identifier within a given account, it does not guarantee that the entity record formed with the union of all attribute-value pairs is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity record, as illustrated by the following example.</p>

<div class="anexample">
<p>
In the following account record, we find two entity records with a same identifier <span class="name">e</span>.</p>
<pre class="codeexample">account(ex:acc1,
        http://example.org/id,
          entity(e,[prov:type="person", ex:age=20])
          entity(e,[prov:type="person", ex:age=30])
          ...)
</pre>
<p>Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity record containing the attribute-value pairs <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific and outside the scope of this specification.
</p></div>

<p>Account records can be nested since  an account record can occur among the records being wrapped by another account. </p>


<p>
An account is said to be well-formed if
it satisfies the constraints  <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>

<p> The union of two accounts is another account, 
containing the unions of their respective records, where
 records with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
accounts are not
closed under union because the
constraint <a href="#generation-unicity">generation-unicity</a> may no
longer be satisfied in the resulting union.  </p>

<div class="anexample">
<p>
Indeed, let us consider another account record</p>
<pre class="codeexample">account(ex:acc2,
        http://example.org/asserter2, 
          entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
          ...
          activity(a1,create-file,t1)
          ...
          wasGeneratedBy(e0,a1,[ex:fct="create"])     
          ... )
</pre>
<p>with identifier <span class="name">ex:acc2</span>, containing assertions by asserter by <span class="name">http://example.org/asserter2</span> stating that the entity represented by entity record identified by <span class="name">e0</span> was generated by an activity represented by activity record identified by <span class="name">a1</span> instead of <span class="name">a0</span> in the previous account <span class="name">ex:acc0</span>.  If accounts <span class="name">ex:acc0</span> and <span class="name">ex:acc2</span> are merged together, the resulting set of records violates <a href="#generation-unicity">generation-unicity</a>.</p>
</div>

<p>Account records constitute a scope for record identifiers. Since accounts can be nested,  scopes can also be nested; thus, the scope of record identifiers should be understood in the context of such nested scopes.  When a record with an identifier occurs directly within an account, then its identifier denotes this record in the scope of this account, except in sub-accounts where records with the same identifier occur. </p>

<div class="anexample">
<p>
The following account record is inspired from section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>. This account, identified by <span class="name">ex:acc3</span>, declares entity record with identifier <span class="name">e0</span>, which is being referred to in the nested account <span class="name">ex:acc4</span>. The scope of identifier <span class="name">e0</span> is account <span class="name">ex:acc3</span>, including subaccount <span class="name">ex:acc4</span>.</p>
<pre class="codeexample">account(ex:acc3,
        http://example.org/asserter1, 
          entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
          activity(a0,create-file,t)
          wasGeneratedBy(e0,a0,[])  
          account(ex:acc4,
                  http://example.org/asserter2,
                    entity(e1, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice", ex:content="" ])
                    activity(a0,copy-file,t)
                    wasGeneratedBy(e1,a0,[ex:fct="create"])
                    wasComplementOf(e1,e0)))
</pre>
<p>Alternatively, an activity record identified by <span class="name">a0</span> occurs in each of the two accounts. Therefore,  each activity record is asserted in a separate scope, and therefore may represent different activities in the world.
</p>
</div>

<p>The account record is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. The annotation mechanism can be used for this purpose, but how general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>


</div>

<div id="RecordContainer" class="section">
<h4><span class="secno">5.4.2 </span>Record Container</h4>

<p>A <dfn id="dfn-RecordContainer">record container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM records. A record container is not a record, but can be exploited to return assertions in response to a request for the provenance of something ([<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-PAQ">PROV-PAQ</a></cite>]). </p> 

<p>


</p><p>A record container, written <span class="name">container decls  recs endContainer</span> in PROV-ASN, contains:
</p><ul>
<li><em>namespaceDeclarations</em>: a set <span class="name">decls</span> of namespace declarations, declaring namespaces and associated prefixes, which can be used in <a title="attribute" href="#dfn-attribute" class="internalDFN">attributes</a> and  <a title="identifier" href="#dfn-identifier" class="internalDFN">identifiers</a> occurring inside  <span class="name">recs</span>;</li>
<li><em>records</em>:  a non-empty set of records <span class="name">recs</span>.</li>
</ul>
<p>All the records in <span class="name">recs</span> are implictly wrapped in a default account, scoping all the record identifiers they declare directly, and constituting a toplevel account, in the hierarchy of accounts.  Consequently, every provenance record is always expressed in the context of an account, either explicitly in an asserted account, or implicitly in a container's default account.</p>

<p>In PROV-ASN, a record container's text matches the <span class="nonterminal">recordContainer</span> production of the grammar defined in this specification document.</p>


<div class="grammar">
<span class="nonterminal">recordContainer</span> ::=  
<span class="name">container</span> 
<span class="nonterminal">namespaceDeclarations</span> 
<span class="plus"> <span class="nonterminal">record</span> </span>
<span class="name">endContainer</span> 
</div>


<div class="anexample">
<p>
The following container </p>
<pre class="codeexample">container
  prefix ex: http://example.org/,

  account(ex:acc1,http://example.org/asserter1,...)
  account(ex:acc2,http://example.org/asserter1,...)
endContainer
</pre>
<p> illustrates how two accounts with identifiers <span class="name">ex:acc1</span> and <span class="name">ex:acc2</span> can be returned in a PROV-ASN serialization of the provenance of something.
</p>
</div>


<div class="pending">Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>


<div class="pending">Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>


</div>
</div>


<div id="sub-record" class="section">
<h3><span class="secno">5.5 </span>Further Terms in Records</h3>

This section further terms in PROV-DM records.



<div id="record-attribute" class="section">
<h4><span class="secno">5.5.1 </span>Attribute</h4>

<p>An <dfn id="dfn-attribute">attribute</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
 by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>

<div class="grammar">
<span class="nonterminal">attribute</span>&nbsp;::=  <span class="nonterminal">qualifiedName</span><br>
<span class="nonterminal">qualifiedName</span> &nbsp;::= <span class="nonterminal">prefixedName</span> | <span class="nonterminal">unprefixedName</span><br>
<span class="nonterminal">prefixedName</span> &nbsp;::= <span class="nonterminal">prefix</span> <span class="name">:</span> <span class="nonterminal">localPart</span><br>
<span class="nonterminal">unprefixedName</span> &nbsp;::= <span class="nonterminal">localPart</span><br>
<span class="nonterminal">prefix</span> &nbsp;::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em><br>
<span class="nonterminal">localPart</span> &nbsp;::= <em>a name without colon compatible with the <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NC_NAME</a> production [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>]</em>
</div>

<p>A qualified name's prefix is <em class="rfc2119" title="optional">optional</em>. If a prefix occurs in a
 qualified name, it refers to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
 record container.  In the absence of prefix, the qualified name
 refers to the default namespace declared in the container.</p>

<div class="note">Note that XML NC_NAME don't allow local identifiers to start with a number.  Instead, should we use the productions used in SPARQL or TURTLE?</div>

<p>From this specification's viewpoint, the interpretation of an attribute declared in a namespace other than prov-dm is out of
scope.</p>

<p>The PROV data model introduces a fixed set of attributes in the <a href="#prov-dm-namespace">PROV-DM namespace</a>:</p>
<ul>
<li> The attribute <dfn id="dfn-role"><span class="name">prov:role</span></dfn>  denotes the function of an entity with respect to an activity, in the context of a usage, generation, activity association, start, end record. The value associated with a <span class="name">prov:role</span> attribute <em class="rfc2119" title="must">must</em> be conformant with  <span class="nonterminal">Literal</span>.

<div class="anexample">
<p>The following start record describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
<pre class="codeexample">   wasStartedBy(a,ag, [prov:role="program-operator"])
</pre>
</div>
 </li>

<li> The attribute <dfn id="dfn-type"><span class="name">prov:type</span></dfn>  provides further typing information for the element or relation asserted in the record. The value associated with a <span class="name">prov:type</span> attribute <em class="rfc2119" title="must">must</em> be conformant with  <span class="nonterminal">Literal</span>. 

<div class="anexample">
<p>The following record declares an agent of type software agent</p>
<pre class="codeexample">   agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
</pre>
</div>


</li><li> The  attribute <dfn id="dfn-steps"><span class="name">prov:steps</span></dfn>  defines the level of precision associated with a derivation record. The value associated with a <span class="name">prov:steps</span> attribute  <em class="rfc2119" title="must">must</em> be   <span class="name">"1"</span> or <span class="name">"n"</span>. </li>

</ul>
</div>



<div id="record-identifier" class="section">
<h4><span class="secno">5.5.2 </span>Identifier</h4>


<p>An <dfn id="dfn-identifier">identifier</dfn> is a <em>qualified name</em>. A qualified name can be mapped into an IRI
 by concatenating the IRI associated with the prefix and the local part (see detailed rule in [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>], Section <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#QSynIRI">4.1.1</a>).</p>

<div class="grammar">
<span class="nonterminal">identifier</span>&nbsp;::=  <span class="nonterminal">qualifiedName</span><br>
<span class="nonterminal">eIdentifier</span>&nbsp;::=  <span class="nonterminal">identifier</span>  <em>(intended to denote an entity record)</em><br>
<span class="nonterminal">aIdentifier</span>&nbsp;::=  <span class="nonterminal">identifier</span>  <em>(intended to denote an activity record)</em><br>
<span class="nonterminal">agIdentifier</span>&nbsp;::=  <span class="nonterminal">identifier</span>  <em>(intended to denote an agent record)</em><br>
<span class="nonterminal">gIdentifier</span>::=  <span class="nonterminal">identifier</span> <em>(intended to denote a generation record)</em><br>
<span class="nonterminal">uIdentifier</span>::=  <span class="nonterminal">identifier</span> <em>(intended to denote a usage record)</em><br>
<span class="nonterminal">nIdentifier</span>::=  <span class="nonterminal">identifier</span> <em>(intended to denote a note record)</em><br>
<span class="nonterminal">accIdentifier</span>::=  <span class="nonterminal">identifier</span> <em>(intended to denote an account record)</em>
</div>


</div>

<div id="record-literal" class="section">
<h4><span class="secno">5.5.3 </span>Literal</h4>

<p>
A PROV-DM Literal represents a data value such as a particular string
or number.  A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
</p>

<p>In PROV-ASN, a Literal's text matches the <span class="nonterminal">Literal</span> production of the grammar defined in this specification document.</p>

<div class="grammar">
<span class="nonterminal">Literal</span> &nbsp;::= <span class="nonterminal">typedLiteral</span> | <span class="nonterminal">convenienceNotation</span> <br>
<span class="nonterminal">typedLiteral</span> ::= <span class="nonterminal">quotedString</span> <span class="name">%%</span> <span class="nonterminal">datatype</span><br>
<span class="nonterminal">datatype</span> ::= <span class="nonterminal">qualifiedName</span><br>
<span class="nonterminal">convenienceNotation</span> &nbsp;::= <span class="nonterminal">stringLiteral</span> | <span class="nonterminal">intLiteral</span><br>
<span class="nonterminal">stringLiteral</span> ::= <span class="nonterminal">quotedString</span><br>
<span class="nonterminal">quotedString</span> ::= <em>a finite sequence of characters in which " (U+22) and \ (U+5C) occur only in pairs of the form \" (U+5C, U+22) and \\ (U+5C, U+5C), enclosed in a pair of " (U+22) characters</em><br>
<span class="nonterminal">intLiteral</span> ::= <em>a finite-length sequence of decimal digits (#x30-#x39) with an optional leading negative sign (-)</em>
</div>

<p>The non terminals <span class="nonterminal">stringLiteral</span> and
<span class="nonterminal">intLiteral</span>
are syntactic sugar for quoted strings with datatype <span class="name">xsd:string</span> and <span class="name">xsd:int</span>, respectively.
</p>

<p> In particular, a PROV-DM Literal may be an IRI-typed string (with datatype <span class="name">xsd:anyURI</span>);  such IRI has no specific interpretation in the context of PROV-DM.</p>


<div class="anexample">
<p>
The following examples respectively are the string "abc" (expressed using the convenience notation), the string "abc", the integer number 1, the integer number 1 (expressed using the convenience notation) and the IRI "http://example.org/foo".
</p><pre class="codeexample">  "abc"
  "abc" %% xsd:string
  "1" %% xsd:int
  1
  "http://example.org/foo" %% xsd:anyURI
</pre>
The following example shows a literal of type <span class="name">xsd:QName</span> (see
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>]).
The prefix <span class="name">ex</span>  <em class="rfc2119" title="must">must</em> be bound to a <a href="#dfn-namespace" class="internalDFN">namespace</a> declared in the
 record container.
<pre class="codeexample">  "ex:value" %% xsd:QName
</pre>
</div>



<div class="note">Should we define structural equivalence of literals as in OWL2? [<cite><a class="bibref" rel="biblioentry" href="#bib-OWL2-SYNTAX">OWL2-SYNTAX</a></cite>]
(see section <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Literals">Literals</a>).
</div>

</div>




<div id="record-Time" class="section">
<h4><span class="secno">5.5.4 </span>Time</h4>

<p><dfn id="dfn-time">Time instants</dfn> are defined according to xsd:dateTime [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</p> 



<p>It is <em class="rfc2119" title="optional">optional</em> to assert time in usage, generation, and activity records.</p>




</div>

<div id="record-Asserter" class="section">
<h4><span class="secno">5.5.5 </span>Asserter</h4>

<p>An <dfn id="dfn-asserter">asserter</dfn> is a creator of PROV-DM records. An asserter is denoted by an IRI. Such IRI has no specific interpretation in the context of PROV-DM.</p> 

<div class="grammar">
<span class="nonterminal">asserter</span>&nbsp;::=  <span class="nonterminal">IRI</span><br>
<span class="nonterminal">IRI</span>&nbsp;::=  <em>an IRI compatible with production IRI in [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>], enclosed in a pair of &lt; (U+3C) and &gt; (U+3E) characters </em>
</div>

<div class="note">
Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as IRI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM.  We seek inputs on how to resolve this issue. </div>

</div>

<div id="record-NamespaceDeclaration" class="section">
<h4><span class="secno">5.5.6 </span>Namespace Declaration</h4>

<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [<cite><a class="bibref" rel="biblioentry" href="#bib-IRI">IRI</a></cite>]. In PROV-DM, attributes, identifiers, and literals of with datatype <span class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>


<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace. 
A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration refers to this namespace.</p>

<div class="grammar">
<span class="nonterminal">namespaceDeclarations</span>&nbsp;::=  
 |  <span class="group"><span class="nonterminal">defaultNamespaceDeclaration</span> | <span class="nonterminal">namespaceDeclaration</span></span> <span class="star"> <span class="nonterminal">namespaceDeclaration</span></span><br>
<span class="nonterminal">namespaceDeclaration</span>&nbsp;::=  
<span class="name">prefix</span> <span class="nonterminal">prefix</span> <span class="nonterminal">IRI</span><br>
<span class="nonterminal">defaultNamespaceDeclaration</span>&nbsp;::=  
 <span class="name">default</span> <span class="nonterminal">IRI</span> <br>
</div>
</div>


<div id="record-RecipeLink" class="section">
<h4><span class="secno">5.5.7 </span>Recipe Link</h4>


<p>A <dfn id="dfn-RecipeLink">recipe link</dfn> is an association between an activity record and a process specification that underpins the represented activity. Such IRI has no specific interpretation in the context of PROV-DM.
</p>

<div class="grammar">
<span class="nonterminal">recipeLink</span>&nbsp;::=  <span class="nonterminal">IRI</span>
</div>

<p>
It is <em class="rfc2119" title="optional">optional</em> to assert recipe links in activities.
</p>


<p>
Process specifications, as referred to by recipe links, are out of scope of this specification.
</p>

<div class="note">
By defining a recipe link as an IRI whose interpretation is out of
scope of PROV-DM, we don't allow it to refer to an entity (in an
inter-operable manner). Is this what we intend?
</div>

<div class="issue"> Simplify the references to recipe link. This is <a href="http://www.w3.org/2011/prov/track/issues/131">ISSUE-131</a></div>

</div>





<div id="record-Location" class="section">
<h4><span class="secno">5.5.8 </span>Location</h4>

<p><dfn id="dfn-Location">Location</dfn> is an identifiable geographic place (ISO 19112). As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, row, column, and so forth. This  document does not specify how to concretely express  locations, but instead provide a mechanism to introduce locations in assertions. </p> 


<p>
Location is an <em class="rfc2119" title="optional">optional</em> attribute of entity records and activity records.  The value associated with a  attribute <span class="name">location</span> <em class="rfc2119" title="must">must</em> be a <span class="nonterminal">Literal</span>, expected to denote a location.
</p>




</div>

</div>

</div>


    <div id="common-relations" class="section"> 
<!--OddPage--><h2><span class="secno">6. </span>PROV-DM Common Relations</h2>

<p>This section contains the normative specification of common relations of PROV-DM.</p>


<div class="issue">We have defined a set of common relation, in response to  <a href="http://www.w3.org/2011/prov/track/issues/44">ISSUE-44</a>. Is this set complete?</div>


<div class="note">The types of these relations need to be made explicit.</div>

<p>The following figure summarizes the additional relations described in subsections 6.2 onwards.</p>

<div style="text-align: center;">
<img src="sec6-summary.png" alt="common relations">
</div>


<div id="record-Collection" class="section">
<h3><span class="secno">6.1 </span>Collections</h3>

The purpose of this section is to enable modelling of part-of relationships amongst entities. In particular, a form of <strong>collection</strong> entity type is introduced, consisting of a set of key-value pairs. Key-value pairs provide a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more.<br>

The relations introduced here are all specializations of the <a href="#Derivation-Relation"><strong>wasDerivedFrom</strong></a> relation, specifically precise-1 or imprecise-1. They are designed to model:

<ul>
  <li><strong>insertion</strong>: a collection entity c' is obtained from collection entity c, by adding entity e having key k to c;
  </li><li><strong>removal</strong>: a collection entity c' is obtained from collection entity c, by removing  entity e having key k from c;
    </li><li><strong>selection</strong>: an entity e was selected from collection c using key k.
 </li></ul>

 A collection record is defined as follows.
<div class="grammar">
  <span class="nonterminal">collectionRecord</span>&nbsp;::=  
<span class="nonterminal">collectionDerivationRecord</span>
| <span class="nonterminal">keyDerivationRecord</span>
| <span class="nonterminal">entityMembershipRecord</span>
<br>

 <span class="nonterminal">collectionDerivationRecord</span>&nbsp;::=  
<span class="name">wasAddedTo_Coll</span> 
 <span class="name">(</span>
 <span class="nonterminal">identifier</span>
 <span class="name">,</span>
<span class="nonterminal">identifier</span>
  <span class="name">)</span>
  |
<span class="name">wasRemovedFrom_Coll</span> 
 <span class="name">(</span>
 <span class="nonterminal">identifier</span>
 <span class="name">,</span>
<span class="nonterminal">identifier</span>
  <span class="name">)</span>
<br>

   <span class="nonterminal">keyDerivationRecord</span>&nbsp;::=  
<span class="name">wasAddedTo_Key</span> 
 <span class="name">(</span>
 <span class="nonterminal">identifier</span>
 <span class="name">,</span>
<span class="nonterminal">identifier</span>
  <span class="name">)</span>
|
<span class="name">wasRemovedFrom_Key</span> 
 <span class="name">(</span>
 <span class="nonterminal">identifier</span>
 <span class="name">,</span>
<span class="nonterminal">identifier</span>
  <span class="name">)</span>
  <br>

  <span class="nonterminal">entityMembershipRecord</span>&nbsp;::=  
<span class="name">wasAddedTo_Entity</span> 
 <span class="name">(</span>
 <span class="nonterminal">identifier</span>
 <span class="name">,</span>
<span class="nonterminal">identifier</span>
  <span class="name">)</span>
<br>
  </div>

<p>    Record:  <span class="name">wasAddedTo_Coll(c2,c1)</span> (resp.  <span class="name">wasRemovedFrom_Coll(c2,c1)</span>) denotes that collection  <span class="name">c2</span> is an updated version of collection <span class="name">c1</span>, following an insertion (resp. deletion) operation.</p>
  
<p>    Record:  <span class="name">wasAddedTo_Key(c,k)</span>  (resp.  <span class="name">wasRemovedFrom_Key(c,k)</span>) denotes that collection <span class="name">c</span> had 
 a new value with key <span class="name">k</span> added to (resp. removed from) it.</p>
  
<p>    Record:  <span class="name">wasAddedTo_Entity(c,e)</span>   denotes that collection <span class="name">c</span> had entity
 <span class="name">e</span>   added to it.
</p>


<div class="anexample">
<p>Consider the following assertions:</p>
<pre class="codeexample">

  <span class="name">wasAddedTo_Coll(c2,c1)</span>
  <span class="name">wasAddedTo_Key(c2,k1)</span>
  <span class="name">wasAddedTo_Entity(c2,e1)</span>

  <span class="name">wasAddedTo_Coll(c3,c2)</span>
  <span class="name">wasAddedTo_Key(c3,k2)</span>
  <span class="name">wasAddedTo_Entity(c3,e2)</span>

  <span class="name">wasRemovedFrom_Coll(c4,c3)</span>
  <span class="name">wasRemovedFrom_Key(c4,k1)</span>
</pre>
<p>The corresponding graphical representation is shown below.</p>

<div style="text-align: center;">
<img src="collections.png" alt="collections">
</div>


<p>  With these assertions:</p>
  <ul>
    <li><span class="name">c2</span> is known to contain the key-value pair <span class="name">(k1,e1)</span>
    </li><li><span class="name">c3</span> is known to contain pairs <span class="name">(k1,e1)</span> and  <span class="name">(k2,e2)</span>.
    </li><li><span class="name">c4</span> is known <em>not</em> to contain pair <span class="name">(k1,e1)</span> and to contain pair <span class="name">(k2,e2)</span>.  
  </li></ul>
</div>

      </div> 

<div id="record-traceability" class="section">
<h3><span class="secno">6.2 </span>Traceability Record</h3>

<p> A <dfn id="dfn-Traceability">traceability record</dfn> states the existence of  a  "dependency path" between two entities, indicating that one entity can be shown to be in the lineage of another, and may have influenced it in some way. This relation is transitive. </p>

<p> A traceability record, written <span class="name">tracedTo(id,e2,e1,attrs)</span> in PROV-ASN:</p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the traceability record;</li> 
<li><em>entity</em>:  an identifier <span class="name">e2</span> identifying an entity;
</li><li><em>ancestor</em>: an identifier <span class="name">e1</span> identifying an ancestor entity in the lineage of  <span class="name">e2</span>;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>

<p>In PROV-ASN, a traceability record's text matches the <span class="nonterminal">traceabilityRecord</span> production of the grammar defined in this specification document.</p>


<div class="grammar">
<span class="nonterminal">traceabilityRecord</span>&nbsp;::= 
<span class="name">tracedTo</span>
<span class="name">(</span>
<span class="optional"><span class="nonterminal">identifier</span>
<span class="name">,</span></span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>

<p>A traceability record can be inferred from existing relations, or can be asserted stating that such a dependency path exists without the asserter knowing its individual steps, as expressed by the following constraints.

</p><div class="constraint" id="traceability-inference">
Given two identifiers <span class="name">e2</span> and  <span class="name">e1</span> identifying entity records, 
the following statements hold:

<ol> 
<li><span class="conditional">If</span>  <span class="name">wasDerivedFrom(e2,e1,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
<li><span class="conditional">If</span>  <span class="name">wasDerivedFrom(e2,e1)</span> holds, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
<li><span class="conditional">If</span>  <span class="name">wasGeneratedBy(e2,a,gAttr) and wasAssociatedWith(a,e1)</span> hold, for some  <span class="name">a</span> and  <span class="name">gAttr</span>, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
<li><span class="conditional">If</span>  <span class="name">wasGeneratedBy(e2,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e1)</span> hold, for some  <span class="name">a</span>, <span class="name">e</span>, and  <span class="name">gAttr</span>, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
<li><span class="conditional">If</span>  <span class="name">wasGeneratedBy(e2,a,gAttr) and wasStartedBy(a,e1,sAttr)</span> hold, for some  <span class="name">a</span>, <span class="name">e</span>, and  <span class="name">gAttr</span>, and  <span class="name">sAttr</span>, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
<li><span class="conditional">If</span>  <span class="name">tracedTo(e2,e)</span> and  <span class="name">tracedTo(e,e1)</span> hold for some  <span class="name">e</span>, <span class="conditional">then</span>  <span class="name">tracedTo(e2,e1)</span> also holds.</li>
</ol>
</div>

<div class="constraint" id="traceability-assertion">
<span class="conditional">If</span> the record <span class="name">tracedTo(r2,r1)</span> holds
for two identifiers <span class="name">r2</span> and  <span class="name">r1</span> identifying entity records, 
 <span class="conditional">then</span> there exist
<span class="name">e<sup>0</sup></span>, <span class="name">e<sup>1</sup></span>, ..., <span class="name">e<sup>n</sup></span> for <span class="name">n≥1</span>, with <span class="name">e<sup>0</sup></span>=<span class="name">r2</span>  and <span class="name">e<sup>n</sup></span>=<span class="name">r1</span>, and
for any i such that <span class="name">0≤i≤n-1</span>, at least of the following statements holds:
<ul> 
<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>,a,g2,u1)</span> holds, for some <span class="name">a</span>, <span class="name">g2</span>, <span class="name">u1</span>, or</li>
<li> <span class="name">wasDerivedFrom(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
<li> <span class="name">wasBasedOn(e<sup>i</sup>,e<sup>i+1</sup>)</span> holds, or</li>
<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasAssociatedWith(a,e<sup>i+1</sup>)</span> hold, for some  <span class="name">a</span> and  <span class="name">gAttr</span>, or</li>
<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr)</span>, <span class="name">wasAssociatedWith(a,e)</span> and <span class="name">actedOnBehalfOf(e,e<sup>i+1</sup>)</span> hold, for some  <span class="name">a</span>, <span class="name">e</span> and  <span class="name">gAttr</span>, or</li>
<li> <span class="name">wasGeneratedBy(e<sup>i</sup>,a,gAttr) and wasStartedBy(a,e<sup>i+1</sup>,sAttr)</span> hold, for some  <span class="name">a</span>, <span class="name">e</span>, and  <span class="name">gAttr</span>, and  <span class="name">sAttr</span>.</li>
</ul>
</div>

<p>We note that the previous constraint is not really an inference <em>rule</em>, since there is nothing that we can actually infer. Instead,  this constraint should simply be seen as part of the definition of the traceability record. </p>


</div>

<div id="record-OrderingOfActivities" class="section">
<h3><span class="secno">6.3 </span>Activity Ordering Record</h3>



<p>PROV-DM allows dependencies amongst activities to be expressed.
An <dfn id="InformationFlowOrdering">information flow ordering record</dfn> is a representation that an entity was generated by an activity, before it was used by another activity.
A <dfn id="ControlOrdering">control ordering record</dfn> is a representation that an activity was initiated by another activity.
</p>

<p>In PROV-ASN, an activity ordering record's text matches the <span class="nonterminal">activityOrderingRecord</span> production of the grammar defined in this specification document.
</p>

<div class="grammar">
<span class="nonterminal">activityOrderingRecord</span>&nbsp;::= 
<span class="nonterminal">informationFlowOrderingRecord</span> |
<span class="nonterminal">controlOrderingRecord</span>
<br>

<span class="nonterminal">informationFlowOrderingRecord</span> &nbsp;::= 
<span class="name">wasInformedBy</span>
<span class="name">(</span>
<span class="optional"><span class="nonterminal">identifier</span>
<span class="name">,</span>
</span>
<span class="nonterminal">aIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">aIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
<br>

<span class="nonterminal">controlOrderingRecord</span> &nbsp;::= 
<span class="name">wasStartedBy</span>
<span class="name">(</span>
<span class="optional"><span class="nonterminal">identifier</span>
<span class="name">,</span>
</span>
<span class="nonterminal">aIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">aIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
<br>
</div>


<p>
An information flow ordering record, written as 
<span class="name">wasInformedBy(id,a2,a1,attrs)</span> in PROV-ASN, contains: 
</p><ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span> identifying the record;</li> 
<li><em>informed</em>: the identifier <span class="name">a2</span> of an activity record representing the informed activity;
</li><li><em>informant</em>: the identifier <span class="name">a1</span> of an activity record representing the informant activity;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>

<p> An information flow ordering record is formally defined as follows.</p>

<div class="constraint" id="wasInformedBy-Definition">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>, 
 the record <span class="name">wasInformedBy(a2,a1)</span>
holds, <span class="conditional">if and only if</span>
 there is an entity record identified by <span class="name">e</span> and sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
such that <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">used(a2,e,attrs2)</span> hold.
</div>

<div class="interpretation" id="wasInformedBy-ordering">
Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasInformedBy(a2,a1)</span>
 holds, <span class="conditional">then</span> the following temporal constraint holds:
the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity end event" href="#dfn-end-event" class="internalDFN">end event</a> of
the activity record denoted by <span class="name">a2</span>.
</div>


<p>The relationship <span class="name">wasInformedBy</span> is not transitive. Indeed, consider the following records.</p>
<pre class="codeexample">wasInformedBy(a2,a1)
wasInformedBy(a3,a2)
</pre>
<p> We cannot infer <span class="name">wasInformedBy(a3,a1)</span> from them. Indeed, 
from 
<span class="name">wasInformedBy(a2,a1)</span>, we know that there exists <span class="name">e1</span> such that <span class="name">e1</span> was generated by <span class="name">a1</span> and used by <span class="name">a2</span>. Likewise, from <span class="name">wasInformedBy(a3,a2)</span>, we know that there exists  <span class="name">e2</span> such that <span class="name">e2</span> was generated by <span class="name">a2</span> and used by <span class="name">a3</span>. The following illustration shows a case where transitivity cannot hold. The horizontal axis represents time. We see that <span class="name">e1</span> was generated after <span class="name">e2</span> was used. Furthermore, the illustration also shows that <span class="name">a3</span> completes before <span class="name">a1</span>.  So it is impossible for <span class="name">a3</span> to have used an entity generated by <span class="name">a1</span>.</p>

<div style="text-align: center;">
<img src="informedByNonTransitive.png" alt="non transitivity of wasInformedBy">
</div>

<div class="note">
The relation wasScheduledAfter was dropped, and replaced by a simplier relation wasStartedBy(a2,a1). It is intentional that the name wasStartedBy is overloaded.
</div>

<p>
A control ordering record, written as 
<span class="name">wasStartedBy(a2,a1)</span> in PROV-ASN, contains: </p>
<ul>
<li><em>id</em>:  an <em class="rfc2119" title="optional">optional</em> identifier  <span class="name">id</span>;</li> 
<li><em>started</em>: refers to an activity record identified by <span class="name">a2</span>, representing the started activity;
</li><li><em>starter</em>: refers to an activity record identified by <span class="name">a1</span>, representing the activity that started <span class="name">a1</span>;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>
<p>Such a record states control ordering between <span class="name">a2</span> and <span class="name">a1</span>, specified as follows.</p>

<div class="constraint" id="wasStartedBy">Given two activity records identified by <span class="name">a1</span> and <span class="name">a2</span>, 
 the record <span class="name">wasStartedBy(a2,a1)</span>
holds <span class="conditional">if and only if</span>
 there exist an entity record identified by <span class="name">e</span> 
and some attributes  <span class="name">gAttr</span> and  <span class="name">sAttr</span>,
such that
 <span class="name">wasGeneratedBy(e,a1,gAttr)</span> 
 and <span class="name">wasStartedBy(a2,e,sAttr)</span> hold.
</div>


<div class="anexample">
<p>
In the following assertions, we find two activity records, identified by <span class="name">a1</span> and <span class="name">a2</span>, representing two activities, which took place on two separate hosts. The third record indicates that the latter activity was started by the former.</p>
<pre class="codeexample">activity(a1,workflow,t1,t2,[ex:host="server1.example.org"])
activity(a2,sub-workflow,t3,t4,[ex:host="server2.example.org"])
wasStartedBy(a2,a1)
</pre>

<p>Alternatively, we could have asserted the existence of an entity, representing a request to create a sub-workflow. This request, issued by <span class="name">a1</span>, triggered the start of <span class="name">a2</span>.
</p>
<pre class="codeexample">entity(e,[prov:type="creation-request"])
wasGeneratedBy(e,a1)
wasStartedBy(a2,e)
</pre>
</div>

<div class="interpretation" id="wasStartedBy-ordering">
Given two activity records denoted by <span class="name">a1</span> and <span class="name">a2</span>, <span class="conditional">if</span> the record <span class="name">wasStartedBy(a2,a1)</span>
 holds, <span class="conditional">then</span> the following temporal constraint holds: the
<a title="activity start event" href="#dfn-start-event" class="internalDFN">start</a> event of the activity record denoted by <span class="name">a1</span> <a href="#dfn-precedes" class="internalDFN">precedes</a> the <a title="activity start event" href="#dfn-start-event" class="internalDFN">start event</a> of
the activity record denoted by <span class="name">a2</span>.
</div>



<div class="pending">Suggested definition for process ordering. This is <a href="http://www.w3.org/2011/prov/track/issues/50">ISSUE-50</a>.</div>

</div>

<div id="record-Revision" class="section">
<h3><span class="secno">6.4 </span>Revision Record</h3>

<p> A <dfn id="dfn-Revision">revision record</dfn> is a representation of the creation of an entity considered to be a variant of another. Deciding whether something is made available as a revision of something else usually involves an agent who represents someone in the world who takes responsibility for approving that the former is a due variant of the latter. </p>

<p> A revision record, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN, contains:</p>
<ul>
<li><em>newer</em>:  an identifier <span class="name">e2</span> identifying an entity that represents a newer version of an entity;
</li><li><em>older</em>: an identifier <span class="name">e1</span> identifying an entity that represents an older version of an entity;
</li><li><em>responsibility</em>: an <em class="rfc2119" title="optional">optional</em>  identifier <span class="name">ag</span> for the agent who approved that <span class="name">e2</span> is a variant of <span class="name">e1</span>;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>


<p>In PROV-ASN, a revision record's text matches the <span class="nonterminal">revisionRecord</span> production of the grammar defined in this specification document.
</p>

<div class="grammar">
<span class="nonterminal">revisionRecord</span>&nbsp;::= 
<span class="name">wasRevisionOf</span>
<span class="name">(</span>
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span>
<span class="nonterminal">eIdentifier</span>
<span class="optional"><span class="name">,</span>
<span class="nonterminal">agIdentifier</span></span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span>
</div>





<p>A revision record needs to satisfy the following constraint, linking the two entity records by a derivation, and stating them to be a complement of a third entity record.</p>

<div class="constraint" id="wasRevision">
Given two identifiers <span class="name">old</span> and <span class="name">new</span> identifying two entities, and an identifier <span class="name">ag</span> identifying an agent,
<span class="conditional">if</span> a record <span class="name">wasRevisionOf(new,old,ag)</span> is asserted, <span class="conditional">then</span> 
there exists an entity record identifier <span class="name">e</span> and attribute-values <span class="name">eAttrs</span>, <span class="name">dAttrs</span>, such that the following records hold:
<ul>
<li> <span class="name">wasDerivedFrom(new,old,dAttrs)</span>;
</li><li> <span class="name">entity(e,eAttrs)</span>;
</li><li> <span class="name">wasComplementOf(new,e)</span>;
</li><li> <span class="name">wasComplementOf(old,e)</span>.
</li></ul>
The derivation record may be imprecise-1 or imprecise-n.
</div>

<p><span class="name">wasRevisionOf</span> is a strict sub-relation
 of <span class="name">wasDerivedFrom</span> since two entities <span class="name">e2</span> and <span class="name">e1</span>
 may satisfy <span class="name">wasDerivedFrom(e2,e1)</span> without being a variant of
 each other.
</p>

<div class="anexample">
<p>
The following revision assertion</p>
<pre class="codeexample">agent(ag,[prov:type="QualityController"])
entity(e1,[prov:type="document"])
entity(e2,[prov:type="document"])
wasRevisionOf(e2,e1,ag)
</pre>
<p>states that the document represented by entity record identified by  <span class="name">e2</span> is a revision of document represented by entity record identified by  <span class="name">e1</span>; agent denoted by <span class="name">ag</span> is responsible for this new versioning of the document.
</p>
</div>


<div class="pending">Revision should be a class not a  property. This is <a href="http://www.w3.org/2011/prov/track/issues/48">ISSUE-48</a>.</div>


</div>


<div id="attribution-record" class="section">
<h3><span class="secno">6.5 </span>Attribution Record</h3> 

<p>An attribution record represents that an entity is ascribed to an agent and is compliant with the <span class="nonterminal">attributionRecord</span> production.</p>


<p> An attribution record, written <span class="name"> wasAttributedTo(e,ag,attr)</span>, contains the following components:</p>
<ul>
<li><em>entity</em>: an identifier <span class="name">e</span> of an entity record;</li>
<li><em>agent</em>: an identifier <span class="name">ag</span> of an agent whom the entity is attributed to;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>
<p>Attribution models the notion of an activity generating an entity identified by <span class="name">e</span> being controlled by an agent <span class="name">ag</span>, which takes responsibility for generating <span class="name">e</span>. Formally, this is expressed as the following necessary condition.</p>

<p>In PROV-ASN, an attribution record's text matches the <span class="nonterminal">attributionRecord</span> production of the grammar.</p>

<div class="grammar">
<span class="nonterminal">attributionRecord</span>&nbsp;::=  
<span class="name">wasAttributedTo</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">agIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>

<div class="constraint" id="attribution-implication">
<span class="conditional">If</span>
<span class="name">wasAttributedTo(e,ag)</span> holds for some identifiers
<span class="name">e</span> and <span class="name">ag</span>,  
<span class="conditional">then</span> there exists an activity identified by <span class="name">pe</span> such that the following statements hold:
<pre>activity(pe,recipe,t1,t2,attr1)
wasGenerateBy(e,pe)
wasAssociatedWith(pe,ag,attr2)
</pre>
for some sets of attribute-value pairs <span class="name">attr1</span> and  <span class="name">attr2</span>, time <span class="name">t1</span>, and <span class="name">t2</span>.
</div>
</div>


<div id="quotation-record" class="section">
<h3><span class="secno">6.6 </span>Quotation Record</h3>


<p> A quotation record is a representation of the repeating or copying of some part of an entity, compatible with 
the <span class="nonterminal">quotationRecord</span> production.</p>


<p>  A quotation record, written <span class="name"> wasQuotedFrom(e2,e1,ag2,ag1,attrs)</span>, contains:</p>
<ul>
<li><em>quote</em>:  an identifier  <span class="name">e2</span>, identifying an entity record that represents the quote; 
</li><li><em>quoted</em>: an identifier  <span class="name">e1</span>, identifying an entity record representing what is being quoted;
</li><li><em>quoterAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag2</span> of the agent who is doing the quoting;
</li><li><em>quotedAgent</em>: an <em class="rfc2119" title="optional">optional</em> identifier <span class="name">ag1</span> of the agent that is quoted;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>

</ul>

<p>In PROV-ASN, a quotation record's text matches the <span class="nonterminal">quotationRecord</span> production of the grammar.</p>

<div class="grammar">
<span class="nonterminal">quotationRecord</span>&nbsp;::=  
<span class="name">wasQuotedFrom</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">agIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">agIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>



<div class="constraint" id="quotation-implication">
<span class="conditional">If</span>
<span class="name">wasQuotedFrom(e2,e1,ag2,ag1)</span> holds for some identifiers
<span class="name">e2</span>, <span class="name">e1</span>, <span class="name">ag2</span>, <span class="name">ag1</span>, 
<span class="conditional">then</span> the following records hold:
<pre>wasDerivedFrom(e2,e1)
wasAttributedTo(e2,ag2)
wasAttributedTo(e1,ag1)
</pre>
</div>

</div>


<div id="summary-record" class="section">
<h3><span class="secno">6.7 </span>Summary Record</h3>
<p>A <dfn id="dfn-summary-record">summary record</dfn> represents that an entity is a synopsis or abbreviation of another entity. A summary record is compliant with the 
<span class="nonterminal">summaryRecord</span> production.</p>



<p> An assertion wasSummaryOf, written <span class="name"> wasSummaryOf(e2,e1,attrs)</span>, contains:</p>
<ul>
<li><em>summarizedEntity</em>: an identifier <span class="name">e2</span> for the entity record that represents the summary; 
</li><li><em>fullEntity</em>: an identifier <span class="name">e1</span> for the entity record that represents what is being summarized;
</li><li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>

<p>In PROV-ASN, a summary record's text matches the <span class="nonterminal">summaryRecord</span> production of the grammar.</p>

<div class="grammar">
<span class="nonterminal">summaryRecord</span>&nbsp;::=  
<span class="name">wasSummaryOf</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">eIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>

<p>
<span class="name">wasSummaryOf</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
</p>


</div>

<div id="original-source-record" class="section">
<h3><span class="secno">6.8 </span>Original Source Record</h3>

<p>An <dfn id="dfn-original-source-record">original source record</dfn> represents an entity in
which another entity first appeared. A original-source
record is compliant with the
<span class="nonterminal">originalSourceRecord</span> production.</p>


<p> An assertion hadOriginalSource, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>, contains:</p>
<ul>
<li><em>entity</em>: an identifier <span class="name">e1</span> for the entity record representing the original entity; </li>
<li><em>source</em>: an identifier <span class="name">e2</span> for an entity record, representing an entity that had appeared previously;</li>
<li><em>attributes</em>: an <em class="rfc2119" title="optional">optional</em> set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
</ul>

<p>
  <span class="name">hasOriginalSource</span> is a strict sub-relation of <span class="name">wasDerivedFrom</span>.
</p>

<p>In PROV-ASN, an original source record's text matches the <span class="nonterminal">originalSourceRecord</span> production of the grammar.</p>

<div class="grammar">
<span class="nonterminal">originalSourceRecord</span>&nbsp;::=  
<span class="name">hadOriginalSource</span> 
<span class="name">(</span> 
<span class="nonterminal">eIdentifier</span>
<span class="name">,</span> 
<span class="nonterminal">eIdentifier</span>
<span class="nonterminal">optional-attribute-values</span>
<span class="name">)</span> 
</div>

</div> 
</div>

    <div id="extensibility-section" class="section"> 
<!--OddPage--><h2><span class="secno">7. </span>PROV-DM Extensibility Points</h2>


<p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:

</p><ul>
<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed.  Applications are free to introduce application-specific attributes, according to their perspective on the world.  Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace declared in a namespace declaration.

<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a set of reserved attributes: <span class="name">type</span>, <span class="name">location</span>.</p></li>


<li> Sets of Attribute-value pairs offer a mechanism to
describe modalities of use, generation, and control  
Such attributes are also qualified by namespaces.

<p>The <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>


<li>Note records allow arbitrary metadata to be associated with identifiable records of PROV-DM. Note records consist of name-value pairs. Like attributes, names are qualified by a namespace.</li>


<li>Namespaces allow attributes and names to be qualified. </li>

<li>Subtyping is allowed by means of the reserved attribute <span class="name">type</span>.</li>

<li>Domain specific values can be expressed by means of typed literals. </li>
</ul>

<p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged.  To ensure inter-operability, specializations of the PROV data model that exploit the extensibility points summarized in this section <em class="rfc2119" title="must">must</em> preserve the semantics specified in this document. For instance, a qualified attribute on a domain specific entity record <em class="rfc2119" title="must">must</em> represent an aspect of an entity and this aspect <em class="rfc2119" title="must">must</em> remain unchanged during the characterization's interval of this entity record.</p>



    </div> 



<div id="resource-section" class="section">
<!--OddPage--><h2><span class="secno">8. </span>Resources, URIs, Entities, Identifiers, and Scope</h2> 

<p>This specification  introduces the  notion of an identifiable entity in the world. In PROV-DM, an entity record is a representation of such an identifiable entity. An entity record includes an identifier identifying this entity.  Identifiers are qualified names, which can be mapped to IRIs.  </p>

<p>The term 'resource' is used in a general sense
      for whatever might be identified by a URI [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3986">RFC3986</a></cite>].  On the Web, a URI denotes a resource, without any expectation that the resource is accessed. </p>

<p>The purpose of this section is to clarify the relationship between resource and the notions of entity and  entity record. </p>  

<p>In the context of PROV-DM, a resource is just a thing in the world. One may take multiple perspectives on such a thing and its situation in the world, fixing some its aspects.</p>

<p> We refer to the example of section <a href="#conceptualization">2.1</a> for a resource (at some URL) and three different perspectives, referred to as entities.  Three different entity records can be expressed for this report, which in the PROV-ASN sample below, are expressed within a same account.
</p>

<pre>container
prefix app urn:example:
prefix cr  http://example.org/crime/

   account(acc1,
           http://example.org/asserter1,

           entity(app:0, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
           entity(app:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
           entity(app:2, [ prov:type="Document", cr:author="John" ])
        ...)
endContainer
</pre>

<p>Each entity record contains an idenfier that identifies the entity it represents.
In this example, three identifiers were minted, and their prefix uses the URN syntax with "example" namespace.</p>

<p>Given that the report is a resource denoted by the URI <span class="name">http://example.org/crime.txt</span>, we could simply use this URI as the identifier of an entity. This would avoid us minting new URIs.  Hence, the report URI would play a double role: as a URI it denotes a resource accessible at that URI, and as a PROV-DM identifier, it identifies a specific characterization of this report. A given identifier  identifies a single entity record within the scope of an account. Hence, below, all entities records have been given the same identifier but appear in the scope of different accounts. </p>

<pre>container 
prefix app http://example.org/
prefix cr  http://example.org/crime/

   account(acc2,
           http://example.org/asserter1,

           entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
           ...)

   account(acc3,
           http://example.org/asserter1,

           entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])
           ...)

   account(acc4,
           http://example.org/asserter1,
           entity(app:crime.txt, [ prov:type="Document", cr:author="John" ])
           ...)
endContainer
</pre>

<p>In this case, the qualified name  <span class="name">app:crime.txt</span> maps to URI <span class="name">http://example.org/crime.txt</span> still denotes the same resource; however, the perspective we take about that resource is expressed as a different entity record, happening to have the same identifier in different accounts. </p>

<p> Alternatively, if we need to assert the existence of two different perspectives on the report within the same account, then alternate identifiers <em class="rfc2119" title="must">must</em> be used, one of them being allowed to be the resource URI.</p>

<pre>container 
 prefix app  http://example.org/
 prefix app2 urn:example:
 prefix cr   http://example.org/crime/

   account(acc5,
           http://example.org/asserter1,

           entity(app:crime.txt, [ prov:type="Document", cr:path="http://example.org/crime.txt" ])
           entity(app2:1, [ prov:type="Document", cr:path="http://example.org/crime.txt", cr:version="2.1", cr:content="...", cr:date="2011-10-07" ])

           ...)
endContainer

</pre>


</div>                 


<!--
<li>For use, generation, and derivation event, the first argument is the 'effect' (i.e. most recent item) and the second argument is the 'cause' (i.e. least recent item). This order is compatible with the temporal layout of the graphical notation.
-->


<div class="appendix section" id="changes-since-first-public-working-draft"> 
      <!--OddPage--><h2><span class="secno">A. </span>Changes Since First Public Working Draft</h2> 
<ul>
<li>12/08/11: Explained non-transitivity of wasInformedBy.  </li>
<li>12/05/11: Made attributes optional, and used non-terminal optional-attribute-values.  </li>
<li>12/05/11: Changed syntax of recordContainer to be more user friendly, and removed list of account ids, since redundant.  </li>
<li>12/05/11: Changed syntax of namespace declaration to be more user friendly.  </li>
<li>12/05/11: Simplified Typed literals, now allows for intLiteral, and datatype adjusted to be qualified name.  </li>
<li>11/29/11: Introduced typed identifiers to make grammar clearer.  </li>
<li>11/29/11: Added section 2.4 on grammar notation.  </li>
<li>11/28/11: Changed grammar notation.  </li>
<li>11/25/11: Updated examples of section 8.  </li>
<li>11/25/11: Definition of namespace. Clarification about interpretation of IRI occurrences.  </li>
<li>11/25/11: Definition of attribute and identifier.  </li>
<li>11/24/11: Added figure of Common Relations in Section 6.  </li>
<li>11/24/11: Updated text preceding graphical illustration, removed appendix A.  </li>
<li>11/24/11: Fix on traceability record.  </li>
<li>11/24/11: Revisited Derivation record, with a single name for derivation. </li>
<li>11/23/11: Defined attribute, identifier, and namespace declaration. </li>
<li>11/23/11: Consolidation of event in section 2.1.2 and linking to definitions from the rest of document. </li>
<li>11/21/11: Added wasStartedBy between activities.</li>
<li>11/21/11: Added wasInformedBy-ordering constraint.</li>
<li>11/17/11: Added Traceability  Record.</li>
<li>11/17/11: Rewrote the whole section on Derivation Record.</li>
<li>11/17/11: Updated wasDerivedFrom to refer to generation/usage record ids.</li>
<li>11/17/11: Simplified hasAnnotation mechanism, now requiring to-be-annotated record to had id.</li>
<li>11/17/11: Renamed annotation into note.</li>
<li>11/17/11: Introduced wasStartedBy, wasEndedBy, and actedOnBehalfOf.</li>
<li>11/16/11: New version of agent/wasAssociatedWith.</li>
<li>11/16/11: Introduced class anexample.</li>
<li>11/16/11: Changed presentation of entity and activity.</li>
<li>11/16/11: Updated examples for usage and generation record.</li>
<li>11/16/11: Renamed use record into usage record.</li>
<li>11/16/11: Removed constraint generation-affects-attributes.</li>
<li>11/16/11: Removed constraint use-attributes.</li>
<li>11/16/11: Introduced optional identity for use and generation record.</li>
<li>11/11/11: Swapped sections 6 and 7.</li>
<li>11/11/11: Use attribute-value pairs uniformly, instead of qualifiers and name-value pairs.</li>
<li>11/08/11: Renamed 'provenance container' into 'record container'.</li>
<li>11/07/11: Addressed ISSUE-143 (qualifiers as a set of name value pairs).</li>
<li>11/07/11: Added a section on Literals (ISSUE-142).</li>
<li>11/07/11: Aligned terminology 'activity' and 'process execution record'.</li>
<li>11/07/11: Renamed 'xxx Expression' into 'xxx Record' to avoid the language connotation.</li>
<li>11/07/11: Defined entity as identifiable characterized thing, and updated text accordingly.</li>
<li>10/08/11: Made explicit the term expression wherever was appropriate, including section titles.</li>
</ul>
    </div> 

<div class="appendix section" id="acknowledgements"> 
      <!--OddPage--><h2><span class="secno">B. </span>Acknowledgements</h2> 
      <p> 
        WG membership to be listed here.
      </p> 
    </div> 
   
 
<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">C. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-IRI">[IRI]</dt><dd>M. Duerst, M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRI).</cite></a> January 2005. Internet RFC 3987. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3987.txt</a> 
</dd><dt id="bib-OWL2-SYNTAX">[OWL2-SYNTAX]</dt><dd>Boris Motik; Peter F. Patel-Schneider; Bijan Parsia. <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/"><cite>OWL 2 Web Ontology Language:Structural Specification and Functional-Style Syntax.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/">http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/</a> 
</dd><dt id="bib-RDF-SPARQL-QUERY">[RDF-SPARQL-QUERY]</dt><dd>Andy Seaborne; Eric Prud'hommeaux. <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115"><cite>SPARQL Query Language for RDF.</cite></a> 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115">http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115</a> 
</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a> 
</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a> 
</dd><dt id="bib-XML-NAMES">[XML-NAMES]</dt><dd>Richard Tobin; et al. <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition).</cite></a> 8 December 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">http://www.w3.org/TR/2009/REC-xml-names-20091208/</a> 
</dd><dt id="bib-XMLSCHEMA-2">[XMLSCHEMA-2]</dt><dd>Paul V. Biron; Ashok Malhotra. <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/</a> 
</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-CLOCK">[CLOCK]</dt><dd>Lamport, L. <a href="http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf"><cite>Time, clocks, and the ordering of events in a distributed system</cite></a>.Communications of the ACM 21 (7): 558–565. 1978 URL: <a href="http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf">http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf</a> DOI: doi:10.1145/359545.359563.
</dd><dt id="bib-CSP">[CSP]</dt><dd>Hoare, C. A. R. <a href="http://www.usingcsp.com/cspbook.pdf"><cite>Communicating Sequential Processes</cite></a>.Prentice-Hall. 1985URL: <a href="http://www.usingcsp.com/cspbook.pdf">http://www.usingcsp.com/cspbook.pdf</a>
</dd><dt id="bib-FOAF">[FOAF]</dt><dd>Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
</dd><dt id="bib-Logic">[Logic]</dt><dd>W. E. Johnson<a href="http://www.ditext.com/johnson/intro-3.html"><cite>Logic: Part III</cite></a>.1924. URL: <a href="http://www.ditext.com/johnson/intro-3.html">http://www.ditext.com/johnson/intro-3.html</a>
</dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Satya Sahoo and Deborah McGuinness <a href="http://www.w3.org/TR/prov-o/"><cite>Provenance Formal Model</cite></a>. 2011, Work in progress. URL: <a href="http://www.w3.org/TR/prov-o/">http://www.w3.org/TR/prov-o/</a>
</dd><dt id="bib-PROV-PAQ">[PROV-PAQ]</dt><dd>Graham Klyne and Paul Groth <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html"><cite>Provenance Access and Query</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html">http://dvcs.w3.org/hg/prov/tip/paq/prov-aq.html</a>
</dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil and Simon Miles <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html"><cite>Prov Model Primer</cite></a>. 2011, Work in progress. URL: <a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html">http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html</a>
</dd><dt id="bib-PROV-SEMANTICS">[PROV-SEMANTICS]</dt><dd>James Cheney <a href="http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman"><cite>Formal Semantics Strawman</cite></a>. 2011, Work in progress. URL: <a href="http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman">http://www.w3.org/2011/prov/wiki/FormalSemanticsStrawman</a>
</dd></dl></div></div></body></html>