Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
The Profiles Ontology is an RDF vocabulary to describe profiles of (one or more) standards for information resources. It describes the general pattern of narrowing the scope of a specification with additional, but consistent, constraints, and is particularly relevant to data exchange situations where conformance to such profiles is expected and carries additional context. The Profiles Ontology enables profile descriptions to specify the role of resources related to data exchange such as schemas, ontologies, rules about use of controlled vocabularies, validation tools, and guidelines. The ontology may however be used to describe the role of artifacts in any situation where constraints are made on a the usage of more general specifications. The namespace for PROF terms is defined in Section 3: Namespaces, and the vocabulary terms in Section 7: Vocabulary Specification.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Dataset Exchange Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-dxwg-comments@w3.org (archives).
Please see the Working Group's implementation report.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 February 2018 W3C Process Document.
This document is part of a set of documents on profiles, edited by the W3C Dataset Exchange Working Group (DXWG). Some of the documents are general while some are technology-specific:
This section is non-normative.
This Profiles Ontology provides a structure to describe profiles of information standards. Its development was triggered by the appearance of multiple profiles of the Dataset Catalog Vocabulary (DCAT) [VOCAB-DCAT-20140116] and examples of profiles including the Dublin Core Application Profiles guidelines [DCAP] and various profiles of OpenGeospatial Consortium specifications.
The Profiles Ontology is an RDF vocabulary to describe the resources that define and implement a profile. A profile is defined as "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." These resources may be human-readable documents (PDFs, textual documents), vocabularies or ontologies (XSD, RDF), resources specific to validation tools (SHACL, ShEx, Schematron), or any other files or resources that support the profile. Each resource is defined as having a role that defines its function within the profile.
This ontology also provides for the description of relationships between such profiles and the standards to which they conform. A standard in this case can be a vocabulary or it can be another profile from which the described profile is a derivation, expansion, or selection. This ontology provides a standardized, machine readable formalism for describing the context of profiles. The basis of the ontology is a specialization ofdct:Standard
, allowing the use of the dct:conformsTo
predicate to specify conformance to a profile.
A "profile" here is represented by the Profile class definition in the Vocabulary Specification with the following definition: "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."
Profiles aim to increase interoperability within a community of users by introducing certain constraints on the use of a more general standard such as a published vocabulary. Such constraints include restrictions on the cardinality of certain properties, or a requirement to select values of a property from a specified controlled vocabulary. Profiles have generally been specified through textually-oriented documents, and/or platform specific constraint languages.
A vocabulary of Resource Role
s is provided alongside this ontology and that list is extensible.
Currently the Resource Roles vocab is referenced in the Prof Ont doc (see last para https://w3c.github.io/dxwg/profilesont/#introduction) but no actual link is given. PR 532 brings the Resource Roles vocab into W3C styling and updates it so now a link to that doc needs to be added.
The reason for this whole issue here is that how it is referenced needs discussion. If it is to be a NOTE, how will this impact future re-publication of it as a dynamic vocab, not a static document?
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
For the purpose of compliance, the normative sections of this document are Section 6 Conceptual Model, Section 7 Vocabulary Specification & Section 9 Test Suite.
The key words may, must, must not, optional, shall, shall not, should, should not, recommended, required, in this document are to be interpreted as described in [RFC2119].
The namespace for PROF is http://www.w3.org/ns/dx/prof/
.
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.
A full set of namespaces and prefixes used in this document is shown in the table below.
Prefix | Namespace |
---|---|
dcat | http://www.w3.org/ns/dcat# |
dct | http://purl.org/dc/terms/ |
owl | http://www.w3.org/2002/07/owl# |
prof | http://www.w3.org/ns/dx/prof/ |
prov | http://www.w3.org/ns/prov# |
rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs | http://www.w3.org/2000/01/rdf-schema# |
skos | http://www.w3.org/2004/02/skos/core# |
xsd | http://www.w3.org/2001/XMLSchema# |
(others) | All other namespace prefixes are used in examples only. In particular, IRIs starting with "http://example.com" represent some application-dependent IRI [RFC3987] |
This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.
This section is non-normative.
Until this ontology, there was no formal W3C method for describing the objects (Internet resources) related to profiles.
There are a multitude of ways to describe the components needed to define a profile and support validation of instances, such as:
Describing only 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:
With a mechanism to relate profiles to standards and other profiles, profile hierarchies can be established which will:
The last part of the motivation section of the prof-ont document refers to machine interpretation of profiles and how the ontology could help in conneg with fallback options (e.g. retrieving a more generic version of a requested resource, which the server could not deliver, based on a profile link). Then, a note points to the prof-conneg document. However, the prof-conneg document doesn't include these fallback options based on the ontology yet.
The model takes the dct:Standard
Class as a starting point and defines two specializations, a Base Specification
(a Standard that does not profile anything) or a Profile
(a Standard which
does). Base Specification
s or Profile
s can have Resource Descriptor
s associated with
them that define rules for implementation, provide guidance on how to implement, or some other role. Resource Descriptor
s must indicate the role they
play (to guide, to validate etc.), the formalism they adhere to (dct:format
)
and any dct:Standard
that they themselves conform to (dct:conformsTo
).
A vocabulary of Resource Role
s is provided alongside this ontology and that list is extensible.
This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.
The PROF vocabulary is available in RDF. Alongside the primary artifact, there is a set of other RDF files that provide additional information, including:
These other artifacts are linked to throughout this document.
This vocabulary makes use of [DCTERMS] properties conformsTo
& format
in its
normative specification.
OWL Class: | prof:BaseSpecification |
---|---|
Label: | Base Specification |
Definition: | A specification that defines all implementation constraints, without applying constraints on usage of another specification |
Sub class of: | prof:Profile |
Usage note: | This may not be a useful class: documents of any specification can be regarded as a trivial profile, so applications only need to be concerned with Profile conformance. If used, a Base Specification may not have the property prof:isProfileOf. |
OWL Class: | prof:Profile |
---|---|
Label: | Profile |
Definition: |
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. This definition includes what are often called "application profiles", "metadata application profiles", or "metadata profiles". |
Sub class of: | dct:Standard |
Source: | https://www.w3.org/2017/dxwg/wiki/ProfileContext |
RDF Property: | prof:hasProfile |
---|---|
OWL type: | owl:ObjectProperty |
Label: | has profile |
Definition: | A dct:Standard (or a Profile or Base Specification) has a Profile |
Domain: | dct:Standard |
Range: | prof:Profile |
Inverse of: | prof:isProfileOf |
RDF Property: | prof:hasResource |
---|---|
OWL type: | owl:ObjectProperty |
Label: | has resource |
Definition: | A Profile has a Resource Descriptor |
Range: | prof:ResourceDescriptor |
RDF Property: | prof:isProfileOf |
---|---|
OWL type: | owl:ObjectProperty |
Label: | is profile of |
Definition: | A Profile is a profile of a dct:Standard (or a Base Specification or another Profile) |
Domain: | prof:Profile |
Range: | dct:Standard |
Inverse of: | prof:hasProfile |
Usage note: | The semantics of the rdfs:Range means that any resource treated as a base specification can be regarded as a Profile (i.e. may be any specification with an empty set of additional constraints) |
RDF Property: | prof:isTransitiveProfileOf |
---|---|
OWL type: | owl:ObjectProperty |
Label: | is a transitive profile of |
Definition: | A dct:Standard (or a Base Specification or another Profile) that a Profile conforms to transitively (through an intermediary) |
Domain: | prof:Profile |
Range: | dct:Standard |
Usage note: | A means to list all the Profiles/Standards within a transitive profile hierarchy |
To further spell out that PROF provides for a profile transitivity patterns and what the pattern is, we could quote the transitivity illustration from SKOS https://www.w3.org/TR/skos-primer/#sectransitivebroader in the PROF ont doc.
We then need to indicate that while PROF provides the pattern, it doesn't provide the mechanics and explanation of specific situation results (inference results).
The property prof:isTransitiveProfileOf defined here performs a role similar to that of the property skos:broaderTransitive defined in [SKOS-REFERENCE]. That property "...allows communities of practice to exploit transitive interpretations of hierarchical networks..." while freeing the simpler hierarchy property of skos:broader from having to enforce transitivity which would prevent broader but non-transitive relationships.
Figure 4.5.2 from [SKOS-PRIMER], reproduced below, illustrates the general principle of use of
skos:broaderTransitive
.
This ontology defines prof:isTransitiveProfileOf to allow for the transitive interpretations of hierarchies of Profiles (of other Profiles and Standards) while freeing the simpler property, prof:isProfileOf from having to enforce transitivity.
While this ontology provides this prof:isProfileOf
& prof:isTransitiveProfileOf
pair of properties, it does not specify how a particular implementation of a Profile that is related to another
Profile or Standard by prof:isTransitiveProfileOf
should implement specific inferences.
Inference based on prof:isTransitiveProfileOf
will be more complex than inference based on
skos:broaderTransitive
due to Profiles being complex objects relative to SKOS Concepts.
RDF Property: | prof:hasToken |
---|---|
OWL type: | owl:DatatypeProperty |
Label: | has token |
Definition: | A property for identifying this Profile for use in APIs |
Domain: | prof:Profile |
Range: | xsd:token |
Usage note: | This property is to be used to indicate a token that identifies this Profile which should be used when the Profile's URI cannot be used. For potential use in content negotiation |
The Resource Descriptor class' name may not convey its intention well. This name needs to be reconsidered with discussion about it here.
OWL Class: | prof:ResourceDescriptor |
---|---|
Label: | Resource Descriptor |
Definition: | A resource that defines an aspect - a particular part or feature - of a Profile |
Usage note: | 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) |
RDF Property: | prof:hasArtifact |
---|---|
Label: | has artifact (resource) |
Definition: | An rdfs:Resource that implements the Resource Descriptor |
Domain: | prof:ResourceDescriptor |
Usage Note: | A property to link from a Resource Descriptor to an actual resource (rdfs:Resource; an individual) that implements it |
This property's details are from the [DCTERMS] specification.
RDF Property: | dct:conformsTo |
---|---|
Label: | Conforms To |
Definition: | An established standard to which the described resource conforms |
Sub property of: | dc:relation, dct:relation |
This property's details are from the [DCTERMS] specification.
RDF Property: | dct:format |
---|---|
Label: | Format |
Definition: | The file format, physical medium, or dimensions of the resource |
Sub property of: | dc:format |
RDF Property: | prof:hasRole |
---|---|
Label: | has role |
Definition: | Functional role of a Resource |
Domain: | prof:ResourceDescriptor |
Range: | skos:Concept |
Usage note: | Some roles are published alongside this ontology in a separate vocabulary |
RDF Property: | prof:isInheritedFrom |
---|---|
Label: | is inherited from |
Definition: | A Profile's Resource Descriptor has been inherited from a Base Specification |
Domain: | prof:ResourceDescriptor |
Range: | prof:Profile |
Usage note: | Profiles within inheritance hierarchies may use this property. If absent, then the Resource Descriptor applies specifically to this Profiles only |
OWL Class: | prof:ResourceRole |
---|---|
Label: | Resource Role |
Definition: | The role that an Resource plays |
Sub class of: | skos:Concept |
Usage note: | Specific terms must come from a vocabulary |
Alongside the Profiles Ontology a vocabulary of ResourceRole instances has been made (see the RDF file however the way this is referenced from the Profiles Ont doc has not yet been determined.
This section is non-normative.
This section contains a few modelled examples of existing profiles to demonstrate aspects of this ontology. While efforts have been made to ensure they are accurate at the time of this document's publication, they are not to be considered authoritative; their purpose is only to illustrate this ontology's use.
This example showcases this ontology's description of parts of a profile.
DCAT-AP is the widely used European Application Profile of DCAT. DCAT-AP is described in document form (PDF & DOCX) and a constraints document for instance validation is available, formulated using the W3C's Shapes Constraints Language constraints language [SHACL].
The figure below described DCA-AP graphically, using elements from this ontology.
In words this ontology's descriptions of DCAT-AP is:
In RDF (turtle format), DCAT-AP is describe using the Profiles Ontology, with many properties not listed in the summary descriptions above as:
<https://joinup.ec.europa.eu/release/dcat-ap-v11> a prof:Profile ; prof:hasToken "dcat-ap" ; rdfs:label "DCAT-AP" ; rdfs:comment "DCAT Application Profile for data portals in Europe" ; dc:publisher "European Union" ; prof:isProfileOf <http://www.w3.org/ns/dcat> ; # this profile has, itself profiles. Here GeoDCAT-AP is given prof:hasProfile <https://joinup.ec.europa.eu/release/geodcat-ap-v10> ; # SHACL constraints for the profile, guidance doc in Word & PDF & an image of the profile components prof:hasResource # Guidance doc in Word (DOCX) <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f6f27f059_bf785_b4d7d_bb602_b6448aab73bd5> , # Guidance doc in PDF <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f17e18570_b1d77_b4171_b9df5_bb53cb4f017d4> , # profile image (PNG) <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f1131a208_b92e9_b4427_ba40c_b6c47746cd422> , # Constraints in SHACL <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096> ; . <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f6f27f059_bf785_b4d7d_bb602_b6448aab73bd5> a prof:ResourceDescriptor; rdfs:label "DCAT-AP Guidance Document (Word)" ; dct:format <https://w3id.org/mediatype/application/msword> ; prof:hasRole roles:Guidance ; . <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f17e18570_b1d77_b4171_b9df5_bb53cb4f017d4> a prof:ResourceDescriptor; rdfs:label "DCAT-AP Guidance Document (PDF)" ; dct:format <https://w3id.org/mediatype/application/pdf> ; prof:hasRole roles:Guidance ; . <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f1131a208_b92e9_b4427_ba40c_b6c47746cd422> a prof:ResourceDescriptor; rdfs:label "DCAT-AP Image" ; dct:format <https://w3id.org/mediatype/image/png> ; prof:hasRole roles:Guidance ; . <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096> a prof:ResourceDescriptor; rdfs:label "DCAT-AP Constraints" ; dct:conformsTo <http://www.w3.org/ns/shacl>; # the namespace for SHACL dct:format "text/turtle" ; prof:hasRole roles:ConformanceTest ; .
This example showcases this ontology being used to indicated profiles within a complex hierarchy.
DCAT-AP, a profile of DCAT, has itself been profiled for various European countries, such as Belgium who has issued DCAT-BE. Additionally, there are several domain profiles of DCAT-AP, such as GeoDCAT-AP - for describing geospatial datasets, dataset series and services - and StatDCAT-AP for enhancing interoperability between descriptions of statistical datasets. further to this, there is even an Italian profile of GeoDCAT, DCAT-AP-IT.
This profile hierarchy is represented graphically in the figure above and in RDF (turtle) below.
<http://www.w3.org/ns/dcat> a prof:BaseSpecification ; <https://joinup.ec.europa.eu/release/dcat-ap-v11> a prof:Profile ; rdfs:label "DCAT-AP" ; prof:isProfileOf <http://www.w3.org/ns/dcat> ; <http://dcat.be> a prof:Profile ; rdfs:label "DCAT-BE" ; prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ; <https://joinup.ec.europa.eu/release/geodcat-ap-v10> a prof:Profile ; rdfs:label "GeoDCAT-AP" ; prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ; <https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europ> a prof:Profile ; rdfs:label "StatDCAT-AP" ; prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ; <https://joinup.ec.europa.eu/news/geodcat-apit1> a prof:Profile ; rdfs:label "GeoDCAT-AP-IT" ; prof:isProfileOf <https://joinup.ec.europa.eu/release/geodcat-ap-v10> ;
Since there are no restrictions on either the property prof:isProfileOf
or the class definition of
prof:Profile
that prevent them from being used to represent polyhierarchies, Belgium could release a
profile of [StatDCAT-AP] (e.g., StatDCAT-BE), that would be both a profile of DCAT-BE and [StatDCAT-AP]. This
imagined profile, '?' in the figure above, would not be a profile of GeoDCAT-AP.
A software suite is made available to test implementations of this ontology for compliance. This suite comprises of [SHACL] RDF graph validation templates and instructions for the application of those templates to implementations.
This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.
This section is non-normative.
Implementation conformance reports for this ontology are given in:
The SHACL Recommendation contains a link to an SHACL Test Suite and Implementation Report that we should emulate to implementations.
This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.
This section is non-normative.
This section will list alignments from PROF to other W3C ontologies.
This ontology aligns with the Dataset Catalogue vocabulary as per the class and property diagrams below.
The RDF file giving the formal alignment is avauilable here: profilesont_dcat_alignment.ttl.
The following table summarieses the mappings shown graphically in Fig. 2 & 3.
PROF element | Mapping property | DCAT element | Notes |
---|---|---|---|
prof:hasResource | rdfs:subPropertyOf | dcat:distribution | |
dct:conformsTo | - | - | Used similarly |
dct:format | - | - | Used similarly |
prof:hasRole | rdfs:subClassOf | dcat:Distribution | |
prof:Profile | rdfs:subClassOf | dcat:Resource | Generic association |
Draft added to the relevant wiki page ("Alignments and crosswalks").
@makxdekkers , could you please check it out, and see if anything needs to be changed? Thanks!
Prepare a formal alignment of PROF (Prof Desc Ont) to VOAF
This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.
This section is non-normative.
This section lists, and then addresses, individual requirements that the Dataset Exchange Working Group considered important for content negotiation by profile.
Responses to individual requirement Issues listed here are, at the time of the First Public Working Draft of this document, for demonstration only; to indicate the logic of answers to individual requirements.
These requirement responses may not survive in their current form in later drafts of this document nor may individual listings of requirements; they may be subsumed into the flowing txt of the document.
Define schema.org equivalents for DCAT properties to support entailment of schema.org compliant profiles of DCAT records.
RESPONSE FOR 65
Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the profiles of DCAT they conform to.
These Use case specific requirements apply to the required scope of this definition. Where appropriate these are also captured as additional requirements.
RESPONSE FOR 72
RESPONSE FOR 204
RESPONSE FOR 205
This is handled by having URIs for profiles resolve to HTML landing pages and RDF descriptions of the profile created according to this ontology which then lenk to Resource Descriptors and other Profiles.
RESPONSE FOR 207
This is addressed by a Profile using this ontology to link to other Profiles from which it derives.
RESPONSE FOR 208
This is addressed by Profiles using Resource Descriptors from this ontology which then implement constraint languages with various Roles such as "Full Constraints".
RESPONSE FOR 209
RESPONSE FOR 210
This is addressed by a Profile implementing a constraint language via a Resource Descriptor and selecting an appropriate Resource Role for it.
RESPONSE FOR 211
RESPONSE FOR 212
RESPONSE FOR 213
RESPONSE FOR 214
Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to (6.1)
RESPONSE FOR 215
Profiles described using this ontology may indicate that they are a profileOf another Profile.
Profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (UC 5.37)
RESPONSE FOR 216
RESPONSE FOR 217
RESPONSE FOR 222
This requirement is based on a use case that reflects practice primarily in libraries, but in some cases also in archives and museums.
For the last 50 years, libraries have used a specific data standard called "MARC".[1] That data standard includes a single data element to indicate the cataloging rules that were used to create the metadata. The element is called "descriptive cataloging form."[2]
18 - Descriptive cataloging form
x - Non-ISBD
a - AACR 2
c - ISBD punctuation omitted
A new data standard called BIBFRAME[3] includes this same information as one element of administrative data[4] for the bibliographic description (aka: record). The property is called "descriptive conventions":
Property: | descriptionConventions
Label: | Description conventions
Definition: | Rules used for the descriptive content of the resource description.
Used with: | AdminMetadata
Expected Value: | DescriptionConventions
In both cases, there is one value for each "record".
Note that the "conventions" or "rules" are in part (as Phil said) style guides, but also contain detailed instructions for making decisions. Many such decisions are not validatable, but must be left to the human cataloger to make a decision within her context, and there often is "no right answer". The current rules used by many Western libraries are over 1000 pages in length.[6] Unfortunately there isn't an open access version but I could supply examples (warning: they'd be lengthy) if anyone wishes.
[1] http://www.loc.gov/marc/bibliographic/
[2] http://www.loc.gov/marc/bibliographic/bdleader.html
[3] http://www.loc.gov/bibframe/docs/index.html
[4] http://id.loc.gov/ontologies/bibframe.html#c_AdminMetadata
[5] http://id.loc.gov/ontologies/bibframe.html#p_descriptionConventions
[6] https://www.amazon.com/RDA-Resource-Description-Print-2015-Revision/dp/0838913466/ref=sr_1_1?ie=UTF8&qid=1528843589&sr=8-1&keywords=resource+description+and+access
RESPONSE FOR 255
Entered from Google Doc
RESPONSE FOR 264
Entered from Google Doc
RESPONSE FOR 268
Entered from Google Doc.
From the documents accessible from references in this use case, it should be possible to infer more specific requirements in terms of profile documentation, but I lack time. It could be captured by other cases. It should maybe be addressed at a later stage of DXWG work.
RESPONSE FOR 272
Entered from Google Doc
RESPONSE FOR 279
Using this ontology, a Profile may indicate a Resource Descriptor instance by way of the resource property. That Resource Descriptor may be a schema that conformsTo a constraints language, such as SHACL etc.
Entered from Google Doc
RESPONSE FOR 280
Entered from Google Doc
Suggested re-wording: a profile must have an identifier
RESPONSE FOR 284
Using this ontology, all Profile instances are RDF Resources with their own URIs. Additionally, the token property is given for use with a Profile to be used to identify it where use of a full URI is not possible, such as within HTTP Query String Arguments.
Entered from Google Doc
What kinds of information? Can we clarify this?
RESPONSE FOR 286
Following relationships from a profile defined using this ontology, a person or machine may discover either Resource Descriptor resources describing any sort of document relevant to the profile or other Profiles.
Entered from Google Doc
Antoine suggests: “some data may conform to several profiles at once” and that we should remove modular.
RESPONSE FOR 287
Entered from Google Doc
RESPONSE FOR 288
Graph navigation of profiles' information described using this ontology is supported by its RDF mechanics.
An instance of a resource claiming adherence to an instance of a Profile might indicate its adherence by using the dct:conformsTo property.
Currently we haven't actually articulated how a resource claiming to conform to a profile indicates that cliamed conformance. Is it by simple use of dct:conformsTo
? If so, what's the pattern of going from a resource to the Profile it conforms to then to a Resource Descriptor with some sort of Constraints Resource Role so it can be tested?
This section will be removed in a later version of this document.
Additional Issues related to this document and not yet placed within it are listed at the: