-
Notifications
You must be signed in to change notification settings - Fork 55
/
index.html
2058 lines (1988 loc) · 109 KB
/
index.html
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
<!DOCTYPE html>
<html lang="en">
<head>
<title>The Profiles Vocabulary</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link rel="stylesheet" type="text/css" href="style/style.css">
</head>
<body class="h-entry" id="respecDocument">
<section id="abstract">
<h2>Abstract</h2>
<p>
The Profiles Vocabulary is an RDF vocabulary created to allows the machine-readable description of profiles of
specifications for information resources. It can be used to describe profile hierarchies wherein profiles of
specifications may themselves have profiles indicated. It can also link multiple resources that make up a profile
- guidelines, validation tools, schemas, term lists and so on - to it and allows for those resources have formats,
roles, and digital artifacts to be described.
</p>
<p style="text-align: center;">
The namespace for PROF terms is <code>http://www.w3.org/ns/dx/prof/</code>.<br />
The PROF vocabulary, defined in OWL and encoded in RDF Turtle, is available at <a href="rdf/prof.ttl">prof.ttl</a>.
</p>
</section>
<section id="sotd">
<!-- The "Status of This Document" section is generated by config.js -->
<section id="FamilyOfDocs">
<h3>Overview of DXWG documents on profiles</h3>
<p>
This document is one from a set of documents on profiles, edited by the W3C Dataset Exchange Working Group (DXWG) and the Internet Engineering Taskforce (IETF). The documents are:
</p>
<ul>
<li><strong>[DX-PROF] this document, an RDF vocabulary that describes profiles and related resources</strong></li>
<li>[DX-PROF-CONNEG] specific guidance on how to negotiate for Internet resource content using profiles</li>
<li>[[DX-PROF-IETF]] - <em>Indicating and Negotiating Profiles in HTTP</em>: an <a href="http://www.ietf.org">IETF</a> <a href="http://www.ietf.org/standards/ids/">Internet-Draft</a> defining HTTP Headers for HTTP content negotiation by profile</li>
<li>The DXWG also plans to provide [[DX-PROF-GUIDANCE]] - Profile Guidance: general recommendations and guidance on profiling.</li>
</ul>
</section>
</section>
<section id="introduction" class="informative">
<h2>Introduction</h2>
<p>
This Profiles Vocabulary (PROF) provides a standardized, structured and human- & machine-readable set of terms
to describe profiles. Its development was triggered by the appearance of multiple profiles of the Dataset Catalog
Vocabulary (DCAT) [[VOCAB-DCAT]] and examples of profile description and implementation guidance systems such as
the Guidelines for Dublin Core Application Profiles [[DCAP]] and the OpenGeospatial Consortium's Standard for
Modular specifications [[MODSPEC]].
</p>
<p>
Profiles aim to increase interoperability within a community of users by introducing constraints, extensions or
combinations on the use of more general specifications. PROF is an RDF vocabulary created
to describe relations between <a>specifications</a> and profiles and the resources that define and implement
<a>profiles</a>. A <em>specification</em> is "A basis for comparison; a reference point against which other things
can be evaluated." (see the definition below) and a A profile, such as a <a>profile</a> or perhaps an
<em>application profile</em>, is defined as "A [data/application] specification that constrains, extends, combines,
or provides guidance or explanation about the usage of other [data/application] specifications". Profile resources
may be human-readable documents (PDFs, textual documents), vocabularies, schemas or ontologies (XSD, RDF),
constraint language resources used by specific validation tools (SHACL, ShEx, Schematron), or any other files or
resources that support the profile. In this specification, each resource is defined as having a role that defines
its function within the profile.
</p>
<p>
This vocabulary's ontological basis for specification/profile relations is a specialization of the
<code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">dct:Standard</a></code>
class which is defined here as a <code><a href="#Class:Profile">prof:Profile</a></code>. A <code>prof:Profile</code>
is related to either <code>dct:Standard</code> or <code>prof:Profile</code> instances by being a <em>profile of</em>
them, formally, <a href="#Property:isProfileOf"><code>prof:isProfileOf</code></a>. Resources that conform to either a
<code>dct:Standard</code> or a <code>prof:Profile</code> are formally described as doing so with the use of the
<code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-conformsTo">dct:conformsTo</a></code>
predicate.
</p>
<p>
Data that conforms to a profile, in PROF, must conform to anything the profile is a profile of. Formally, this vocabulary
includes the property chain axiom <code>dct:conformsTo owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo )</code>.
Individual communities may define what conformance to their profiles and the things they profile means and how to
test for conformance if indeed they wish to.
</p>
<div class="issue" data-number="1078"></div>
<p>
In recognition of the existence of specifications and profiles that are made up of multiple resources –
perhaps PDF documents, machine-readable constraint language files, code lists etc. – this vocabulary also
provides for the description of the parts that constitute a profile or a specification. It defines a
<a href="#Class:ResourceDescriptor"><code>prof:ResourceDescriptor</code></a> class which is used to qualify the
relationship between a profile and its part resources. A <code>prof:Profile</code> may have any number of
<a href="#Property:hasResource"><code>prof:hasResource</code></a> predicates indicating <code>prof:ResourceDescriptor</code>
instances which then indicates the location (a URI) of the actual resource artifact with a
<a href="#Property:hasArtifact"><code>prof:hasArtifact</code></a> predicate and then may describes the artifact's
format and any specifications it conforms to with <a href="#Property:format"><code>dct:format</code></a> &
<a href="#Property:conformsTo"><code>dct:conformsTo</code></a> predicates respectively. The role that the resource
plays with respect to the profile may be indicating using a <a href="#Class:ResourceRole"><code>prof:ResourceRole</code></a>
class instance linked to it with the <a href="#Property:hasRole"><code>prof:hasRole</code></a> predicate.
</p>
<p>
A vocabulary of <code>prof:ResourceRole</code> instances is provided in <a href="#resource-roles-vocab"></a> but
communities are encouraged to create additional <code>prof:ResourceRole</code> instances with definitions suited to
their purposes.
</p>
</section>
<section id="conformance">
<!-- boilerplate will be added here -->
<p>
For the purpose of compliance, the normative sections of this document are:
</p>
<ul>
<li><a href="#conceptualmodel"></a>,</li>
<li><a href="#specification"></a> &</li>
<li><a href="#testsuite"></a>.</li>
</ul>
<section id="notationalconventions">
<h3>Notational Conventions</h3>
<p>
The keywords <dfn>may</dfn>, <dfn>must</dfn>, <dfn>must not</dfn>, <dfn>optional</dfn>, <dfn>shall</dfn>,
<dfn>shall not</dfn>, <dfn>should</dfn>, <dfn>should not</dfn>, <dfn>recommended</dfn>, <dfn>required</dfn>,
in this document are to be interpreted as described in [[RFC2119]].
</p>
</section>
<section id="diagramconventions">
<h3>Diagram Conventions</h3>
<p>
All diagrams in this specification, apart from <a href="#fig-skos-4.5.2"></a>, use elements defined in this key.
The tokens in the key are defined in <a href="#namespaces"></a>.
</p>
<figure id="fig-element-key">
<a href="figures/element-key.svg">
<img src="figures/element-key.svg" alt="Diagram's element key" />
</a>
<figcaption>A key of the elements used in this specification's diagrams</figcaption>
</figure>
</section>
</section>
<section id="definitions">
<h2>Definitions</h2>
<dl>
<dt><dfn data-lt="specification">specification</dfn></dt>
<dd>
<p>
A basis for comparison; a reference point against which other things can be evaluated.
</p>
<p>
<em>Source: DCMI Metadata Terms [[DCTERMS]]'s definition for a <code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">Standard</a></code>.</em>
</p>
</dd>
<dt><dfn data-lt="data specification">data specification</dfn></dt>
<dd>
<p>
A <a>specification</a>, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.
</p>
</dd>
<dt><dfn data-lt="profile">data profile</dfn></dt>
<dd>
<p>
A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.
</p>
<p>
This definition includes what are sometimes called "application profiles", "metadata application profiles", or "metadata profiles". In this document, "data profile" and these other variants are all referred to as just "profiles".
</p>
</dd>
<dt><dfn>resource</dfn></dt>
<dd>
The entity that is identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose. [[RFC3986]]
</dd>
<dt><dfn>metadata</dfn></dt>
<dd>Information that is supplied about a resource. [[RFC3986]]</dd>
<dt><dfn>token</dfn></dt>
<dd>
<p>A short name identifying something.</p>
<p>In the context of this specification, it is a <a>profile</a> that is usually identified by a token.</dd>
</dl>
</section>
<section id="namespaces">
<h2>Namespaces</h2>
<p>
The namespace for PROF is <strong><code><a href="http://www.w3.org/ns/dx/prof/">http://www.w3.org/ns/dx/prof/</a></code></strong>.
However, it should be noted that PROF makes use of terms from other vocabularies, in particular Dublin Core [[!DCTERMS]].
PROF itself only defines a minimal set of classes and properties of its own.
</p>
<p>
PROF also makes use of derivative namespaces of it's namespace for auxiliary vocabulary elements, such as instances
of the <code>prof:ResourceRole</code> which are within the <code>http://www.w3.org/ns/dx/prof/role/</code> namespace.
</p>
<p>
A full set of namespaces and prefixes used in this specification is given in the table below.
</p>
<table id="namespaces-table">
<thead>
<tr><th>Prefix</th><th>Namespace</th></tr>
</thead>
<tbody>
<tr><td>dcat</td><td>http://www.w3.org/ns/dcat#</td></tr>
<tr><td>dct</td><td>http://purl.org/dc/terms/</td></tr>
<tr><td>owl</td><td>http://www.w3.org/2002/07/owl#</td></tr>
<tr><td><strong>prof</strong></td><td><strong><a href="http://www.w3.org/ns/dx/prof/">http://www.w3.org/ns/dx/prof/</a></strong></td></tr>
<tr><td>role</td><td>http://www.w3.org/ns/dx/prof/role/</tr>
<tr><td>prov</td><td>http://www.w3.org/ns/prov#</td></tr>
<tr><td>rdf</td><td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td></tr>
<tr><td>rdfs</td><td>http://www.w3.org/2000/01/rdf-schema#</td></tr>
<tr><td>skos</td><td>http://www.w3.org/2004/02/skos/core#</td></tr>
<tr><td>xsd</td><td>http://www.w3.org/2001/XMLSchema#</td></tr>
<tr><td>(others)</td><td>All other namespace prefixes are used in examples only. <br>
In particular, IRIs starting with "http://example.org" represent some application-dependent IRI [[RFC3987]]</td></tr>
</tbody>
</table>
</section>
<section id="motivation" class="informative">
<h2>Motivation</h2>
<p>
Until this vocabulary's creation, there was no formal W3C method for describing the objects (Internet resources)
used for <a>profiles</a>.
</p>
<p>
There are a multitude of ways to describe the components needed to define a profile and support validation of data
to profiles, such as:
</p>
<ul>
<li>human-readable documents stating requirements (e.g. [[PDF]]) </li>
<li>usage and guidance notes</li>
<li>
machine readable constraint languages (e.g. the abstract (Dublin Core's Description Set Profiles [[DCDSP]]) or
the more concrete (SHACL [[SHACL]] & ShEx [[SHEX]]).
</li>
</ul>
<p>
Describing the components within a profile via documents or constraint languages does not indicate many things
either important or interesting to know about a profile such as:
</p>
<ul>
<li>its dependence on standards or other profiles</li>
<li>inheritance of profile information from the things being profiled, or</li>
<li>related profile resources
<ul>
<li>
guidance documents in addition to formal constraints
</li>
<li>
equivalent constraints written in different constraint languages for different forms of resource, e.g. SHACL
for RDF and Schematron [[SCHEMATRON]] for XML.
</li>
</ul>
</li>
</ul>
<p>
With a mechanism to relate profiles to specifications and other profiles, profile hierarchies can be established
which will:
</p>
<ul>
<li>
assist with the reuse of existing profiles
<ul>
<li>
one can profile another profile, adding a small set of additional constraints and declaring compatibility
with all profiled specifications.
</li>
<li>
reducing the total effort and information necessary to specify a profile
</li>
</ul>
</li>
<li>
allow for machine interpretation of profiles and automated profile negotiation with fallback options
<ul>
<li>
if a client requests a profile which a server cannot deliver, a server may be able to instead deliver a more
generic version of the requested resource, using a profile link to the thing it profiles
</li>
<li>
a client may be able to generate a request that already indicates acceptable fallback options for resources
when the primary requested profile is unavailable
</li>
</ul>
</li>
</ul>
<section id="motivating-requirements">
<h4>Motivating Requirements</h4>
<p>
For the purposes of dataset exchange and with the lack of a formal W3C method for describing the objects related
to profiles, the DXWG undertook a process of Use Case and Requirements gathering. They established the
<a href="https://www.w3.org/TR/dcat-ucr/">Dataset Exchange Use Case and Requirements</a> document
(the UCR document) [[DCAT-UCR]] which groups requirements for profiles into the following sections:
</p>
<ul>
<li><a href="https://www.w3.org/TR/dcat-ucr/#ProfileAbstractRequirements">6.10 Profiles — abstract requirements applying to the general definition of profiles</a></li>
<li><a href="https://www.w3.org/TR/dcat-ucr/#ProfileFunctionalityRequirements">6.11 Profiles — Profile functionality</a></li>
<li><a href="https://www.w3.org/TR/dcat-ucr/#ProfileDistributionRequirements">6.12 Profiles — Profile distributions</a></li>
<li><a href="https://www.w3.org/TR/dcat-ucr/#ProfileMetadataRequirements">6.13 Profiles — Profile metadata</a></li>
</ul>
<p>
PROF addresses many of those Requirements – those that can be addressed by describing
profile components and relations – and those Requirements link back to the Use
Cases that motivated them.
</p>
<p>
The UCR document lists a further profiles Requirements section:
<a href="https://www.w3.org/TR/dcat-ucr/#ProfileNegotiationRequirements">6.14 Profile and content negotiation</a>
however those are not addressed here but by the related [[DX-PROF-CONNEG]] document.
</p>
</section>
</section>
<section id="relatedwork" class="informative">
<h2>Related Work</h2>
<p>
Here several RDF vocabularies related to PROF are described as well as non-RDF initiatives and models.
</p>
<section id="related-owl">
<h3>Web Ontology Language (OWL)</h3>
<p>
OWL [[OWL2-OVERVIEW]] is an RDF-based ontology language that provides for the description of classes, properties,
individuals, and data values which are stored as Semantic Web documents. PROF uses many OWL properties, classes
and structures and is easily recognizable as a specialized OWL ontology.
</p>
<p>
Regarding profiling, none of the various OWL (or the updated OWL2) specifications directly address profiling, as
it's understood here, however OWL does include "ontology properties" that "can be used to associate information
with an ontology" [[owl2-rdf-based-semantics]] (<a href="https://www.w3.org/TR/owl2-syntax/#Ontology_Annotations">§ 3.5 Ontology Annotations</a>).
In particular, the ontology and annotation property <code>owl:imports</code> allows an ontology to indicate that
it <em>imports</em> other ontology[ies] "in order to gain access to their entities, expressions, and axioms,
thus providing the basic facility for ontology modularization" (<a href="https://www.w3.org/TR/owl2-syntax/#Imports">§ 3.4 Imports</a>).
</p>
<p>
<code>owl:imports</code> is included in OWL to facilitate the closure of ontology semantics within systems used to
manipulate ontology data and is a technical convenience mechanism. It does not make any strong ontological claim
about the relationship of the two ontologies joined by it nor does it make any conceptual claim about the
importing ontology's specific use of the imported ontology, only that some use/reuse is implied. It is not possbile,
with <code>owl:imports</code>, or any other OWL ontology property, to know that data conforming to an ontology
also conforms to another ontology.
</p>
<p>
It <em>is</em> possible to know, on a per-class or property basis, that data elements conform to particular
ontologies through inspection of those elements. Ontologies that use OWL (and RDF [[RDF11-CONCEPTS]] & RDF
Schema [[RDF-SCHEMA]]) declare classes and properties as being of a particular defined class by using
<code>rdf:type</code> – <code>:myNewClassInstance rdf:type ex:SomeExistingClass</code> – which claims
conformance to the indicated class or property. Newly declared classes and properties may also claim conformance
to existing classes or properties by using <code>rdfs:subClassOf</code> or <code>rdfs:subPropertyOf</code>
respectively.
</p>
<p>
These data or ontology element conformances do not indicate conformance or whole profiles to other specifications
or profiles or of instance data to specifications or profiles.
</p>
</section>
<section id="related-dcat">
<h3>Data Catalog Vocabulary (DCAT)</h3>
<p>
DCAT was originally published as a W3C Recommendation in 2014 [[VOCAB-DCAT]] and has now been revised by the DXWG
[[VOCAB-DCAT-2]]. The revised version is backward-compatible with the original and the intention of the vocabulary
– to facilitate interoperability between data catalogs published on the Web – is unchanged.
</p>
<p>
Original and revised DCAT allow for the descriptions of <code>dcat:Catalog</code> instances which contain
<code>dcat:Dataset</code> instances which may be <em>distributed</em> – delivered in a specific form –
as <code>dcat:Distribution</code> instances.
</p>
<p>
PROF borrows its main structures from DCAT in that PROF's <code>prof:Profile</code> & <code>prof:ResourceDescriptor</code>
classes parallel DCAT's <code>dcat:Dataset</code> & <code>dcat:Distribution</code> classes.
</p>
<p>
The main subject that differentiates PROF from DCAT is that PROF specifically addresses the notion of conformance
– of <a>profiles</a> to <a>specifications</a> or other profiles – about which DCAT is silent. DCAT
does address the notion of instance data conforming to an "established standard" (see it's suggested use of the
<a href="https://www.w3.org/TR/vocab-dcat-2/#Property:resource_conforms_to"><code>dct:conformsTo</code> property</a>
and here – instance data conformance to specifications – DCAT and PROF offer compatible instructions.
</p>
<p>
No normative alignment between DCAT & PROF is presented in this document however they can and should be used
together and informative alignment between them (with revised DCAT [[VOCAB-DCAT-2]]) is given in
<a href="#alignment-dcat"></a>.
</p>
</section>
<section id="related-adms">
<h3>Asset Description Metadata Schema (ADMS)</h3>
<p>
ADMS [[VOCAB-ADMS]] is "a profile of DCAT, used to describe <em>semantic assets</em>" and, as such, follows DCAT's structures
with many class alignments including <code>adms:Asset</code> & <code>adms:AssetDistribution</code> classes
which parallel DCAT's <code>dcat:Dataset</code> & <code>dcat:Distribution</code> classes.
</p>
<p>
ADMS has been specifically designed for documenting an "asset", not only to make it discoverable, but also to
provide contextual information (e.g., who's the publisher, which versions of an asset exist, etc.) and does not
specifically address the core motivating notion for PROF of relating to conformance between profiles and
specifications or profiles. In this regard, the relation of PROF to ADMS is similar to that of PROF to DCAT: there
is some overlap with respect to class structures and the recommended use of particular annotation properties
– title, description, etc. – for class instances.
</p>
<p>
As with DCAT, PROF can and should be used with ADMS however no normative alignment between them is presented here
but an informative alignment is given in <a href="#alignment-adms"></a>.
</p>
</section>
<section id="related-prov">
<h3>PROV-O: The PROV Ontology</h3>
<p>
PROV-O [[PROV-O]] is an ontology that "provides a set of classes, properties, and restrictions that can be used
to represent and interchange provenance information". Further: "It can also be specialized to create new classes
and properties to model provenance information for different applications and domains.".
</p>
<p>
PROV-O is concerned with <em>derivation</em> of things from other things (<code>prov:Entity</code>s from
<code>prov:Entity</code>s), <em>usage/generation</em> of things by events (<code>prov:Entity</code>s from
<code>prov:Activity</code>s), attribution of things to things with agency (<code>prov:Entity</code>s to
<code>prov:Agent</code>s) and the association of events with things with agency and these concerns are presented
as a series of "Starting Point classes and properties" with many "Expanded and qualified classes and properties"
that can be used to specialise their use.
</p>
<p>
PROV-O does not address notions of conformance – of data to specifications/profiles or specifications/
profiles to other specifications/profiles – however the DXWG debated whether <code>prof:isProfileOf</code>
could be considered a sub-property of PROV-O's <code>prov:wasDerivedFrom</code> (see discussion within
<a href="https://github.com/w3c/dxwg/issues/485">DXWG's Issue 485</a>). The outcome of that discussion was that
DXWG felt that since <code>prov:wasDerivedFrom</code> doesn’t say anything about dependency but that
<code>prof:isProfileOf</code> does, it would be of no value to make an <code>rdfs:subPropertyOf</code> assertion
between the two properties. Moreover, <code>prof:isProfileOf</code>'s dependency assertion is seen as conceptual
rather than axiomatic so it would be difficult to define an axiom that could be true in a wide variety of cases.
</p>
</section>
<section id="related-void">
<h3>The VoID Vocabulary</h3>
<p>
"VoID is an RDF Schema vocabulary for expressing metadata about RDF datasets." [[VOID]]. It provides for the
describing of partitioned datasets and links between datasets. It is able to do this since, unlike DCAT (and ADMS),
it caters for datasets only, not datasets in general, and thus is able to know about dataset's structure (as RDF
triples) and therefore how to describe parts within datasets.
</p>
<p>
VoID also allows for indications of how one RDF dataset <em>uses</em> uses one or more RDFS vocabularies or OWL
ontologies. For example, a dataset may indicate the most important, not necessarily all, of the vocabularies it
uses with the <code>void:vocabulary</code> predicate with the used vocabulary's namespaces URI as the object value.
This is similar to OWL's [[OWL2-PRIMER]] <code>owl:imports</code> in that this is an annotation property and does
not make any strong axiomatic claim.
</p>
<p>
VoID does not address <em>dependence</em> or <em>conformance</em> of resource on or two other resources.
</p>
</section>
<section id="related-voaf">
<h3>Vocabulary of a Friend (VOAF)</h3>
<p>
[[VOAF]] provides elements allowing for the description of vocabularies (RDFS vocabularies or OWL ontologies) and,
in particular, "provides properties expressing the different ways such vocabularies can rely on, extend, specify,
annotate or otherwise link to each other.".
</p>
<p>
VOAF declares a <code>voaf:Vocabulary</code> class for identifying RDF vocabularies in order to associate its
properties with them and also makes references to datasets that use vocabulary data. It uses VoID's <code>void:Dataset</code>
class to identify datasets and <code>voaf:Vocabulary</code> is declared as being a sub class of it.
</p>
<p>
VOAF includes a series of predicates to indicate specific relationships between vocabularies and those related to
profiling-like activities are given in the table below.
</p>
<table>
<thead>
<tr>
<th>Property</th><th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>voaf:reliesOn</code></td><td>Indicates that the subject vocabulary uses or extends some class or property of the object vocabulary</td>
</tr>
<tr>
<td><code>voaf:usedBy</code></td><td>Indicates that the subject vocabulary is used by the object vocabulary</td>
</tr>
<tr>
<td><code>voaf:extends</code></td><td>Indicates that the subject vocabulary extends the expressivity of the object vocabulary by declaring subsumption relationships, using object vocabulary class as domain or range of a subject vocabulary property, defining local restrictions etc</td>
</tr>
<tr>
<td><code>voaf:specializes</code></td><td>Indicates that the subject vocabulary defines some subclasses or subproperties of the object vocabulary, or local restrictions on those</td>
</tr>
<tr>
<td><code>voaf:generalizes</code></td><td>Indicates that the subject vocabulary generalizes by some superclasses or superproperties the object vocabulary.</td>
</tr>
<tr>
<td><code>voaf:hasEquivalencesWith</code></td><td>Indicates that the subject vocabulary declares some equivalent classes or properties with the object vocabulary</td>
</tr>
<tr>
<td><code>voaf:hasDisjunctionsWith</code></td><td>Indicates that the subject vocabulary declares some disjunct classes with the object vocabulary.</td>
</tr>
<tr>
<td><code>voaf:similar</code></td><td>Used to assert that two vocabularies are similar in scope and objectives, independently of the fact that they otherwise refer to each other</td>
</tr>
</tbody>
</table>
<p>
VOAF/PROF differentiator here
</p>
</section>
<section id="related-modspec">
<h3>OGC's ModSpec</h3>
<div class="issue" data-number="403"></div>
</section>
<section id="related-constraintlanguages">
<h3>Constraint Languages</h3>
<p>
Constraint languages such as [[SHACL]], [[SHEX]], [[SCHEMATRON]] and the [[DCDSP]] defined rules for validating
the conformance of instance data against sets of conditions.
</p>
<p>
Constraint Languages are frequently used in profile definitions – see <a href="#examples"></a> –
but they may not be all that is needed for a complete definition: frequently profiles also include guidance
documents, examples of use and other resources too.
</p>
<p>
PROF does include the possibility of defining profile parts via instances of the <code>prof:ResourceDescriptor</code>
class with roles via the <code>prof:hasRole</code> property. Using these, profiles may indicate constraint
language profile resources with an appropriate role, such as "constraints" or "validation". The list of
<code>prof:ResourceRoles</code> instances given in <a href="#resource-roles-vocab"></a> may be extended by PROF users
if appropriate roles for their constraint language resource are not found.
</p>
<p>
PROF does not define any new constraint languages or indicate particular languages for use; this is left to
individual communities to determine.
</p>
</section>
</section>
<section id="conceptualmodel">
<h2>Conceptual Model</h2>
<figure id="fig-overview">
<a href="figures/prof.svg">
<img src="figures/prof.svg" alt="Vocabulary overview diagram" />
</a>
<figcaption>OWL [[OWL2-OVERVIEW]] overview diagram of this vocabulary</figcaption>
</figure>
<p>
This vocabulary is for describing relationships between standards/specifications, profiles of them and supporting artifacts such as validating resources.
</p>
<p>
The model takes the <code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">dct:Standard</a></code> Class as a starting point and defines a specialization, a <code>Profile</code>, which is a <code>dct:Standard</code> that <em>profiles</em> a <code>dct:Standard</code> or another <code>Profile</code>. <code>Standards</code>s or <code>Profile</code>s can have <code>Resource Descriptor</code>s associated with
them that define rules for implementation, provide guidance on how to implement, or play some other role. <code>Resource Descriptor</code>s must indicate the role they
play (to guide, to validate etc.), the formalism they adhere to (<code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-format">dct:format</a></code>)
and any <code>dct:Standard</code> that they themselves conform to (<code><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-conformsTo">dct:conformsTo</a></code>).
</p>
<p>
Any <code>rdfs:Resource</code> MAY indicate conformance to a profile as per <a href="#eg-conformance-to-profile"></a>
by using <code>dct:conformsTo</code>. Individual communities MAY determine what constitutes an appropriate URI to
identify a profile.
</p>
<p>
<em>The remainder of this section is informative.</em>
</p>
<section id="initial-examples">
<h3>Initial Examples</h3>
<p>
The example below illustrates the use of most parts of PROF and indicates how non-PROF profile metadata is stored alongside PROF metadata.
</p>
<figure id="fig-initial-example">
<a href="figures/initial.svg">
<img src="figures/initial.svg" title="An example profile of Dublin Core Terms" style="width:90%;" />
</a>
<figcaption>
A full example profile described using common metadata and the Profiles Vocabulary
</figcaption>
</figure>
<pre id="eg-initial-example"
class="example nohighlight turtle" aria-busy="false" aria-live="polite"
title="A full example described using PROF in RDF (turtle)">
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<http://example.org/profile/x> # a Profile; it's identifying URI
a prof:Profile ;
# common metadata for the Profile
# the Profile's label
rdfs:label "Profile X" ;
# regular metadata, a basic description of the Profile
rdfs:comment """This is a Profile of Dublin Core Terms used to describe items in
CSIRO's publications catalogue."""@en ;
# regular metadata, URI of publisher
dct:publisher <http://catalogue.linked.data.gov.au/org/O-000886> ;
# PROF metadata
# this is a profile of Dublin Core Terms, referenced by its namespace
prof:isProfileOf <http://purl.org/dc/terms/> ;
# this profile has a SHACL resource that constrains it's use of Dublin Core
prof:hasResource [
a prof:ResourceDescriptor ;
# it's in Turtle format
dct:format <https://w3id.org/mediatype/text/turtle> ;
# it conforms to SHACL, here refered to by its namespace URI as a Profile
dct:conformsTo <https://www.w3.org/TR/shacl/> ;
# this resource plays the role of "Validation"
# described in this ontology's accompanying Roles vocabulary
prof:hasRole role:Validation ;
# this resource's actual file
prof:hasArtifact <http://example.org/profile/x/resource/validator.ttl>
] ;
# other resources this profile contains
prof:hasResource ... ;
# a short code to refer to the Profile with when a URI can't be used
prof:hasToken "profx"
.
</pre>
<p>
The following example demonstrates how resources can indicate conformance to a profile. Note that in
<a href="#eg-initial-example"></a>, there is also an example of this pattern whereby the <code>ResourceDescriptor</code>
is indicated as conforming to the [[SHACL]] specification, which is also understood to be a profile to which
things may conform.
</p>
<pre id="eg-conformance-to-profile"
class="example nohighlight turtle" aria-busy="false" aria-live="polite"
title="An example demonstrating how resources can indicate conformance to profiles.">
# Profile X
<strong><http://example.org/profile/x> a prof:Profile</strong> ;
dct:title "Profile X" .
# A resource indicating conformance to Profile X.
# In this example it's a DCAT Dataset's Distribution
<http://example.org/dataset/001>
a dcat:Dataset ;
dcat:distribution :dataset-001-x .
:dataset-001-x
a dcat:Distribution ;
dct:title "Distribution of imaginary dataset 001 that conforms to Profile X" ;
dcat:downloadURL <http://www.example.org/files/001.x> ;
<strong>dct:conformsTo <http://example.org/profile/x></strong> .
</pre>
<p>
This next example shows how a conclusion about conformance can be drawn due to this vocabulary's inclusion of a
property chain axiom about conformance.
</p>
<pre id="eg-conformance-axiom"
class="example nohighlight turtle" aria-busy="false" aria-live="polite"
title="Demonstrating conformance via the vocabulary's dct:conformsTo/prof:isProfileOf property chain.">
# Profile X, is a profile of Specification Y
<http://example.org/profile/x> a prof:Profile ;
prof:isProfileOf <http://example.org/specification/y>
dct:title "Profile X" .
# A resource indicating conformance to Profile X is given
<http://example.org/resource/a>
dct:conformsTo <http://example.org/profile/x> .
# Due to the property chain axiom:
# dct:conformsTo owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo )
# the resource above can be inferred to conform to Specification Y
<http://example.org/resource/a>
<strong>dct:conformsTo <http://example.org/specification/y></strong> . # this triple is inferred
</pre>
</section>
<section id="roles-vocab">
<h3>Roles Vocabulary</h3>
<p>
A starting point vocabulary of <code>Resource Role</code> instances that is expected to be extended by
implementers of PROF to suite specialised needs is provided within this vocabulary in
<a href="#resource-roles-vocab"></a>.
</p>
</section>
</section>
<section id="specification">
<h2>Vocabulary Specification</h2>
<section id="RDF-representation">
<h4>RDF representation</h4>
<p>The PROF vocabulary is available in RDF via the vocabulary namespace (<code><a href="https://www.w3.org/ns/dx/prof/">https://www.w3.org/ns/dx/prof/</a></code>). Alongside the primary artifact, there is
a set of other RDF files that provide additional information, including:</p>
<ol>
<li>
alignments to other vocabularies, some of which are normative, and others which are for guidance only
</li>
<li>
additional axioms, which can be useful in some contexts
</li>
<li>
validating graphs using [[SHACL]]
</li>
</ol>
<p>These other artifacts are linked to throughout this document.</p>
</section>
<section id="dependencies">
<h3>Dependencies</h3>
<p>
This vocabulary makes use of [[DCTERMS]] properties <code><a href="#Property:conformsTo">conformsTo</a></code> & <code><a href="#Property:format">format</a></code> in its
normative specification.
</p>
</section>
<section id="Class:Profile" class="property">
<h4>Class: Profile</h4>
<table class="definition">
<thead>
<tr><th><a href="https://www.w3.org/TR/owl-syntax/#Classes">OWL Class</a></th><th><a href="#Class:Profile">prof:Profile</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>Profile</td></tr>
<tr>
<td class="prop">Definition:</td>
<td>
<p>
A named set of constraints on one or more identified base specifications or other profiles, including the
identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options
and parameters of those base specifications necessary to accomplish a particular function.
</p>
<p>
This definition includes what are sometimes called "application profiles", "metadata application profiles",
or "metadata profiles".
</p>
</td>
</tr>
<tr><td class="prop">Sub class of:</td><td><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">dct:Standard</a></td></tr>
<tr><td class="prop">Source:</td><td><a href="https://www.w3.org/2017/dxwg/wiki/ProfileContext">https://www.w3.org/2017/dxwg/wiki/ProfileContext</a></td></tr>
<tr><td class="prop">Usage Note:</td><td>The Profile class "may be used to model aspects of data structure and content (as per <a>profile</a>) or any other declared behaviour where a base specification can be identified and further requirements asserted.</td></tr>
</tbody>
</table>
<section id="Property:hasResource" class="property">
<h4>Property: hasResource</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:hasResource">prof:hasResource</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">OWL type:</td><td><a href="https://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties">owl:ObjectProperty</a></td></tr>
<tr><td class="prop">Label:</td><td>has resource</td></tr>
<tr><td class="prop">Definition:</td><td>A resource which describes the nature of an artifact and the role it plays in relation to a profile</td></tr>
<tr><td class="prop">Range:</td><td><a href="#Class:ResourceDescriptor">prof:ResourceDescriptor</a></td></tr>
</tbody>
</table>
</section>
<section id="Property:isProfileOf" class="property">
<h4>Property: isProfileOf</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:isProfileOf">prof:isProfileOf</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">OWL type:</td><td><a href="https://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties">owl:ObjectProperty</a></td></tr>
<tr><td class="prop">Label:</td><td>is profile of</td></tr>
<tr><td class="prop">Definition:</td><td>The subject of 'is profile of' defines constraints on the object which playes the role of a base specification</td></tr>
<tr><td class="prop">Sub property of:</td><td><a href="#Property:isTransitiveProfileOf">prof:isTransitiveProfileOf</a></td></tr>
<tr><td class="prop">Domain:</td><td><a href="#Class:Profile">prof:Profile</a></td></tr>
<tr><td class="prop">Range:</td><td><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">dct:Standard</a></td></tr>
<tr><td class="prop">Usage Note:</td>
<td>
<p>
A Profile may define constraints on the usage of one or more specifications. All constraints of these specifications are inherited, in the sense that an object conforming to a profile conforms to all the constraints specified the targets of prof:isProfileOf relations. This property is optional, allowing any specification to be declared at the root of a profile hierarchy using the Profile class.
</p>
<p>
Note that the axiom within this vocabulary that allows the inference that conformance to a profile means conformance to anything it profiles is part of the definition <code><a href="#Property:conformsTo"></a></code>.
</p>
<p>
The use of this prof:isTransitiveProfileOf as a super-property of prof:isProfileOf allows communities of practice to exploit transitive interpretations of hierarchical network of profiles as they see fit, while not interfering with the semantics of prof:isProfileOf, which cannot enforce such transitivity. Intuitively, one can interpret prof:isProfileOf statements as explicitly asserted direct profiling links, while prof:isTransitiveProfileOf is used to reflect more-general (and possibly indirect) ancestor relationships.
</p>
</td>
</tr>
</tbody>
</table>
</section>
<section id="Property:isTransitiveProfileOf" class="property">
<h4>Property: isTransitiveProfileOf</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:isTransitiveProfileOf">prof:isTransitiveProfileOf</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">OWL type:</td><td><a href="https://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties">owl:ObjectProperty</a></td></tr>
<tr><td class="prop">Label:</td><td>is a transitive profile of</td></tr>
<tr><td class="prop">Definition:</td><td>A specification for which this Profile defines constraints, possibly through a chain of isProfileOf relationships</td></tr>
<tr><td class="prop">Super property of:</td><td><a href="#Property:isProfileOf">prof:isProfileOf</a></td></tr>
<tr><td class="prop">Domain:</td><td><a href="#Class:Profile">prof:Profile</a></td></tr>
<tr><td class="prop">Range:</td><td><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">dct:Standard</a></td></tr>
<tr>
<td class="prop">Usage note:</td>
<td>
<p>
This is a convenience predicate that may be used to declare all specifications (including profiles) that the subject profile requires an information resource to conform to. This avoids forcing clients to traverse a profile hierarchy to find all conformance implications and available resources. If present all such relationships should be present so a client can safely avoid hierarchy traversal.
</p>
<p>
The use of this prof:isTransitiveProfileOf as a super-property of prof:isProfileOf allows communities of practice to exploit transitive interpretations of hierarchical network of profiles as they see fit, while not interfering with the semantics of prof:isProfileOf, which cannot enforce such transitivity. Intuitively, one can interpret prof:isProfileOf statements as explicitly asserted direct profiling links, while prof:isTransitiveProfileOf is used to reflect more-general (and possibly indirect) ancestor relationships.
</p>
</td>
</tr>
</tbody>
</table>
</section>
<div class="note" title="Explanation of profiling transitivity">
<p>
The property <a href="#Property:isTransitiveProfileOf">prof:isTransitiveProfileOf</a> defined here performs a role
similar to that of the property <a href="https://www.w3.org/TR/skos-reference/#semantic-relations">skos:broaderTransitive</a>
defined in [[SKOS-REFERENCE]]. That property "...allows communities of practice to exploit transitive
interpretations of hierarchical networks..." while freeing the simpler hierarchy property of
<a href="https://www.w3.org/TR/skos-reference/#semantic-relations">skos:broader</a> from having to enforce
transitivity which would prevent broader but non-transitive relationships.
</p>
<p>
Figure 4.5.2 from [[SKOS-PRIMER]], reproduced below, illustrates the general principle of use of
<code>skos:broaderTransitive</code>.
</p>
<figure id="fig-skos-4.5.2">
<img src="figures/broaderTransitive.jpg" title="Figure 4.5.1 from the SKOS Primer WG Note" style="width:90%;" />
<figcaption>
Inferring a transitive hierarchy from asserted skos:broader statements. Dotted arrows represent statements
inferred from the SKOS data model. Solid arrows represent asserted statements. Reproduction of Figure 4.5.2
in [[SKOS-PRIMER]]
</figcaption>
</figure>
<p>
This vocabulary defines <a href="#Property:isTransitiveProfileOf">prof:isTransitiveProfileOf</a> to allow for the
transitive interpretations of hierarchies of Profiles (of other Profiles and Standards) while freeing the
simpler property, <a href="#Property:isProfileOf">prof:isProfileOf</a> from having to enforce transitivity.
</p>
<p>
While this vocabulary provides this <code>prof:isProfileOf</code> & <code>prof:isTransitiveProfileOf</code>
pair of properties, it does not specify how a particular implementation of a Profile that is related to another
Profile or Standard by <code>prof:isTransitiveProfileOf</code> should implement specific inferences.
</p>
<p>
Inference based on <code>prof:isTransitiveProfileOf</code> will be more complex than inference based on
<code>skos:broaderTransitive</code> due to Profiles being complex objects relative to SKOS Concepts.
</p>
</div>
<figure id="fig-isTransitiveProfileOf">
<a href="figures/isTransitiveProfileOf.svg">
<img src="figures/isTransitiveProfileOf.svg" title="Property isTransitiveProfileOf in use" style="width:90%;" />
</a>
<figcaption>Property isTransitiveProfileOf in use. See the full explanation in the example text below.</figcaption>
</figure>
<pre id="eg-isTransitiveProfileOf"
class="example nohighlight turtle" aria-busy="false" aria-live="polite"
title="Property isTransitiveProfileOf in use">
# A profile that is within a hierarchy of profiles may wish to indicate it profiles
# things "further up the chain". To do this, prof:isTransitiveProfileOf can be used
# to indicate anything the profile is related to by a series of one or more
# prof:isProfileOf properties.
# Here the New Zealand profile of the ISO addressing standard is presented in a chain
# of profiles:
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<http://linked.data.gov.au/def/iso19160-1-address-nz-profile>
a prof:Profile ;
rdfs:label "New Zealand Profile of ISO19160-1" ;
rdfs:comment """This is a country-specific profile of the international
addressing standard, ISO19160-1:2015 (Address)""" ;
prof:isProfileOf <http://linked.data.gov.au/def/iso19160-1-address> .
# The ISO thing that the NZ Profile profiles is actually a Web Ontology Language
# (OWL) version of the original ISO addressing standard
<http://linked.data.gov.au/def/iso19160-1-address>
a prof:Profile ;
rdfs:label "OWL Profile of ISO19160-1" ;
rdfs:comment """This profile profiles both ISO19160-1 (Addressing) and also
the Web Ontology Language (OWL)""" ;
prof:isProfileOf <https://www.iso.org/standard/61710.html> ,
<http://www.w3.org/2002/07/owl#> .
<https://www.iso.org/standard/61710.html>
a dct:Standard ;
rdfs:label "ISO 19160-1:2015 Addressing -- Part 1: Conceptual model" .
# Now, according to the semantics of prof:isTransitiveProfileOf, using the
# prof:isProfileOf statements above, one can infer the following additional
# statements:
<http://linked.data.gov.au/def/iso19160-1-address-nz-profile>
prof:isTransitiveProfileOf <http://linked.data.gov.au/def/iso19160-1-address> ,
<https://www.iso.org/standard/61710.html> ,
<http://www.w3.org/2002/07/owl#> .
# These statements may help consumers understand which broad, well-known
# profiles data they have conforms to when they are presented only with its
# conformance to most specialised (lowest) profile in a hierarchy which they
# may not understand.
# In this example too, a user of the profile
# <http://linked.data.gov.au/def/iso19160-1-address-nz-profile> will also
# understand that data conforming to it is also conformant with OWL which is not
# in the direct hierarchy of addressing standards (iso19160-1-address-nz-profile >
# iso19160-1-address > ISO 19160-1:2015) but is critical to know about when using
# the specialised standard as it can indicate reasoning possibilities.
</pre>
<section id="Property:hasToken" class="property">
<h4>Property: hasToken</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:hasToken">prof:hasToken</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">OWL type:</td><td><a href="https://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-datatypes">owl:DatatypeProperty</a></td></tr>
<tr><td class="prop">Label:</td><td>has token</td></tr>
<tr><td class="prop">Definition:</td><td>The preferred identifier for the Profile, for use in circumstances where its URI cannot be used.</td></tr>
<tr><td class="prop">Domain:</td><td><a href="#Class:Profile">prof:Profile</a></td></tr>
<tr><td class="prop">Range:</td><td><a href="https://www.w3.org/TR/xmlschema-2/#token">xsd:token</a></td></tr>
<tr><td class="prop">Usage note:</td><td>A simple lexical form of identifier that may be accepted in some circumstances, such as API arguments or in content negotiation, to reference this profile. This is a “preferred term”, since alternative identifiers may be declared and used by any implementation</td></tr>
</tbody>
</table>
</section>
</section>
<section id="Class:ResourceDescriptor" class="property">
<h4>Class: ResourceDescriptor</h4>
<div class="issue" data-number="573"></div>
<table class="definition">
<thead>
<tr><th><a href="https://www.w3.org/TR/owl-syntax/#Classes">OWL Class</a></th><th><a href="#Class:ResourceDescriptor">prof:ResourceDescriptor</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>Resource Descriptor</td></tr>
<tr><td class="prop">Definition:</td><td>A resource that defines an aspect - a particular part or feature - of a Profile</td></tr>
<tr><td class="prop">Usage note:</td><td>Used to indicate the formalism (via dct:format) and any adherence to a dct:Standard (via dct:conformsTo) to allow for machine mediation as well as its purpose via relation to a ResourceRole (via hasRole)</td></tr>
</tbody>
</table>
<section id="Property:hasArtifact" class="property">
<h4>Property: hasArtifact</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:hasArtifact">prof:hasArtifact</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>has artifact (resource)</td></tr>
<tr><td class="prop">Definition:</td><td>The URL of a downloadable file with particulars such as its format and role indicated by a Resource Descriptor</td></tr>
<tr><td class="prop">Domain:</td><td><a href="#Class:ResourceDescriptor">prof:ResourceDescriptor</a></td></tr>
<tr><td class="prop">Usage Note:</td><td>A property to link from a Resource Descriptor to an actual resource (rdfs:Resource; an individual) that implements it</td></tr>
</tbody>
</table>
</section>
<section id="Property:conformsTo" class="property">
<h4>Property: dct:conformsTo</h4>
<p><em>This property is from the [[DCTERMS]] specification however the property chain axiom declared here is new in PROF.</em></p>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-conformsTo">dct:conformsTo</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>Conforms To</td></tr>
<tr><td class="prop">Definition:</td><td>An established standard to which the described resource conforms</td></tr>
<tr><td class="prop">Sub property of:</td><td><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-relation">dct:relation</a></td></tr>
<tr><td class="prop">Property Chain Axiom:</td><td><code>owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo )</code></td></tr>
<tr>
<td class="prop">Usage note:</td>
<td>
<p>
This property is to be used to show conformance of a resource to a specification (<code>dct:Standard</code>)
or a profile (<code>prof:Profile</code>).
</p>
<p>
The property chain axiom declared for this property means that if the thing conformed to is a profile of
something else (indicated by <code>prof:isProfileOf</code>), then the conforming resource will be
inferred to be conformant to that other thing too.
</p>
<p>
PROF does not specify the nature of conformance: communities using <a>specifications</a> and <a>profiles</a>
are free to define appropriate conformance for their purposes.
</p>
</td>
</tr>
</tbody>
</table>
<div class="issue" data-number="1078"></div>
</section>
<section id="Property:format" class="property">
<h4>Property: dct:format</h4>
<p><em>This property's details are from the [[DCTERMS]] specification.</em></p>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-format">dct:format</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>Format</td></tr>
<tr><td class="prop">Definition:</td><td>The file format, physical medium, or dimensions of the resource</td></tr>
<tr><td class="prop">Sub property of:</td><td><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#elements-format">dc:format</a></td></tr>
</tbody>
</table>
</section>
<section id="Property:hasRole" class="property">
<h4>Property: hasRole</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:hasRole">prof:hasRole</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>has role</td></tr>
<tr><td class="prop">Definition:</td><td>The function of the described artifact in the expression of the Profile, such as a specification, guidance documentation, SHACL file etc.</td></tr>
<tr><td class="prop">Domain:</td><td><a href="#Class:ResourceDescriptor">prof:ResourceDescriptor</a></td></tr>
<tr><td class="prop">Range:</td><td><a href="https://www.w3.org/TR/skos-reference/#Concept">skos:Concept</a></td></tr>
<tr><td class="prop">Usage note:</td><td>A set of common roles are defined by the Profiles Vocabulary. These are not exhaustive or disjoint, and may be extended for situations where finer-grained description of purpose is necessary. A resource may perform multiple roles</td></tr>
</tbody>
</table>
</section>
<section id="Property:isInheritedFrom" class="property">
<h4>Property: isInheritedFrom</h4>
<table class="definition">
<thead>
<tr><th>RDF Property:</th><th><a href="#Property:isInheritedFrom">prof:isInheritedFrom</a></th></tr>
</thead>
<tbody>
<tr><td class="prop">Label:</td><td>is inherited from</td></tr>
<tr><td class="prop">Definition:</td><td>This property indicates a Resource Descriptor described by this Profile’s base specification that is to be considered a Resource Descriptor for this Profile also</td></tr>