├── AP_over_RDF.md ├── DSP2.ttl ├── DSPcompare.md ├── DSPdefined.json ├── DSPedited.md ├── DSPoverview.md ├── Patterns.md ├── README.md ├── Use_cases.md ├── _config.yml ├── catalog-v001.xml ├── csv ├── description.csv ├── descriptionSet.csv ├── rule.csv ├── smtVal1.csv ├── smtVal2.csv ├── statement.csv └── values.csv ├── dspDiagramWRules.uxf ├── dspdiagram2.md ├── options.md ├── requirements.md ├── shex4simple.txt ├── test.csv └── test2.csv /AP_over_RDF.md: -------------------------------------------------------------------------------- 1 | # Application Profile over RDF 2 | 3 | There are tensions between the idea of application profiles, structured metadata, RDF, and OWL. The intention of the RDF-AP is not to create an AP using RDF, but to use application profiles to provide the structure, rules, and user documentation for metadata that is based on RDF. In addition to that, this project intends to follow the principles of simplicity that are key to the Dublin Core work. 4 | 5 | ## RDF as abstract model 6 | 7 | RDF is an abstract model that describes a simple unit, the triple. This simple unit is incredibly powerful; it allows one to create anything from simple to very complex data graphs. By itself it does not satisfy some key requirements of metadata such as usage constraints, structural relationships, etc. Some of these functions have been addressed by the OWL2 standard, but the end result of those was not the same as a metadata definition because of some inherent aspects of RDF and in particular OWL. I see these as being differences between structural definition and inferred semantics. 8 | 9 | ## Structure v. semantics 10 | 11 | Both RDF and OWL express semantic relationships that were primarily introduced by the artificial intelligence community. Statements in the AI community are often of the type "A is a type of B" or "Because C, then A is a type of B". Semantics in this sense are logical axioms that can be expressed in graph form. The AI community is interested in being able to say things like: 12 | 13 | SubClassOf( 14 | :Grandfather 15 | ObjectIntersectionOf( :Man :Parent ) 16 | ) 17 | 18 | meaning "every Grandfather is both a man and a parent (whereas the converse is not necessarily true)" ([https://www.w3.org/TR/2012/REC-owl2-primer-20121211/ OWL2 Primer]) 19 | 20 | Axioms of this type express knowledge about the world, meaning that they are part of the metadata for a very big universe, the universe of everything. The data that we often call "metadata" has a much more modest goal: metadata describes a carved-out area of knowledge, and often describes things for a particular purpose rather than emphasizing meaning. When you buy a home appliance, there are technical specifications that give relevant information like dimensions, color, and features. 21 | -------------------------------------------------------------------------------- /DSP2.ttl: -------------------------------------------------------------------------------- 1 | @prefix : . 2 | @prefix owl: . 3 | @prefix rdf: . 4 | @prefix xml: . 5 | @prefix xsd: . 6 | @prefix rdfs: . 7 | @base . 8 | 9 | rdf:type owl:Ontology ; 10 | owl:imports . 11 | 12 | ################################################################# 13 | # Object Properties 14 | ################################################################# 15 | 16 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/descriptionID 17 | rdf:type owl:ObjectProperty ; 18 | rdfs:domain ; 19 | rdfs:range . 20 | 21 | 22 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/descriptionSetID 23 | rdf:type owl:ObjectProperty ; 24 | rdfs:domain ; 25 | rdfs:range . 26 | 27 | 28 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/statementID 29 | rdf:type owl:ObjectProperty ; 30 | rdfs:domain ; 31 | rdfs:range . 32 | 33 | 34 | ################################################################# 35 | # Data properties 36 | ################################################################# 37 | 38 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/maxOccur 39 | rdf:type owl:DatatypeProperty ; 40 | rdfs:range xsd:integer . 41 | 42 | 43 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/minOccur 44 | rdf:type owl:DatatypeProperty ; 45 | rdfs:range xsd:integer . 46 | 47 | 48 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/version 49 | rdf:type owl:DatatypeProperty ; 50 | rdfs:domain ; 51 | rdfs:range rdfs:Literal . 52 | 53 | 54 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/versionDate 55 | rdf:type owl:DatatypeProperty ; 56 | rdfs:domain ; 57 | rdfs:range xsd:dateTime . 58 | 59 | 60 | ################################################################# 61 | # Classes 62 | ################################################################# 63 | 64 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/DataTypeValue 65 | rdf:type owl:Class ; 66 | rdfs:subClassOf . 67 | 68 | 69 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/Desc 70 | rdf:type owl:Class . 71 | 72 | 73 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/DescSet 74 | rdf:type owl:Class . 75 | 76 | 77 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/LiteralValue 78 | rdf:type owl:Class ; 79 | rdfs:subClassOf . 80 | 81 | 82 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/ObjectValue 83 | rdf:type owl:Class ; 84 | rdfs:subClassOf . 85 | 86 | 87 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/SValue 88 | rdf:type owl:Class . 89 | 90 | 91 | ### http://kcoyle.net/metadata/examples/ontologies/2017/10/27/untitled-ontology-152/Statement 92 | rdf:type owl:Class . 93 | 94 | 95 | ### Generated by the OWL API (version 4.2.8.20170104-2310) https://github.com/owlcs/owlapi 96 | -------------------------------------------------------------------------------- /DSPcompare.md: -------------------------------------------------------------------------------- 1 | # Comparison of DC-DSP with ShEx and SHACL 2 | 3 | ## General Functionality 4 | 5 | | Function | DC-DSP | ShEx | SHACL | Comment | 6 | | ---------| ------ | ---- | ----- | ------- | 7 | | Start node | no | no | yes: target | ShEx assumes target set prior to validation | 8 | | min/max count (class) | yes | | | | 9 | | min/max count (property) | yes | | | | 10 | | node kind | | | IRI, bnode, literal | SHACL includes combinations, e.g. IRIOrLiteral | 11 | 12 | 13 | 14 | ## DSP Specifics 15 | 16 | (needed?) 17 | 18 | | DC-DSP | ShEx | SHACL | Comment | 19 | | ------ | ---- | ----- | ------- | 20 | | DescriptionTemplate ID | | | 21 | -------------------------------------------------------------------------------- /DSPdefined.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": "http://www.w3.org/ns/csvw", 3 | "tables": [{ 4 | "url": "http://example.org/descriptionSet.csv", 5 | "tableSchema": { 6 | "columns": [{ 7 | "name": "descID", 8 | "datatype": "string" 9 | }, { 10 | "name": "version", 11 | "datatype": "string" 12 | }, { 13 | "name": "versionDate", 14 | "datatype": "date" 15 | }, { 16 | "name": "topic", 17 | "datatype": "string" 18 | }, { 19 | "name": "creator", 20 | "datatype": "string" 21 | } 22 | ], 23 | "aboutUrl": "http://example.org/dsp.csv{#descID}", 24 | "propertyUrl": "http://example.com/{_name}", 25 | "primaryKey": "descID" 26 | } 27 | }, { 28 | "url": "http://example.org/description.csv", 29 | "tableSchema": { 30 | "columns": [{ 31 | "name": "descSetID", 32 | "valueUrl": "http://example.org/dsp.csv{#descSetID}" 33 | }, { 34 | "name": "descID", 35 | "datatype": "string" 36 | }, { 37 | "name": "label", 38 | "datatype": "string" 39 | }, { 40 | "name": "shortDescription", 41 | "datatype": "string" 42 | }, 43 | { 44 | "name": "longDescription", 45 | "datatype": "string" 46 | }, 47 | { 48 | "name": "minOccurs", 49 | "datatype": "integer" 50 | }, 51 | { 52 | "name": "maxOccurs", 53 | "datatype": "integer" 54 | }, 55 | { 56 | "name": "standalone", 57 | "datatype": "string" 58 | }, 59 | { 60 | "name": "class", 61 | "datatype": "string" 62 | } 63 | ], 64 | "foreignKeys": [{ 65 | "columnReference": "descSetID", 66 | "reference": { 67 | "resource": "http://example.org/description.csv", 68 | "columnReference": "descSetID" 69 | } 70 | }] 71 | } 72 | }] 73 | } -------------------------------------------------------------------------------- /DSPedited.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | # Description set profile, RDF version 5 | 6 | A description set profile is a document that describes the components of a metadata profile: the *things* the metadata describes, the terms it uses to describe those, the allowed values for the terms, rules relating to the values and terms, and human-readable documentation that guides the creation of valid metadata. 7 | 8 | # Description Set 9 | 10 | A description set is a document with one or more descriptions. The IRI of the description set identifies a single resource that may be described with multiple component descriptions, such as journal article metadata that has separate but linked descriptions for the text, the persons who authored the text, and the publisher responsible for publication. 11 | 12 | ##Administrative 13 | 14 | **Comment** 15 | 16 | _Probably more administrative information is desired, including: creators, license terms for re-use. I have included Version because that seems to be a universal need. I don't know what else is essential, or if we can push this off to a vocabulary like VOID._ 17 | 18 | ## Topic 19 | 20 | **Summary** 21 | 22 | Topic areas covered by the metadata, such as "documents", "weather data", etc. 23 | 24 | **Comment** 25 | 26 | _This is needed for discoverability. It could use dct:subject, or it could be done as a schema.org statement if the final document is in HTML. Probably we cannot work this out until we have a better idea of what the form (or forms) of DSP2 will be._ 27 | 28 | **Allowed values** 29 | 30 | Ideally taken from a controlled list. Could be text or an IRI. If an IRI a label should be included for discoverability. Text can be provided as a comma-delimited string. 31 | 32 | **Default** 33 | 34 | none 35 | 36 | **Conditions** 37 | 38 | none 39 | 40 | **Name** 41 | 42 | topic 43 | 44 | ## Version 45 | 46 | **Summary** 47 | 48 | The version of the DSP2 document. 49 | 50 | **Allowed values** 51 | 52 | Any text 53 | 54 | **Conditions** 55 | 56 | None 57 | 58 | **Name** 59 | 60 | version 61 | 62 | ## Version date 63 | 64 | **summary** 65 | 66 | The date of the version of the document in a standard date form: YYYYMMDD, YYYYMM, YYYY 67 | 68 | **Allowed values** 69 | 70 | Must be a valid date. 71 | 72 | **Conditions** 73 | 74 | none 75 | 76 | **Name** 77 | 78 | versionDate 79 | 80 | # Description 81 | 82 | A description describes a single resource; that resource is identified with an IRI. 83 | 84 | **Comment** 85 | 86 | _I always thought of the descriptions as entities, but could a description be simply a set of properties that don't define an entity per se, such as a group of administrative properties?_ 87 | 88 | ## Standalone 89 | 90 | **Summary** 91 | 92 | Whether descriptions matching this template are allowed to occur standalone, i.e. without being the value of a property. 93 | 94 | **Comment** 95 | 96 | _It would be good to have an example of a situation where this is essential. It seems that with graphs this could be too restrictive. Also this probably requires more validation logic than we can handle here._ 97 | 98 | **Allowed values** 99 | 100 | "yes" / "no" / "either" 101 | 102 | **Default** 103 | 104 | none 105 | 106 | **Conditions** 107 | 108 | If standalone is "yes", a matching description may not be a description of value occurring elsewhere in the DSP. The description must "stand alone". 109 | 110 | If standalone is "no", a matching description *must* be a description of value occurring elsewhere in the DSP. 111 | 112 | If standalone is "either" then the description can be used either alone or as a value. 113 | 114 | If standalone is not defined, then the description set is silent on this issue, which has the same affect as "either". 115 | 116 | If this description template is referred to in a Value Constraint, standalone cannot be "yes". 117 | 118 | **Name** 119 | 120 | standalone 121 | 122 | ## Minimum occurrence constraint 123 | 124 | **Summary** 125 | 126 | The minimum number of times this kind of description must appear in the Description Set. 127 | 128 | **Allowed values** 129 | 130 | non-negative integer 131 | 132 | **Default** 133 | 134 | 0 135 | 136 | If undefined, no minimum is enforced. Description is optional. 137 | 138 | Any positive integer means the description is required for the resource identified by the description set. 139 | 140 | **Conditions** 141 | 142 | Must be equal or less than the Maximum occurrence 143 | 144 | **Name** 145 | 146 | minOccurs 147 | 148 | ## Maximum occurrence constraint 149 | 150 | **Summary** 151 | 152 | The maximum number of times this kind of description is allowed to appear in the Description Set. 153 | 154 | **Comment** 155 | 156 | _It may not be possible to use "infinity" if this is defined as datatype non-negative integer. Instead, if no maximum is given, no constraint is assumed (which = infinity)__ 157 | 158 | **Allowed values** 159 | 160 | non-negative integer or "infinity" 161 | 162 | **Default** 163 | 164 | "infinity" 165 | 166 | **Conditions** 167 | 168 | Must be equal or greater than the Minimum occurrence. If there is no maximum to enforce, this constraint must not be included in the set. 169 | 170 | **Name** 171 | 172 | maxOccurs 173 | 174 | ## Resource Class Membership Constraint 175 | 176 | **Summary** 177 | 178 | Classes that the resource may be an instance of 179 | 180 | **Allowed values** 181 | 182 | a list of class URIs 183 | 184 | **Default** 185 | 186 | none 187 | 188 | **Conditions** 189 | 190 | if given, the resource must be an instance of one of the given classes. If this property is not used, there is no constraint on the what classes the description may be an instance of 191 | 192 | _Not clear why "resource" is used here. Until now this has been called a description. It might make sense to use resource, but we would have to do that throughout. Or we could talk about a "resource description"._ 193 | 194 | **Name** 195 | 196 | resourceClass 197 | 198 | ## Has statement 199 | 200 | **Summary** 201 | 202 | Relationship of a description to its statement(s). 203 | 204 | **Allowed values** 205 | 206 | IRI of a statement 207 | 208 | **Default** 209 | 210 | none 211 | 212 | **Conditions** 213 | 214 | There SHOULD be at least one statement associated with each description. There is no limit on the number of statements. 215 | 216 | **Name** 217 | 218 | hasStatement 219 | 220 | # Statement 221 | 222 | A statement is a single data element that is used in the metadata to describe the resource that is identified in the description. A statement is identified with the IRI of an RDF vocabulary term. Statements are associated with/members of a description with the _hasStatement_ property. The statement defines the valid values for the vocabulary term, and other constraints. 223 | 224 | There are no limits on the number of statements that can be associated with a description. A description with no statements is not actionable. 225 | 226 | A statement template has the following possible constraints. 227 | 228 | **Comment** 229 | 230 | _Questions on this_ 231 | 232 | _1. Can the same property be associated with more than one statement?_ 233 | 234 | _2. Can there be properties that are not associated with a statement?_ 235 | 236 | **Name** 237 | 238 | Each statement has either an rdf:label property, or a label property from another vocabulary, such as SKOS. 239 | 240 | _Issue: should labels from the original vocabulary be used if no label is given in the description set?_ 241 | 242 | ## Minimum occurrence constraint 243 | 244 | **Summary** 245 | 246 | The minimum number of times this kind of statement must appear in the enclosing Description. If the value of this property is zero ("0"), the this statement is not required. 247 | 248 | **Allowed values** 249 | 250 | non-negative integer 251 | 252 | **Default** 253 | 254 | 0 255 | 256 | **Conditions** 257 | 258 | must be equal or less than the Maximum occurrence 259 | 260 | **Name** 261 | 262 | minOccurs 263 | 264 | ## Maximum occurrence constraint 265 | 266 | **Summary** 267 | 268 | The maximum number of times this kind of statement is allowed to appear in the enclosing Description. If the value of this property is greater than one, then this property is repeatable. If no maxOccurs property is included in the profile, then the property is repeatable and there are no limits on how many times it can be repeated. 269 | 270 | **Comment** 271 | 272 | _It may not be possible to use "infinity" if this is defined as datatype non-negative integer. Instead, if no maximum is given, no constraint is assumed (which = infinity)__ 273 | 274 | **Allowed values** 275 | 276 | non-negative integer 277 | 278 | **Default** 279 | 280 | none 281 | 282 | **Conditions** 283 | 284 | must be equal or greater than the Minimum occurrence 285 | 286 | **Name** 287 | 288 | maxOccurs 289 | 290 | # Value constraints 291 | 292 | ## Value type constraint 293 | 294 | **Summary** 295 | 296 | The type of value that is allowed in this Statement. 297 | 298 | **Allowed values** 299 | 300 | "literal" / "nonliteral" 301 | "Object" (IRI) / "Datatype" (xsd:)/ "literal" () 302 | 303 | **Comment** 304 | 305 | _The original values of literal and nonliteral followed the DCAM, and the constraints were based on DCAM notions of value surrogates. To move away from that, should this use object/data from OWL?_ 306 | 307 | _Would it be useful here to indicate that the value is a value list?_ 308 | 309 | **Default** 310 | 311 | If undefined, no further value constraints are applied. 312 | 313 | **Conditions** 314 | 315 | If not provided, there can be no constraints on the value. _Same as OWL annotation property._ 316 | 317 | **Name** 318 | 319 | valueType 320 | 321 | Note: that the value type constraint should not contradict the range given for the used properties where they are originally defined. 322 | 323 | 324 | ## Object constraints 325 | 326 | Object values are always IRIs. IRIs can be complete or can be patterns that include the domain, domain name, or some portion of the IRI path. 327 | 328 | e.g.s 329 | 330 | http://id.loc.gov/authorities/names* ##limited to name authority list 331 | 332 | http://id.loc.gov/authorities/* ##limited to any LC authority list 333 | 334 | http://id.loc.gov/ ## limited to any LC IRIs at id.loc.gov 335 | 336 | http://.gov/ ## allows any IRI from the .gov domain 337 | 338 | Note that a DSP Description can be the value of an object statement. 339 | 340 | ### IRI list constraint 341 | 342 | **Summary** 343 | 344 | IRIs that are allowed as values. 345 | 346 | **Allowed values** 347 | 348 | a list of IRIs that can be used as values. The list can also contain IRI "stubs" giving at least the 349 | 350 | **Default** 351 | 352 | no constraint 353 | 354 | **Conditions** 355 | 356 | none 357 | 358 | **Name** 359 | 360 | IRIList 361 | 362 | ### Unique IRI constraint 363 | 364 | **Summary** 365 | 366 | For a given property, an IRI can appear only once 367 | 368 | **Allowed values** 369 | 370 | Yes / No 371 | 372 | **Default** 373 | 374 | no constraint 375 | 376 | **Conditions** 377 | 378 | _This requires comparing values for some set of properties. This gets into complex validation because it looks at more than one property._ 379 | 380 | **Name** 381 | 382 | UniqueIRI 383 | 384 | ## Literal value constraints 385 | 386 | Constrains a literal value in a statement. Only allowed in the case that the type constraint has the value "literal". 387 | 388 | **Comment** 389 | 390 | _This can be a heading, but not sure that we need a property. We'll need to decide this after we model the RDF._ 391 | 392 | **Name** 393 | 394 | LiteralConstraint 395 | 396 | ### Literal list constraint 397 | 398 | **Summary** 399 | 400 | Literals that are allowed as values. 401 | 402 | **Allowed values** 403 | 404 | a list of literals, i.e. (string, language tag) or (string, syntax encoding scheme URI) pairs. 405 | 406 | **Default** 407 | 408 | no constraint 409 | 410 | **Conditions** 411 | 412 | if given, no other literal constraint may be given 413 | 414 | **Name** 415 | 416 | literalList 417 | 418 | ### Literal maximum length constraint 419 | 420 | **Summary** 421 | 422 | The maximum allowed length of the literal in bytes 423 | 424 | **Allowed values** 425 | 426 | non-negative integer 427 | 428 | **Default** 429 | 430 | no constraint 431 | 432 | **Conditions** 433 | 434 | Maximum length must be greater than or equal to minimum length 435 | 436 | **Name** 437 | 438 | literalMaxLength 439 | 440 | ### Literal minimum length constraint 441 | 442 | **Summary** 443 | 444 | The minimum allowed length of the literal in bytes 445 | 446 | **Allowed values** 447 | 448 | non-negative integer 449 | 450 | **Default** 451 | 452 | no constraint 453 | 454 | **Conditions** 455 | 456 | Minimum length must be less than or equal to maximum length 457 | 458 | **Name** 459 | 460 | literalMinLength 461 | 462 | ### Language tag constraint 463 | 464 | **Summary** 465 | 466 | Whether languages are required for the literal 467 | 468 | **Comment** 469 | 470 | _For validation purposes, the values seem to be yes/no, and optional is that this property is not included. But the difficulty is where there is no constraint but a set of valid language codes is given. That could be difficult to express as a validation statement._ 471 | 472 | **Allowed values** 473 | 474 | "mandatory" / "optional" / "disallowed" 475 | 476 | **Default** 477 | 478 | "optional" 479 | 480 | **Conditions** 481 | 482 | _(DCAM: if "mandatory", Syntax encoding schemes are automatically disallowed.)(Drop?)_ 483 | 484 | **Name** 485 | 486 | languageTag 487 | 488 | ### Unique language constraint 489 | 490 | **Summary** 491 | 492 | For a given property, only one string can appear per language tag. 493 | 494 | **Allowed values** 495 | 496 | Yes / No 497 | 498 | **Default** 499 | 500 | no constraint 501 | 502 | **Conditions** 503 | 504 | _This requires comparing values for some set of properties. This gets into complex validation because it looks at more than one property. It fulfills some SKOS requirements._ 505 | 506 | **Name** 507 | 508 | UniqueIRI 509 | 510 | ### Language list constraint 511 | 512 | **Summary** 513 | 514 | Languages allowed for the literal. The language tag must be one of the tags 515 | 516 | **Comment** 517 | 518 | _What is the format of the list? An RDF list? A comma-delimited list? Do the strings need to be in quotes: "@en","@de"? or @en,@de?_ 519 | 520 | _Can be tested with SHACL:languageIn. Language-tagged strings are defined as type http://www.w3.org/1999/02/22-rdf-syntax-ns#langString._ 521 | 522 | _there also needs to be a constraint on each language can appear only once_ 523 | 524 | **Allowed values** 525 | 526 | a list consisting of language tags (@xx). 527 | 528 | **Default** 529 | 530 | no constraint 531 | 532 | **Conditions** 533 | 534 | This should only apply if languageTag is not "disallowed". 535 | 536 | **Name** 537 | 538 | validLanguageList 539 | 540 | 541 | 542 | 543 | ### Datatype constraint 544 | 545 | **Summary** 546 | 547 | The datatype that is valid for this property 548 | 549 | **Allowed values** 550 | 551 | An xsd: datatype 552 | 553 | **Default** 554 | 555 | "optional" 556 | 557 | **Conditions** 558 | 559 | must be valid xsd: datatypes 560 | 561 | **Name** 562 | 563 | dataType 564 | 565 | ### Datatype list constraint 566 | 567 | **Summary** 568 | 569 | A list of xsd: datatypes that are valid for this property 570 | 571 | **Allowed values** 572 | 573 | a list consisting of xsd: datatypes 574 | 575 | **Default** 576 | 577 | no constraint 578 | 579 | **Conditions** 580 | 581 | Must be valid xsd: datatypes 582 | 583 | **Name** 584 | 585 | dataTypeList 586 | 587 | ### Datatype value constraint 588 | 589 | **Summary** 590 | 591 | Constraints on the actual values, such as "date must be > 1990" 592 | 593 | **Comment** 594 | 595 | _This is something the validation languages can do. It isn't clear if there can be a simple form of this, but it is a common need._ 596 | 597 | **Allowed values** 598 | 599 | text describing the desired constraints 600 | 601 | **Default** 602 | 603 | no constraint 604 | 605 | **Conditions** 606 | 607 | 608 | 609 | **Name** 610 | 611 | dataTypeValue 612 | 613 | -------------------------------------------------------------------------------- /DSPoverview.md: -------------------------------------------------------------------------------- 1 | # DSP2 Overview 2 | 3 | The primary elements of DSP2 are: 4 | 5 | * A Description set that contains one or more descriptions 6 | 7 | * One or more descriptions that each link to one or more statements. Descriptions are generally entities and may have class membership. 8 | 9 | * One or more statements linked to a description. Statements consist of properties and values. 10 | 11 | ## Description Set 12 | ### Admin (general) 13 | ### Topic 14 | ### Version 15 | ### Version Date 16 | ### Descriptions 17 | 18 | ## Description 19 | ### Standalone 20 | ### Minimum occurrence 21 | ### Maximum occurrence 22 | ### Resource class membership 23 | ### Statements 24 | 25 | ## Statement 26 | ### Minimum occurrence 27 | ### Maximum occurrence 28 | 29 | ## Values 30 | ### Value type 31 | 32 | ## Object value 33 | ### IRI list constraint 34 | ### Unique IRI constraint 35 | ### Value class constraint 36 | 37 | ## Literal value 38 | ### Literal list constraint 39 | ### Literal maximum length 40 | ### Literal minimum length 41 | ### Language tag constraint 42 | ### Unique language constraint 43 | ### Language list constraint 44 | 45 | ## Datatype value 46 | ### Datatype constraint 47 | ### Dataype list constraint 48 | ### Datatype value constraint 49 | 50 | 51 | -------------------------------------------------------------------------------- /Patterns.md: -------------------------------------------------------------------------------- 1 | # Patterns 2 | 3 | There are three main components of the application profile: entities, properties, and values. There are five primary types of relationships between these: entity/entity relationships, property/property relationships, and entity/property relationships, property/value relationships, and value/value relationships. The relationships can be of type dependency, choice, or compound. 4 | 5 | ## Primary and Secondary Entities 6 | 7 | For the purpose of navigation of the graph, it may be useful to define a primary entity. This entity is the starting point for subsequent operations. The identifier of the entity may be considered the identifier for the *record*. All other entities are secondary. 8 | 9 | * Main entity (0 or 1) 10 | * Secondary entities (0 or unlimited) 11 | 12 | Entities can be identified using RDF types (classes) or through specific properties. 13 | 14 | [Note: assume that cardinality can be used throughout, even if not expressly listed.] 15 | 16 | ## Stand alone 17 | 18 | In the Dublin Core Description Set Profile there is a quality called "stand alone" for entities which is either true or false. This determines whether an entity can exist without being the object of some other entity. "False" is is a broader requirement than a dependency because it does not state a dependency on any particular other entity in the set. "True" would allow, for example, that there could be entities for persons even though they are not associated with a specific resource. This could also be useful in allowing entities to be created at a convenient point in the workflow without triggering errors before the description is completed. 19 | 20 | ## Properties 21 | 22 | Once the entity/property and property/property relationships are applied, there can be rules that apply to the properties and their values: 23 | * property cardinality (if not already defined in relationship patterns) 24 | * property value rules 25 | 26 | ## Entity/entity relationships 27 | 28 | * Dependency: 29 | * if A then B / if A then not B 30 | * if A then (pattern), e.g. if A then (B or C), if A then (B and (C or D)), etc. 31 | * Choice 32 | * one of (list), not one of (list) 33 | 34 | ## Entity/property relationships 35 | 36 | * Dependency 37 | * if E1 then P1, if E1 then (patterns of P) 38 | * Choice 39 | * one of (list), not one of (list) 40 | 41 | ## Property/property relationships 42 | 43 | * Dependency: 44 | * if A then B / if A then not B 45 | * if A then (pattern), e.g. if A then (B or C), if A then (B and (C or D)), etc. 46 | * value of A / relationship / value of B (greater than, less than, equal to) 47 | * Choice 48 | * one of (list), not one of (list) 49 | * Compound 50 | * A and B must both be present 51 | 52 | ## Property/value relationships 53 | 54 | There will be many tests that can be done on property values, including ones with dependencies and choices. Some are enumerated here. 55 | 56 | | Property value | must/must not| 57 | | -------------- | ------------ | 58 | | value type | | 59 | | value list (choice) | | 60 | | value pattern (regex) | | 61 | 62 | ## Value/value relationships 63 | 64 | * greater than/less than 65 | * birth date must be less than death date 66 | 67 | ## Open/Closed 68 | 69 | The overall validation may require that the rules be closed, that is, that only the entities and properties in the Application Profile may be present. The presence of other entities or properties will be flagged as an error. [There will need to be a default of either open or closed that can be over-ridden.] 70 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # RDF-AP 2 | (possibly a future [VOWEL - web vocabulary language](https://kcoyle.blogspot.com/2019/03/id-like-to-buy-vowel.html)) 3 | 4 | This is ongoing work to modify the DC-Description Set Profile, taking into account the vocabularies of ShEx and SHACL. 5 | 6 | ## DSP vocabulary project 7 | * [Proposed vocabulary](https://github.com/dcmi/dcap/blob/master/schemaList.csv) for profiles 8 | * [DSP ontology](https://github.com/dcmi/dcap/blob/master/dsp.ttl) 9 | * [Diagram](dspDiagram2.jpg) for this vocabulary 10 | * [Diagram with rules](dspDiagram.jpg) proposes a possible way to include more complex rules within the profile 11 | * [Comparison](BIBFRAMEcompare.csv) of the proposed vocabulary with other profile vocabularies, including DSP 12 | 13 | ## Background on project 14 | 15 | ### Basic use cases 16 | * People need a simple way to describe their metadata terms for use and reuse 17 | * People need a simple way to convey their data model to others 18 | * There is a need for a way to define and communicate the "business rules" for their data; an extra plus is if those rules are or can be made actionable 19 | 20 | ### Goals 21 | * Define a basic vocabulary (a core) for creating metadata application profiles including some basic constraints 22 | * Extra: make this modular so units can be reused 23 | * Define formal validation rules for basic vocabulary 24 | * Extra: create these as code, or that can be converted to code 25 | * Extra: make these modular and reusable 26 | 27 | ### Files 28 | 29 | [Requirements](requirements.md) is a list of requirements. 30 | 31 | [Use cases](Use_cases.md) is a gathering of use cases relevant to the task. 32 | 33 | [Start of a vocabulary schema](schemaList.csv) that is loosely based on the [DCMI Description Set Profile](http://dublincore.org/documents/dc-dsp/) 34 | 35 | [Comparison](BIBFRAMEcompare.csv) with BIBFRAME profiles, and others 36 | 37 | [Patterns](Patterns.md) proposes a basic list of design patterns used for metadata description and validation. 38 | 39 | [Description Set Profile - 2](DSPedited.md) is a re-writing of the DSP document. 40 | 41 | A [directory](https://github.com/kcoyle/RDF-AP/tree/master/csv) with some attempts at creating CSV files for a simple profile. 42 | 43 | ### Summary 44 | 45 | From 2014 to 2016 a Dublin Core task group met to discuss the requirements for an [application profile for RDF data](https://github.com/dcmi/repository/blob/master/mediawiki_wiki/RDF_Application_Profiles.md). These requirements were input to the W3C RDF validation working group that developed [SHACL](https://www.w3.org/TR/shacl/). RDF validation, however, is not the same as a profile, therefore a suitable "core" of functions for simple application profiles is still needed. 46 | 47 | This site is one vision of a simple solution to the needs of metadata developers for a standard application profile definition. It leans toward RDF metadata but could be applied to other solutions. The basic assumption (see the [Requirements](requirements.md) document) is that there are many people designing and employing metadata who do not have either extensive metadata training nor available tools to aid them. In keeping with its history of providing a core vocabulary for metadata, the documents here attempt to define a very basic core vocabulary for the description of metadata profiles. 48 | 49 | Many metadata profiles "in the wild" make use of tables (rows and columns) in their documentation. For this reason, this project includes an alignment with the W3C's [tabular metadata](https://www.w3.org/TR/tabular-metadata/) work (also known as CSV on the Web, or CSVW). Such a solution would allow developers to create their metadata as a set of tables, which could then be converted to serializations such as RDF or JSON. These profiles would also support instance data in table form. (Support for non-tabular profiles is not ruled out. This can be considered a first, experimental step using tables as a "low hanging fruit.") 50 | 51 | Eventually, it is desirable that metadata profiles be actionable. Part of this would be the ability to transform profile descriptions into validation schemas for the instance data that the profile defines. Thus a profile would generate the code needed to validate instance data that professes to follow that profile. Currently, DCMI is working with the [ShEx](http://shex.io) working group to align the metadata profile proposal with ShEx validation rules. 52 | 53 | 54 | -------------------------------------------------------------------------------- /Use_cases.md: -------------------------------------------------------------------------------- 1 | # Use Cases 2 | 3 | ## Multiple sources 4 | 5 | I have more than one source of input, and they have some differences between them. I want to be able to gather this information in a single profile so I can mix that data with my own. Here is an example: 6 | 7 | Source A has an "address" field that puts the entire address into a single string, like: 8 | 9 | 3333 Main Street, Arlington, Virginia, 10010 10 | 11 | Source B has an "address" structure that uses Vcard: 12 | 13 | ADR;HOME:;;42 Plantation St.;Baytown;LA;30314;USA 14 | 15 | Source C uses the following structure: 16 | 
17 |   AddressId
18 |   Line1
19 |   Line2
20 |   Line3
21 |   City
22 |   ZipOrPostcode
23 |   StateProvinceCounty
24 |   CountryId
25 |   OtherAddressDetails
-------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate -------------------------------------------------------------------------------- /catalog-v001.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /csv/description.csv: -------------------------------------------------------------------------------- 1 | descID,label,shortDescription,longDescription,minOccur,maxOccur 2 | "d345","Book","Description of a book","The full bibliographic description of a book.",1,1 3 | "d346","Author","Information about the author","Name of the author and any other identifying information",0,-1 4 | "d347","Publisher","Publisher information","This identifies the publisher and can include a city or full address",0,1 5 | -------------------------------------------------------------------------------- /csv/descriptionSet.csv: -------------------------------------------------------------------------------- 1 | descSetID,version,versionDate,topic,creator,descriptions 2 | "ds123","v.1","20171101","books","kcoyle","d345" 3 | -------------------------------------------------------------------------------- /csv/rule.csv: -------------------------------------------------------------------------------- 1 | 2 | id,ruleType,rule,about 3 | -------------------------------------------------------------------------------- /csv/smtVal1.csv: -------------------------------------------------------------------------------- 1 | d345,bookTitle 2 | d345,bookLanguage 3 | d345,mediaType 4 | d345,ISBN 5 | d345,pubDate 6 | d346,AUName 7 | d346,AUBirth 8 | d346,AUDeath 9 | d347,publisher 10 | d347,placeOfPub 11 | -------------------------------------------------------------------------------- /csv/smtVal2.csv: -------------------------------------------------------------------------------- 1 | descID,stmtId,IRI,VType,maxLen,minLen,example,selectList,pattern 2 | d345,bookTitle,dct:title,xs:string,250,1,Moby Dick,, 3 | d345,bookLanguage,dct:language,xs:string,64,2,"eng,fre",,http://id.loc.gov/vocabulary/iso639-2* 4 | d345,mediaType,dct:type,xs:anyURI,,,text,, 5 | d345,ISBN,schema:isbn,xs:string,20,10,9781250066206,, 6 | d345,pubDate,dct:date,xs:gYear,4,4,2006,, 7 | d346,AUName,foaf:name,xs:string,100,2,J.K. Rowling,, 8 | d346,AUBirth,bio:birth,xs:dateTime,20,4,19190512,, 9 | d346,AUDeath,bio:death,xs:dateTime,20,4,20030923,, 10 | d347,publisher,schema:publisher,xs:string,60,2,,, 11 | d347,placeOfPub,schema:city,xs:string,60,2,"London, New York",, 12 | -------------------------------------------------------------------------------- /csv/statement.csv: -------------------------------------------------------------------------------- 1 | stmtID,displayName,shortDescription, usage note,minOccurs,maxOccurs 2 | bookTitle,Title,"Main title of the book, transcribed.",,1,1 3 | bookLanguage,Language,One or more languages of the text,,1,1 4 | mediaType,Media Type,One of the DC type values,uses one of the media types defined in Dublin Core,1,3 5 | ISBN,ISBN,ISBN of the book,,0,2 6 | pubDate,Publication date,Usually the year of publication of copyright,,0,1 7 | AUName,Author,name of the author or creator,"The name of the author, last name forst",0,3 8 | AUBirth,Birth date,birth date (usually year) if known,Include as much of the author's birth date as is available,0,1 9 | AUDeath,Death date,death date (usually year) if known,Include as much of the author's death date as is available.,0,1 10 | publisher,Publisher,name of publisher of the resource,,0,1 11 | placeOfPub,Place of publication,City of publication,may be a comma delimited list of cities,0,1 12 | -------------------------------------------------------------------------------- /csv/values.csv: -------------------------------------------------------------------------------- 1 | valueId,IRI,VType,displayName,description,maxLen,minLen,usageNote,example,selectList,pattern 2 | bookTitle,dct:title,xs:string,Title,"title of the book",250,1,,"Moby Dick",, 3 | bookLanguage,dct:language,xs:string,Language,"language(s) of the book",64,2,,"eng, fre",,http://id.loc.gov/vocabulary/iso639-2* 4 | mediaType,dct:type,xs:anyURI,"Media type","the medium of the work",,,"uses one of the media types defined in Dublin Core as 'type'","text",, 5 | ISBN,schema:isbn,xs:string,ISBN,"the ISBN of the book",20,10,,"9781250066206",, 6 | pubDate,dct:date,xs:gYear,Publication date,the year of publication or copyright that is on the piece,4,4,,"2006",, 7 | AUName,foaf:name,xs:string,Author name,"the name of the author",100,2,"the name of the author as shown on the piece.","J.K. Rowling",, 8 | AUBirth,bio:birth,xs:dateTime,Birth date,"The birth date of the author",20,4,include as much of the author's birth date as is available,"19190512",, 9 | AUDeath,bio:death,xs:dateTime,Death date,"the death date of the author",20,4,include as much of the author's death date as is available,"20030923",, 10 | publisher,schema:publisher,xs:string,Publisher,"the name of the publisher",60,2,,,, 11 | placeOfPub,schema:city,xs:string,Place of publication,"the place of publication",60,2,"the city or cities of publication listed on the item","London, New York",, 12 | -------------------------------------------------------------------------------- /dspDiagramWRules.uxf: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10 4 | 5 | UMLClass 6 | 7 | 0 8 | 40 9 | 210 10 | 130 11 | 12 | Description Set 13 | -- 14 | id 15 | version 16 | version date 17 | topic 18 | creator 19 | 20 | 21 | 22 | UMLClass 23 | 24 | 50 25 | 250 26 | 210 27 | 170 28 | 29 | Description 30 | -- 31 | id 32 | display name 33 | short description 34 | long description 35 | minOccur 36 | maxOccur 37 | standalone? 38 | class(list) 39 | rule 40 | 41 | 42 | 43 | 44 | UMLClass 45 | 46 | 280 47 | 60 48 | 220 49 | 160 50 | 51 | Statement 52 | -- 53 | id 54 | display name 55 | short description 56 | long description 57 | minOccurs 58 | maxOccurs 59 | value type 60 | rule 61 | 62 | 63 | 64 | UMLClass 65 | 66 | 530 67 | 410 68 | 210 69 | 120 70 | 71 | object value 72 | -- 73 | id 74 | IRI list constraint 75 | Unique IRI constraint 76 | Value class constraint 77 | rule 78 | 79 | 80 | 81 | UMLClass 82 | 83 | 530 84 | 230 85 | 210 86 | 150 87 | 88 | literal value 89 | -- 90 | id 91 | Literal list constraint 92 | Literal maximum length 93 | Literal minimum length 94 | Language tag constraint 95 | Unique language constraint 96 | Language list constraint 97 | rule 98 | 99 | 100 | 101 | UMLClass 102 | 103 | 520 104 | 80 105 | 210 106 | 120 107 | 108 | datatype value 109 | -- 110 | id 111 | Datatype 112 | Datatype constraint 113 | Dataype list constraint 114 | Datatype value constraint 115 | rule 116 | 117 | 118 | 119 | UMLClass 120 | 121 | 240 122 | 460 123 | 210 124 | 70 125 | 126 | rule 127 | -- 128 | id 129 | ruleType 130 | (shex?) 131 | 132 | 133 | 134 | Relation 135 | 136 | 100 137 | 160 138 | 80 139 | 110 140 | 141 | lt=<<<<- 142 | 60.0;90.0;10.0;10.0 143 | 144 | 145 | Relation 146 | 147 | 180 148 | 130 149 | 120 150 | 140 151 | 152 | lt=<<<<- 153 | 100.0;10.0;10.0;120.0 154 | 155 | 156 | Relation 157 | 158 | 350 159 | 150 160 | 190 161 | 60 162 | 163 | lt=<<<- 164 | 170.0;10.0;10.0;40.0 165 | 166 | 167 | Relation 168 | 169 | 350 170 | 180 171 | 200 172 | 130 173 | 174 | lt=<<<- 175 | 180.0;110.0;10.0;10.0 176 | 177 | 178 | Relation 179 | 180 | 350 181 | 180 182 | 190 183 | 310 184 | 185 | lt=<<<- 186 | 170.0;290.0;10.0;10.0 187 | 188 | 189 | Relation 190 | 191 | 330 192 | 210 193 | 40 194 | 260 195 | 196 | lt=<<<- 197 | 10.0;240.0;20.0;10.0 198 | 199 | 200 | Relation 201 | 202 | 180 203 | 410 204 | 80 205 | 80 206 | 207 | lt=<<<- 208 | 60.0;60.0;10.0;10.0 209 | 210 | 211 | Relation 212 | 213 | 350 214 | 190 215 | 180 216 | 280 217 | 218 | lt=<<<- 219 | 10.0;260.0;160.0;10.0 220 | 221 | 222 | Relation 223 | 224 | 360 225 | 310 226 | 190 227 | 170 228 | 229 | lt=<<<- 230 | 10.0;150.0;170.0;10.0 231 | 232 | 233 | Relation 234 | 235 | 440 236 | 490 237 | 100 238 | 30 239 | 240 | lt=<<<- 241 | 10.0;10.0;80.0;10.0 242 | 243 | 244 | -------------------------------------------------------------------------------- /dspdiagram2.md: -------------------------------------------------------------------------------- 1 | # Diagram "2" 2 | 3 | This diagram does not include the table of "rules", which would be the ShEx or SHACL code bits. It is a simplification, but includes the local and foreign keys that hold the relationships between the tables. 4 | -------------------------------------------------------------------------------- /options.md: -------------------------------------------------------------------------------- 1 | 2 | # Options for Profile Formats 3 | 4 | ## Markdown 5 | 6 | Pros 7 | 8 | - Easy 9 | - Translates to HTML 10 | - Easily shared 11 | - Wysiwig editors? 12 | 13 | Cons 14 | 15 | - Very linear 16 | - Hard to do boxes or call outs or organize the page visually 17 | 18 | 19 | ## Wiki 20 | 21 | Pros 22 | 23 | - Easy enough 24 | - Can create info boxes with key/value pairs 25 | 26 | Cons 27 | 28 | - Requires an installed wiki 29 | - Can export? HTML? PDF? 30 | 31 | 32 | ## Schema / html 33 | 34 | Pros 35 | 36 | - HTML is well-known 37 | - Immediately web-visible 38 | - Lots of formatting options 39 | 40 | Cons 41 | 42 | - Embedding schema data can be complex - any editors? 43 | - Data would need to be rdf or some ML 44 | -------------------------------------------------------------------------------- /requirements.md: -------------------------------------------------------------------------------- 1 | # Requirements and motivation for a DC-AP 2 | 3 | Why? Who? What? How? Why do we want to create profiles? Who needs them? What functions do they need to provide? How will they work? 4 | 5 | ## Why? 6 | 7 | Help someone else understand your data well enough to make use of it. This is not unlike the more general problem with open source: you can declare your code ‘open’ and wish people ‘good luck’ or you can provide support. 8 | 9 | * To understand variations 10 | * on a standard 11 | * among partners 12 | * within a community 13 | * along a workflow 14 | * To build consensus 15 | * by making decisions visible 16 | * by providing a focus for process 17 | * To drive applications 18 | * To drive user interfaces 19 | * input forms 20 | * displays 21 | * To provide a framework for developing metadata templates 22 | 23 | ## Who? 24 | * Creators: anyone providing data 25 | * Users 26 | * anyone who can/is allowed to access the data 27 | * both people AND machines - not an either/or, but should be both (? if not both, then people?) 28 | 29 | ## What? 30 | * To describe the basic structure of the data 31 | * To characterize the story that the data is designed to tell 32 | * To characterize the things described, and how they are described 33 | * To enumerate the elements that "anchor" a dataset? (E.g., the unique keys of a dbms: what has to be there to make the data useful) 34 | * To describe the content of the data in more detail 35 | * subjects - properties - objects 36 | * things - attributes - values 37 | * To describe the things that the metadata is "about" 38 | * How are those things defined? 39 | * How are they described? 40 | * How are the things related among themselves 41 | * What things can stand alone (i.e., be described independently of related things)? 42 | * Properties, attributes, elements (use the one that makes most sense to you, assume they are the same) 43 | * What properties define the things? are required? 44 | * What are the relationships between properties? 45 | * Objects, values (same) 46 | * What is the value type or types for each property 47 | * what are/is the range of/ valid values 48 | * can values change? How? 49 | * To describe relationships between values (e.g. start date <= end date) 50 | 51 | ## Administration of the profile 52 | * Versioning 53 | * Creator 54 | * Rights 55 | ## How? 56 | * markdown -> html 57 | * wiki 58 | * html with schema.org 59 | -------------------------------------------------------------------------------- /shex4simple.txt: -------------------------------------------------------------------------------- 1 | PREFIX : 2 | PREFIX xsd: 3 | 4 | start = @ 5 | 6 | { # A Profile has: 7 | :Profile_name IRI ; # identifier for the profile 8 | :Profile_label xsd:string {0,1} ; # optional label, not repeatable 9 | :Property @+ # one or more PropertyShape(s) . 10 | } 11 | 12 | { # A Property has: 13 | :Property_name IRI LITERAL; # an identifier, IRI or literal 14 | :Property_label xsd:string* ; # an optional label 15 | :Mandatory ["y" "n"] ; 16 | :Repeatable ["y" "n"] ; 17 | :Value_type xsd:string ; # The type of value - may be pick list? 18 | :Value xsd:string ; # additional value constraints 19 | :Annotation xsd:string ; # any information needed about property + value . 20 | } 21 | -------------------------------------------------------------------------------- /test.csv: -------------------------------------------------------------------------------- 1 | Entity,Entity_label,Property,Property_label,Mand,Repeat,ValueType,Value,Annotation,Prefix,Namespace 2 | book,Book,rdf:type,,,,IRI,sco:Book,,, 3 | ,,dct:creator,Author,y,y,entity,#NAME?,Author is not required; no limit on the number,dct,http://purl.org/dc/terms/ 4 | ,,dct:title,Title,y,n,literal,xsd:string,Each book must have a title,dct,http://purl.org/dc/terms/ 5 | ,,dct:date,Year of publication,y,n,literal,xsd:year,"Only the year, 9999",dct,http://purl.org/dc/terms/ 6 | person,Person,rdf:type,,,,IRI,sco:Person,,, 7 | ,,foaf:Name,Name,y,n,literal,,Each person has one name,foaf,http://xmlns.com/foaf/spec/ 8 | ,,foaf:mbox,Email,n,y,IRI,,Email is optional but only one allowed,foaf,http://xmlns.com/foaf/spec/ 9 | ,,dct:date,Birth year, n,y,literal,xsd:year,"Only the year, 9999",dct,http://purl.org/dc/terms/ 10 | -------------------------------------------------------------------------------- /test2.csv: -------------------------------------------------------------------------------- 1 | Entity,Entity_label,Property,Property_label,Mand,Repeat,ValueType,Value,Annotation,Prefix,Namespace 2 | book,Book,dct:creator,Author,y,y,entity,#NAME?,Author is not required; no limit on the number,dct,http://purl.org/dc/terms/ 3 | ,,dct:title,Title,y,n,literal,xsd:string,Each book must have a title,xsd,http://www.w3.org/2001/XMLSchema# 4 | ,,dct:date,Year of publication,y,n,literal,xsd:year,"Only the year, 9999",, 5 | person,Person,foaf:Name,Name,y,n,literal,,Each person has one name,foaf,http://xmlns.com/foaf/spec/ 6 | ,,foaf:mbox,Email,n,y,IRI,,Email is optional but only one allowed,, 7 | ,,dct:date,Birth year, n,y,literal,xsd:year,"Only the year, 9999",, 8 | --------------------------------------------------------------------------------