Re: Profile definition

I'd like to avoid putting a specific point of view forward as an editor of
the UCR doc - and make sure all the nuances in the discussion and UC are
fully captured.

That said - from what I have seen with OGC service interfaces is that
_service profiles_ are nearly always required to achieve interoperability -
and for data access services this includes content profiles where a service
supports a particular set of data schema.

In this respect, I think the idea of a content profile being in addition to
a schema sounds right - i.e. schema extensions are not profiles per se,
but perhaps providing specialised substitutable subclasses is a profile
concern? I'm agnostic how we interpret this (or just confused) here -
because certainly subclasses can introduce new properties - but not of the
DCAT objects themselves.

Service profiles likewise should reference content profiles, and describe
orthogonal aspects - such as perhaps which optional methods are supported,
what map projections, performance, access rights etc - all of which are
critical information discovery factors, but cannot be easily generalised
into DCAT core I suspect.  so as long as DCAT allows for services to be
referenced with object properties for the description of service profiles,
content profiles and supported schemas, and critically the ability to
annotate them as to what type of object holds these descriptions, then I
think we can add a lot of power to DCAT for its prime function, and avoid
overspecifying these aspects.

(For the record I would regard RDF-QB for describing data structure as a
useful means to define dataset content profiles - but not insist that its
the only option DCAT supports. As in ID26 - which I would like to edit make
sure includes support for services, content and service profiles   )

Regards
Rob Atkinson





On Wed, 14 Jun 2017 at 19:19 Alejandra Gonzalez-Beltran <
agbeltran.lists@gmail.com> wrote:

> Hi All,
>
> +1 to defining clearly what the group will consider as
> application/negotiation profiles and their differences, if any
>
> I added another reference to the wiki: a chapter by Karen entitled "Application
> Profiles: An Overview", which I found very useful (thanks Karen and thanks
> Andrea for adding the DOI to the wiki- you beat me to it!).
>
> In that chapter, Karen does provide the background on Dublin Core and
> Dublin Core Application Profiles - and indeed it will be great to hear more
> from her about all this.
>
> Just as a few summary points from her chapter (sorry Karen that I am
> taking the liberty of picking up these points from your chapter):
> - the problem they wanted to solve when creating DCAPs was "how to define,
> control and communicate the elements and rules of a metadata schema that
> was composed of data elements taken from existing vocabularies"
> - a key concept as "that application profiles would gather elements from
> existing namespaces, but would not define new elements" - this makes the
> distinction between profiles and extensions IMO
> - A AP is defined "solely as a usage of metadata elements", would "provide
> further definition and constraints on the elements that it includes, yet
> these extensions to the semantics of the elements must not contradict the
> semantics of the elements as they are defined in their native namespaces"
> - Thus, DCAP "is therefore a meta level above the original element
> definitions. It also could contain significant enrichment of the context of
> the metadata and the meaning of the element themselves".
>
> So, I think it is also very important that we agree on the scope of DCAT,
> as it's been discussed before, in addition to what constitutes a profile.
>
> In this respect, I would like to understand better Rob's point of view on
> defining service access as possibly another dimension of profile. I would
> think that services access should be defined within the DCAT namespace, but
> then the profile could determine its usage.
>
> Many thanks,
>
> Alejandra
>
>
> On Wed, Jun 14, 2017 at 8:58 AM, <andrea.perego@ec.europa.eu> wrote:
>
>> Hi, Rob.
>>
>>
>>
>> Makx can correct me if I'm wrong, but basically DCAT-AP re-uses the
>> Dublin Core [1] and DCAT [2] definition(s) of application profile.
>>
>>
>>
>> About what we mean with "application profile" and "negotiation profile"
>> (which may not be necessarily the same thing), I think it would be
>> beneficial for our discussion to know more about the background of the
>> Doblin Core AP document. I wonder whether Karen, who co-authored it, can
>> share some insights. Also, I think it would be good to start collecting
>> reference documentation on this topic – I took the liberty of updating the
>> AP wiki page accordingly [3].
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrea
>>
>>
>>
>> [1] http://dublincore.org/documents/profile-guidelines/
>>
>> [2] https://www.w3.org/TR/vocab-dcat/#conformance
>>
>> [3]
>> https://www.w3.org/2017/dxwg/wiki/Guidance_on_publishing_application_profiles_of_vocabularies
>>
>>
>>
>> ----
>>
>> Andrea Perego, Ph.D.
>>
>> Scientific / Technical Project Officer
>>
>> European Commission DG JRC
>>
>> Directorate B - Growth and Innovation
>>
>> Unit B6 - Digital Economy
>>
>> Via E. Fermi, 2749 - TP 262
>>
>> 21027 Ispra VA, Italy
>>
>>
>>
>> https://ec.europa.eu/jrc/
>>
>>
>>
>> ----
>>
>> The views expressed are purely those of the writer and may
>>
>> not in any circumstances be regarded as stating an official
>>
>> position of the European Commission.
>>
>>
>>
>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>> *Sent:* Tuesday, June 13, 2017 5:14 AM
>> *To:* Simon.Cox@csiro.au; rob@metalinkage.com.au; public-dxwg-wg@w3.org
>> *Subject:* Re: Profile definition
>>
>>
>>
>> Thanks Simon,
>>
>>
>>
>> I was _aware_ of it - but its not yet clear to me whether the scope of
>> application profiles discussed there fully covers the requirements under
>> discussion here.
>>
>>
>>
>> It would be great if Andrea or someone could provide a pointer to a
>> formal definition as settled on within this community (so far in
>> discussions this has not been offered as a straw man, and only the question
>> "what is a profile" has been raised.)
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>> On Tue, 13 Jun 2017 at 12:47 <Simon.Cox@csiro.au> wrote:
>>
>> Assume you are already aware of
>> https://joinup.ec.europa.eu/asset/dcat_application_profile/home
>>
>> which I think is where the whole idea of DCAT profiles was most
>> comprehensively discussed until now.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>> *Sent:* Tuesday, 13 June, 2017 12:35
>> *To:* public-dxwg-wg@w3.org
>> *Subject:* Profile definition
>>
>>
>>
>> Looking for a working definition of a profile - here's a starter from
>> Dublin Core [1]
>>
>>
>>
>> "A DCAP is a document (or set of documents) that specifies and describes
>> the metadata used in a particular application. To accomplish this, a
>> profile:
>>
>>    - describes what a community wants to accomplish with its application
>>    (Functional Requirements);
>>    - characterizes the types of things described by the metadata and
>>    their relationships (Domain Model);
>>    - enumerates the metadata terms to be used and the rules for their
>>    use (Description Set Profile and Usage Guidelines); and
>>    - defines the machine syntax that will be used to encode the data
>>    (Syntax Guidelines and Data Formats)."
>>
>>
>>
>> I think service access is possibly another dimension of profile - and in
>> fact I'd like to model profiles as n-dimensional, with the ability to label
>> (soft-type) each of the dimensions an AP chooses to qualify.
>>
>>
>>
>> So, even though we are not going to define any specific AP, I think we
>> need to decide if we will define a meta-model for an AP, in terms of
>> attachment points for each of these aspects, as well as self-reporting
>> identification of the set of APs a document conforms to.
>>
>>
>>
>> Any advances on this definition  before I have a go at defining generic
>> Use Case(s) that covers this scope?
>>
>>
>>
>> [1] http://dublincore.org/documents/profile-guidelines/#sect-2
>>
>>
>

Received on Wednesday, 14 June 2017 11:09:32 UTC