What is a profile? - Githubissues

kcoyle commented 6 years ago

Many of our issues for the profile guidance document hinge on our definition of profile. I'm going to suggest some functions that a profile must/may/should have as a start to that conversation.

MUST define vocabulary terms that are used in the metadata being profiled.
Vocabulary terms SHOULD be defined as mandatory, optional, repeatable, not repeatable (alt.: cardinality rules for vocabulary terms SHOULD be defined in the profile)
Human-readable labels and definitions MUST be included for vocabulary terms
The profile SHOULD (MUST?) define what values are valid for vocabulary terms
The profile MAY include input instructions for metadata creators (and to aid users in understanding the deeper meaning of terms)
The profile MAY include operational validation code
The profile MUST be published to the relevant metadata-using community
The profile MAY be published as a human-readable document
The profile MAY be published as operational code
The profile MAY be expressed in more than one physical file
The profile MAY be based on one or more known community standards, for interoperability within that community ("profile of X"), and, when it is, it must indicate that basis.
The profile MAY combine vocabularies that cross community boundaries without having any strongly identifiable base profile or profiles.

(No, I'm not sure about all of this - just tossing out every idea I can come up with to aid discussion.)

kcoyle commented 6 years ago

Instead of the layered view given in the DC Singapore Framework I've been thinking about a more function-based view, something like: profile

kcoyle commented 6 years ago

Here's more or less what I had in mind for using examples to talk about types of profiles:

Profiles can take a number of forms and can have a variety of relationships to existing vocabularies, standards, and other profiles. Although it is not possible to list all of the types of profiles, some common types are:

profiles that are subsets of a larger vocabulary. These reduce the vocabulary terms of a broad data standard to a smaller number of terms that are useful for a particular community member or application. An example of this is BIBFRA.me designed for library materials. It defines both a core set of terms as well as profiles for specialized communities such as cataloging of rare materials or early printing trade. In this community, all profiles use only terms from a single vocabulary.
profiles that can both reduce and extend a base standard. These profiles are developed by members of a data-sharing community but for reasons of jurisdiction or specialization need to add terms beyond the base standard vocabulary in order to meet their needs. They may also omit terms from the base standard that are not relevant to their implementations. An example of this is data catalog vocabulary standard, DCAT, its primary profile, DCAT-AP, and the national variants (DCAT-AT-IT, DCAT-AP-NO, DCAT-AT-DE). While maintaining overall compatibility with the larger data catalog community, each of these profiles adds needed terms for the local variant. These profiles generally make use of terms from more than one namespace.
profiles that amend a base standard by inheriting or overriding values of that standard. The example here is of the Open Digital Rights Language (ODRL) which is a language to support rights in the use of digital content in publishing, distribution, and consumption of digital media. The ODRL language encodes a policy that has a core vocabulary that can be extended or overridden by individual instances called "profiles."
profiles that use some vocabulary terms from multiple standards without having a strong relationship to any base standard. These profiles develop new vocabularies and may define new terms as needed. (?? not sure about this one?) An example of this is the ADMS vocabulary.

(I don't think I fully understand ODRL - need help from Antoine. It may not be different from DCAT as a type.)

aisaac commented 6 years ago

I am not 100% sure about ODRL but this seems rather right to me anyway.

The same for the rest. I cannot vouch for everything as I've got a pretty bad bird's eye view of our requirements right now and no time to check. Therefore I can't say whether our requirements overlap or exactly match with these MUST/SHOULD/MAYs, these functions and these types. But I must recognize that (1) the general approach goes in a very interesting direction and (2) that these lists look really, really credible to me :-)

nicholascar commented 6 years ago

The profile MAY be based on one or more known community standards, for interoperability within that community ("profile of X")

Can we extend that to say rather

"The profile MAY be based on one or more known community standards, for interoperability within that community ("profile of X") and, when it is, it must indicate that basis".

kcoyle commented 6 years ago

@nicholascar updated as indicated

smrgeoinfo commented 5 years ago

What is a profile for? My answer would be that the purpose is to convey to an agent (human or software) information necessary for it to determine whether the target of a hypermedia affordance (machine actionable link) is available in a representation (serialization + vocabulary + conventions) that the agent can use for some process it wants to execute. In practice, the affordance could specify a representation profile using a URI value that would dereference to a profile description; there might also be tokens like MIME types to use in content negotiation.

This profile ontology needs to define an information model for 'specifications' to allow intelligent clients to determine whether something conforming to the specification is going to be useful. What we'd like is that a URI identifying a spec can be dereferenced to obtain a description of the spec. For humans, a document describing the specification should be available. An rdf representation using the prof:Profile ontology would be for software agents. This machine actionable description asserts relationships between a described spec (the profile) and other known specifications, conformance tests, or(?) some other kind of artefact. It seems to me that there are likely to be a variety of these kind of relationships, which would be specified by the prof:ResourceRole vocabulary proposed in the draft profile doc.

kcoyle commented 5 years ago

@smrgeoinfo Thanks for that. Our charter asks us to define and create guidance for profiles in general, not specifically DCAT profiles. With that in mind, could you revise/devise an answer that is not specific to DCAT? I think the new wording would begin after "whether the target ... " It would be great if you could complete that sentence. Much appreciated!

rob-metalinkage commented 5 years ago

@smrgeoinfo - we have implemented a profiles ontology to meet precisely these concerns. It also is limited to those concerns not expressable in other canonical vocabularies.

So it does directly define all the properties a given community may need to define a specification - but under the open world assumption things like skos:Definition, prov:wasDerivedFrom, dc:author would be appropriate.

w.r.t. "conforming to the specification is going to be useful" - the profiles ontology partially addresses this by identifying the implications in terms of conformance to more general specifications. Describe "usefulness" beyond that is very challenging to do perfectly - but we have now an object type that can be further modelled by communities of practice with their own profiles. The profiles ontology supports interoperability at this declarative level between such communities primarily.

At the OGC I will indeed adapt Simon Cox's proposed modular specification OWL model - and create additional rules about such metadata - as a profile of the profiles ontology to meet the OGC's needs when publishing specifications and profiles thereof.

Its all very RDF - turtles all the way down and Open World

smrgeoinfo commented 5 years ago

@kcoyle I revised language to talk about 'hypermedia affordance', which I believe is the generalized concept we're interested in.

@rob-metalinkage sounds like we're on the same page, but isn't this dxwg project more about the information model/vocabulary for describing a specification and its relationship to other base specifications (if it's a profile)? I think 'determining if the representation is useful' will have to be based on a client's prior knowledge. If it recognizes the identifier for a profile, or get the representation for the profile and finds out it's based on a known spec, then it might be useful; if the client doesn't recognize anything about the offered representation, it moves on to the next affordance in the document being parsed. This is why clarifying the implications of 'profileOf' is critical.

kcoyle commented 5 years ago

Possible wording about conformance (if we decide to address conformance) here.