RE: Organizing Use Cases for F2F

Hi Rob,

 

Thanks for your thoughts. I had some difficulties to parse your message because there seem to be some implicit assumptions that I’d like to understand:

 

You said we would need: 

 

> -   simple summary dataproperty set that is consistent with the schema.org <http://schema.org>  world - (which may be able to take DCAT on board - but certainly simple mappings)

 

Are you saying the approach in this group should be based on the schema.org approach? I am fine with that if others agree, but on the other hand we may want to look at semantic requirements first and then let schema.org think about how they could map to it on build on it. Are you thinking of something like the way DCAT handles keywords (a simple summary data property) versus themes (an object property)?

 

> - an identifiable extension point (an objectproperty  to attach details)

> - a way of declaring the type the extension details 

 

In the current DCAT, is the use of dct:spatial, linking to an instance of dct:Location as its type, an example of such an ‘identifiable extension point’? Or do you refer to something different or more complex?

 

> - a way of defining profiles of DCAT which constrain the types of details available.

 

Yes, this is an issue that I have seen come up several times. For example, in DCAT you can link to contact information with dcat:contactPoint which links to an instance of vcard:Kind, but in practice, people need to know the set of vcard properties they are supposed to provide or can expect to find. 

 

> so I'm guesing the objectproperty is going to be a link object, with the resource, link type, label and probably a profile identifier that defines the profile of the descriptive metadata resource ( profiles will be nested, rather than massively complex monolithic descriptions - and the profile nesting graph itself will be useful semantics about the compatibility of the dataset.)

 

I did not understand this sentence: how can an (object) property *be* a (link) object? Are properties and objects not two different things? And what is a ‘link object’?

Nesting profiles rather than monolithic profiles sounds like a good idea, but we would need to see how one or the other helps or hinders interoperability. A monolithic profile gives more certainty about what you’re supposed to send and can expect to receive, while nested profiles give more flexibility. Both approaches may have advantages and disadvantages.

 

I agree that once we have identified the kinds of ‘extensions’ we want to cover, subgroups can start fleshing out the details for particular types.

 

 

Thanks, 

 

Makx.

 

 

From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
Sent: 06 July 2017 22:10
To: kcoyle@kcoyle.net; public-dxwg-wg@w3.org
Subject: Re: Organizing Use Cases for F2F

 

 

Hi

 

What i see as the meta-issue here is that a lot of Use Cases relate to having richer metadata about data sets, which allow the data to be potentially understood, (discovered, evaluated and exploited)  in different contexts - spatio-temporal, provenance, access services, etc.

 

In all these cases we usually need:

-   simple summary dataproperty set that is consistent with the schema.org <http://schema.org>  world - (which may be able to take DCAT on board - but certainly simple mappings)

- an identifiable extension point (an objectproperty  to attach details)

- a way of declaring the type the extension details 

- a way of defining profiles of DCAT which constrain the types of details available.

 

so I'm guesing the objectproperty is going to be a link object, with the resource, link type, label and probably a profile identifier that defines the profile of the descriptive metadata resource ( profiles will be nested, rather than massively complex monolithic descriptions - and the profile nesting graph itself will be useful semantics about the compatibility of the dataset.)

 

if we agree on a mechanism, then it will be simple to delegate each issue to subgroups, by just asking for them to nominate at least one canonical descriptive model and the entailment rules to derive the simple datatype properties. The actual model doesnt need to go into DCAT core, keeping it clean.

 

If we cant find a suitable model, then that feature is either out of scope, or we define just simple dataproperties. Again I'd focus on schema.org <http://schema.org>  equivalences, and where DCAT adds specific extra value.

 

In the F2F you could have a first session to triage the UC against this and other patterns, and as you go perhaps prioritise the extension pattern cases.

 

I'd leave the profile negotiation discussion until after you have developed a common view of profiles and how they will be needed to cope with this rich set of extension options. (I'm sure profiles will need abstraction/specialisation hierarchies, and multiple profiles will apply to the same DCAT resource - so if you hit this issue prematurely you'll probably solve half the problem)

 

Rob Atkinson

OGC

 

 

On Fri, 7 Jul 2017 at 05:13 Karen Coyle <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > wrote:

In preparing for the face-to-face, Caroline and I would like to ask the
group, especially the UCR editors, to suggest what they see as the
logical groupings for our discussion sessions. It would be ideal for us
to have this by the end of the working day (European time) on Tuesday.

We have eight 90-minute slots that we can make use of. If we assume that
at least part of the first slot will be introductions and establishing
an overall working hypothesis, then we have 7 slots in which to discuss
actual use cases. We may also wish to reserve 30 minutes at the end of
the second day to prepare a list of missing use cases and immediate
tasks relating to this deliverable.

Remember that the primary goal of the F2F meeting is to provide the UCR
editors with the information and decisions that they need to create a
First Public Working Draft of the Use Cases and Requirements. A FPWD is
a "heart-beat" document that is not expected to be final but that gives
the W3C management and community an indication of the direction of the
group, as well as proof that it is indeed getting its work done. We will
expect the UCR to be issued in additional versions as the work
progresses. Our goal for the FPWD is to meet the August 9 W3C deadline
for publishing documents, which means that the group needs to approve
the document before that.

Also, it would be good to have by the end of the Oxford meeting an idea
of how the DCAT group will proceed once the UCR FPWD is in place. We
should also determine if the work so far informs the Profile and Content
Negotiation groups, or if we have more to do in gathering use cases in
those areas.
--
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>