Re: [dxwg] profileDesc and the Guidance document

For the record I'm happy to take this wherever it seems to make most sense,
which means a balance of least effort and most use to a wider community.

@agreiner - if you unpack this using the "Open World Assumption" then
indeed anything identified by a URI can be (retrospectively, or by a third
party) described as a Profile.

There are a range of different machine readable profile expressions, OGC
has some expressed in SchemaTron, others are in SHACL etc. They all suffer
expressivity issues against the set of requirements (regardless of what
subset we choose I suspect). Helping "the programmer", or systems they
program,  find these and choose them is a useful first step (i.e.
profileDesc). Of course this doesnt preclude members of the group from
going deeper into designing profile description languages and bring a
proposal to the table - but its hard to see this fitting into either the
charter or available time.

Optionally, some form of profile negotiation can be used to deference a
Profile identifier to a specific distribution (i.e. representation) so it
doesnt mean clients must traverse the information model explicitly, but
they also need to access descriptions of what is available in general, so
you get back to the need for a metadata carrier. Descriptions are going to
be the most critical general case for existing web resources that identify
Profiles, but do not support such negotiation.

The one thing that that must reflect reality is that Profiles normatively
expressed as a single schema co-exist with profiles (like DCAT-AP) with
multiple related resources, so the whole Dataset/Distribution pattern is
relevant. This certainly doesnt stop a machine-readable Profile - it just
needs a metadata entity to hold statements about it to be maximally useful
- and we end up back at the need to have a profile descriptor - which looks
a lot like an analogue of a dcat:Dataset.  This is why I promoted the
DCAT-AP experience where they extended their interpretation of DCAT to
implement this same information model.

Guidance should help people do something similar, but actually consistent
with the declared vocabulary semantics.

we are  preparing an "alignment vocabulary" for profileDesc as a subclass
of dcat:Resource, as per
https://rawgit.com/w3c/dxwg/dcat-service-simon/dcat/#vocabulary-overview

(I've also included specific support for "packaged" profiles containing
references to all inherited constraint sets)




On Thu, 31 May 2018 at 03:10 Annette Greiner via GitHub <sysbot+gh@w3.org>
wrote:

> So here is where I'm confused: if we write a spec that says all you need
> to have a profile is a URI, then absolutely everything on the web is
> potentially a profile. If we think a machine-readable form of a profile is
> a necessity, and the only guarantee we make for a programmer is that the
> thing has a URI, we haven't really offered the programmer anything useful
> to code against. I'm still not sure that a machine-readable profile needs
> to be anything other than a schema, though. That's what I'm hoping some
> real use cases can clarify. What do we want profiles to do that a schema
> doesn't already do?
>
> --
> GitHub Notification of comment by agreiner
> Please view or discuss this issue at
> https://github.com/w3c/dxwg/issues/242#issuecomment-393241804 using your
> GitHub account
>
>