Re: Documenting ontologies at W3C

On 5/25/18 9:06 AM, Rob Atkinson wrote:
> 
> I think profileDesc comes under the charter clause : 
> 
> Other Deliverables,,
> Subject to its capacity, the working group may choose to develop
> additional relevant vocabularies in response to community demand.

Note that this is stated in the charter as a "non-normative document". I
don't know what all that changes for us. I'll try to find out what that
means in a practical sense.

> 
> (unless it ends up being recast as a specialisation of the emerging
> dcat:Resource generalised class)

In which case it would be in the dcat: namespace? And in that case it
would also be normative.

> 
> Either way it:
>   a) needs to be described as a vocabulary using W3C style
>   b) be referenced as part of the guidance of DCAT profiles - which I
> think SHOULD be described in relationship to other more general DCAT
> profiles (and other profiled standards) using profileDesc

First, the guidance is for profiles in general, not DCAT profiles. This
is why it is not limited to RDF or to anything related to DCAT.

Second, this is why I want to find out what "non-normative" means. It
may mean that it cannot be referenced in the DCAT or Guidance documents,
which *are* normative, or that it can only be included in its own
non-normative section. That would limit how it can be integrated with
the 3 deliverables on the recommendation track.

> 
> ProfileDesc is far simpler and more general than DCAT guidance - so its
> going to be easist and most useful to publish it standalone then
> leverage in the guidance doc.
> 
> I also think profileDesc can be used within the guidance doc as the
> example formalism for describing best practices around profiles formally
> identifying the nature and role of constraints definitions. 

I'm not sure what you mean here by "constraints definitions." In the
requirements for profiles we have some relating to constraints on
properties, classes, and non-RDF data elements. These are like:
cardinality, value validity rules, etc. I don't believe that profileDesc
refers to these aspects of profiles, ?

> 
> Overall the guidance doc should address all those requirements we can't
> hard-code into DCAT, but will use need to use additional ontologies to
> support.  For example, the issue of describing a constraint that a
> particular reference vocabulary is used in content can be described
> using RDF-Datcube, which can bind a data element to a set of
> skos:Concepts from a given ConceptScheme.

Again, remember that we are not limiting ourselves to profiles of RDF
metadata so we cannot give (only) RDF-related guidance.

> 
> ProfileDesc provides the vocabulary needed to discover and access
> constraint sets and interoperability of specialised profiles with their
> base profiles. At this stage no other candidate has been provided. (I
> have reviewed ADMS and it doesnt seem to cover the conformance aspect,
> and seems to be compatible with an alignment of
> prof:ImplementationResourceDescriptor in the same subclass heirarchy as
> dcat:Distribution)


We should definitely present any options other than profileDesc that we
can identify even if they are not equivalent. It would be best if our
Guidance allows for a variety of technical environments and choices. If
we describe the capabilities, readers can select what works best for them.

kc

> 
> Rob
> 
> 
> 
> On Fri, 25 May 2018 at 16:06 Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> 
>     At F2F3 I asked for documentation on the profileDesc ontology. As an
>     example of how ontologies are documented at W3C, it could be useful to
>     look at the SKOS recommendation.[1] If we are to present profileDesc
>     either as the Guidance deliverable or as a non-recommendation note
>     (which appears to require a community group in which to place it) then
>     it will need to be documented using the style seen in the SKOS
>     recommendation.
> 
>     If we decide to provide profileDesc as our response to the Guidance
>     deliverable, the non-normative Introduction area could contain the
>     outline from Lars' issue[1] modified a bit. If profileDesc is to be
>     presented as a separate work item, then it becomes a smaller section
>     within that outline. I have done a github issue[2] illustrating these
>     two options, based on Lars' initial issue. It would be good to discuss
>     pros and cons there.
> 
>     kc
>     [1] https://www.w3.org/TR/2009/REC-skos-reference-20090818/
>     -- 
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 (Signal)
>     skype: kcoylenet/+1-510-984-3600 <tel:+1%20510-984-3600>
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Friday, 25 May 2018 15:34:58 UTC