– DRAFT –
DXWG F2F3 - Day 2

<riccardoAlbertoni> https://‌docs.google.com/‌document/‌d/‌15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/‌edit#heading=h.70ebjavd7jrw

PWinstanley: yesterday clarified issues re Profiles. Today - construct skeleton of Profile guidance document

<kcoyle> https://‌www.w3.org/‌2018/‌05/‌08-dxwg-minutes

PWinstanley: focused on validation and relationships between profiles
… all ok? Any overnight epiphanies?

kcoyle: relations are awkward

PWinstanley: does section need breaking up?

kcoyle: need to go back to UCs ...

Action: kcoyle to review profiling use-cases

<trackbot> Created ACTION-112 - Review profiling use-cases [on Karen Coyle - due 2018-05-16].

Jaroslav_Pullmann: need to review scenarios for profiles, to correlate with UCs. Also check GitHub issues. Perhaps generate UCs from issues?

kcoyle: wants to go the other way - re-extract reqs from UCs - some Reqs do not appear to be well grounded in UCs
… conceptually the Reqs do not reflect the UCs :-(

Action: Jaroslav_Pullmann to work with kcoyle on profile UCs and Requirements

<trackbot> Created ACTION-113 - Work with kcoyle on profile ucs and requirements [on Jaroslav Pullmann - due 2018-05-16].

PWinstanley: We didn't pay much attention to content negotiation by profile

<roba> DCAT-AP scenario drives most of the requirements - and there are not that many additional ones. So if folks are uncomfortable with complexity, then re-read the real world examples provided by Makx - if something missing provide example as evidence.

<antoine> kcoyle, Jaroslav_Pullmann : I have one case about links between profile I could work with you if you want

PWinstanley: need to make sure nothing left on the editing floor

<roba> * just mute conference room when someone else taling please

PWinstanley: kcoyle will give presentation on Dublin Core approach, to see if anything we can adopt from there
… then going forward we can ensure our approach is harmonised with that

roba: looking at comments from yesterday - too much focus on expressivity of constraint language :-(

we shouldn't be inventing a constraint language. We need to adopt technologies that are available.

<antoine> For the record the questions I asked was whether we should include elements about the content of profile specifciation (cardinality constraints etc) like Dublin Core work in the "profile content" sections.

SimonCox: harmonization is good, but not if the DC approach is not fit for our purpose

PWinstanley: agree - just avoid unnecessary divergence

<kcoyle> http://‌dublincore.org/‌documents/‌singapore-framework/

<kcoyle> http://‌dublincore.org/‌documents/‌dc-dsp/

<kcoyle> http://‌dublincore.org/‌documents/‌profile-guidelines/

kcoyle: describing DC profile approach
… SHACL/ShEX are too atomistic
… 2007 Singapore Framework documents too dense

<kcoyle> https://‌github.com/‌kcoyle/‌RDF-AP

kcoyle: 2009 draft http://‌dublincore.org/‌documents/‌profile-guidelines/ is clearer about how to develop profiles
… new draft 2018 https://‌github.com/‌kcoyle/‌RDF-AP also based on CSV-W
… everyone develops application profiles as tables
… goal is simple enough documents so that all interested parties can use them
… see schemaList.csv - could also link out to Shacl/ShEx for validation
… but spreadsheet should express AP, then can build data template as a tables
… Gregg Kellogg works on software for converting spreadsheets to web-friendly data

automatically convert constraints-in-a-table into data-template-as-a-table

?

kcoyle: yes - though not working yet

PWinstanley: discussion?

<roba> seems to show that a diversity of implementing resources is a reality - challenge is classifying the role each resource may have..

<PWinstanley> http://‌xlsform.org/ is a route to building forms that uses a spreadsheet approach

SimonCox: tabular representation of constraints is another useful prof:resource associated with a Profile
… with different role - e.g. 'data-template-rule'

Data entry is important goal. Can also use SHACL to drive forms (NickCar student; built in to TopBraid)

discussion on how to move forward

PWinstanley: need someone to take control ...

kcoyle: wants in-out list - see gdoc

riccardoAlbertoni: do not enforce/adopt one technology

kcoyle: shoudl we mention technologies?

roba: document must explain what profiles are, and how data conforms

kcoyle: what should we say about constraints in the guidance document?

roba: how many documents: 1. guidance document ... but must refer to 2. profile description formalization
… 'guidance for DCAT profiles' does not need to describe profiles technology or constraints languages, they belong in a different document

kcoyle: how many documents ? not yet clear.

roba: two options - one complex document or two simple documents
… willing to write up profiledesc as separate standalone document, which then will make DCAT guidance easier, because it will provide means for describing more complex requirements
… Nick and roba have implementation plans ready (OGC, Oz) independent of DCAT

kcoyle: guidance dcument should not define a vocabulary, its a document

roba: profiledesc will make writing profile-guidance easier

kcoyle: profiledesc could be the main deliverable?

SimonCox: note that profiledesc document is generated by LODE from profiledesc RDF - it doesn't have a lot of text

<roba> +1

<roba> (to peter's summary)

PWinstanley: will need to add lots of text

<roba> note that the vocabulary is completely open to change to meet needs

antoine: the proposal to work on profiledesc makes a lot of sense
… but must not forget content-negotiation requirement
… conneg is a separate deliverable

<roba> yet to identify a requirement to access profile description during negotiation - but possibly inheritance may raise an need

kcoyle: must be corodinated with profile guidance/profiledesc

antoine: deliverables must cross-reference each other

PWinstanley: deliverables are independent must must be coordinated, there must be no inconsistency

<roba> Happy for this to be the formalism part of a single deliverable, which describes how to use it and show examples of what specific constraint languages are used

AndreaPerego: need to be careful about rolling in too many things. there are other profiling formalisms. Users may be confused. How does this complement SHACL, ShEx etc?

<antoine> Most profile languages like SHACL ShEx, DC's DSP seek to describe the content of profile (ie constraints). Our Vocabulary describe profiles. It gives the hook to bind everything together.

<LarsG> +1 to what antoine just said

+1 antoine

<kcoyle> +1 to antoine

roba: there is no profile description language around (there are several constraint languages, mostly tech specific)

<antoine> And the role of content negotiation should be to point users to constraints languages (SHACL, XML Schema), humaan-readable doc (HTML) or the 'hook' as represented in ProfileDesc (RDF)

<Zakim> LarsG, you wanted to say that the profile description should have the same content as profiledesc but doesn't have to implement it

the hook also indicates role of different artefacts, which wasn't there before

<antoine> SimonCox +1 and LarsG +1

<riccardoAlbertoni> +1 LarsG

<roba> yes - thats correct

LarsG: profiledesc complements constraints expressions and guidance documents

<roba> so @tombaker - can DC work be refactored to use a simple vocab with this scope?

<antoine> My proposal would be to have the profile guidance as a Primer for ProfileDesc

<antoine> and for Conneg

kcoyle: proposes that we use profiledesc as basis for guidance document

<roba> +1 antoine

kcoyle: need to plan AP Guidance doc using profiledesc as core resource

<antoine> I think it's compatible with what kcoyle proposes

<LarsG> antoine is that for profile-negotiation or for how to distribute information about a specific profile?

PWinstanley: need to roadtest profiledesc

<antoine> Suggested title: "Describing and publishing data profiles - a Primer" :-)

<roba> it still needs work of course - role description and can we handle all the versioning complexity Makx highlighted?

<antoine> LarsG: both

<Zakim> tombaker, you wanted to say that http://‌dublincore.org/‌documents/‌singapore-framework/ also had the goal of specifying the documentary components of a profile and how they relate

Description of profiledesc is here https://‌w3c.github.io/‌dxwg/‌profiledesc/‌profiledesc.html

examples here: https://‌github.com/‌w3c/‌dxwg/‌tree/‌gh-pages/‌profiledesc/‌examples

<roba> Can we get some love to test profiledesc against singaporeframework requirements

tombaker: Singapore Framework (3 page doc) is important well-used resource, perhaps needs updating, coordinating

<Zakim> AndreaPerego, you wanted to say it would be good to integrate also the draft made by antoine - https://‌docs.google.com/‌drawings/‌d/‌1dHkpwKwUwMgS1RqSCTPO3uOoRiY_qNk0z5bhXJlYi4Y/‌edit

SimonCox: urges people to review profiledesc resources mentioned above

<roba> * was trying to work out f just me...

roba: profiledesc meets operational needs know to the authors - several tests have been done
… shoudl be crossed-checked against SF (Singapore Framework)
… profiledesc is currently v small and could be evolved and aligned quite easily

<Zakim> LarsG, you wanted to propose that we combine the documentation part of the Singapore Framework with the structure of profileDesc

<kcoyle> Do we need more use cases to cover profiledesc?

LarsG: +1 to roba

<Zakim> antoine, you wanted to suggest we really need to set up a profile group to coordinate between the 3 deliverables

antoine: we agree on strategy, need to organize the work.

<kcoyle> PROPOSED: Explore placing ProfileDesc as basis for Guidance deliverable

<LarsG> +1

<kcoyle> +1

<PWinstanley> +1

+1

<Makx> +1

<roba> +1

<riccardoAlbertoni> +1

<DaveBrowning> +1

<Jaroslav_Pullmann> +1

<antoine> +1 (with hesitation: I think it would be not *the* basis)

<tombaker> +1

Resolved: we will explore placing ProfileDesc as a basis for Guidance deliverable

Resolved: Explore placing ProfileDesc as basis for Guidance deliverable

<antoine> 4 months should be ok

PWinstanley: logistics - timing?

<antoine> looking at the maturity for the rest

PWinstanley: well before TPAC, Lyon October 25/6
… so needs to be well underway by August

<antoine> yes it's possible

PWinstanley: so as not to clash with lazy northern summer
… (excepting kcoyle of course)
… FPWD needs to show sense of direction. RobA, kcoyle Nick all champing at the bit
… probably antoine too
… (we are talking about potential editors here)

antoine: will ensure that conneg will be included

LarsG: what about previously nominated editors?

PWinstanley: roba has been v active, but not on profile/index.html

<antoine> I can help co-editing stuff especially taking care of interrelationships and the wording that goes with it.

<roba> once scope is clear and contributions start then editing can start :-) Ready to go..

Editors: kcoyle roba antoine (for now)

<antoine> I'm expecting that in the end we could have more editors, as I expect we'll pick contributions from Lars, Ruben, Nick about their 'products'

+1 antoine

<antoine> and probably SimonCox too ;-)

DaveBrowning: is this still a 'guidance' document

kcoyle: description is vague, can be bent to fit
… phila encouraged us to take it in the direction required

PWinstanley: establish a position!

DaveBrowning: balance guidance vs. authoritative slant
… we (Reuters) struggle with the balance

PWinstanley: DaveBrowning should be strong reviewer

LarsG: does profiledesc replace ruben/lars/roba document?

PWinstanley: need to verify that profiledesc-based work is sound

<roba> aiming for rec track - i need to implement at OGC Linked Data resources in next few months :-)

<antoine> +1 to what PWinstanley said. Let's start with doing something then we see the formal status

PWinstanley: need to bring forward milestones to verify quality

<antoine> which probably means that we're aiming at Note first...

<roba> let it emerge - buts its a very tiny little vocab ..

<roba> * how long?

<roba> * ok

<kcoyle> we'll try to get back top of the hour

[coffee break]

Project plan for the profile guidance doc

<kcoyle> https://‌docs.google.com/‌document/‌d/‌15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/‌edit#

PWinstanley: We need to decide all the bits - location of the doc and all the ingredients

kcoyle: Starting with the pre-requisites

kcoyle: [editing the google doc]

kcoyle: We need a project plan so we can determine what we can do.
… Let's call it for the moment "guidance doc" but it may be called otherwise.

kcoyle: Given the idea of creating the doc around the profile desc voc, we need to follow the W3C process - which includes UCs + Reqs
… Jaroslav_Pullmann and I will re-derive reqs from UCs, and compare them with the profile desc, and see if anything is missing (new UCs).
… So we probably need to get UCs from Rob and Nick.

<antoine> we need to set the github space

kcoyle: We need also to form the group + chairs.

PWinstanley: We also need a clear indication of the working space.

<antoine> I can create github 'milestones' for the 3 deliverables.

kcoyle: So we need to decide whether or not to re-use the original space for the profile guidance doc.

PWinstanley: We need also to start our engagement with stakeholders - the wider community.
… We should avoid what happened so far - very low engagement and feedback.

kcoyle: We also need to set the milestones.

PWinstanley: And a review process.
… For efficiency, this needs to be coordinated.
… Ensure quick feedback (couple of days).
… Note also that the stakeholders may be different from the ones of DCAT - scope of the profile document is broader than DCAT.

antoine: There was a discussion on the moderation of the comment list - so messages are not passing through directly.

kcoyle: We need DaveRaggett to dig deeply into it.

kcoyle: FPWD around early August.

kcoyle: Looking at how the profile desc relates to conneg is another point.

kcoyle: Who's going to do that and when?

LarsG: I can do that. June/July may be feasible to me.

kcoyle: Should this be separate from the group?

LarsG: I can join the group, but I'll be away for 2 months.

roba: One of the things that needs to be checked is whether conneg requires anything on the side of profile desc.

<roba> * +1

<roba> +1

LarsG: May be worth you roba do the coordination with the conneg group.

roba: [agrees]

antoine: I wonder whether we should merge the groups...

<roba> seem to be quite different activities to me ..

kcoyle: I feel they are 2 different activities, although dependent to each other, so merging them could be an option.

antoine: We can discuss this in a later stage.

kcoyle: Anything else we should add to the project plan?

PWinstanley: We need a definitive version of profile desc and comparison with existing alternative approaches.

<antoine> How does this github milestone look? https://‌github.com/‌w3c/‌dxwg/‌milestone/‌9

PWinstanley: This should go in the pre-requisites. It's about a definitive version of the vocs we are going to refer to.

roba: We do need some feedback for consolidating it.

<antoine> I've just created it

<antoine> was there another one on Profile Desc?

<SimonCox> also https://‌github.com/‌w3c/‌dxwg/‌projects/‌2

kcoyle: Thanks for creating that milestone, antoine.

<antoine> SimonCox a kanban board looks great indeed! We'll have to see what is best (a kanban for all profile-related issues could be lot)

LarsG: [noting he posted some questions on profile desc that were not answered]

<roba> projects should help - i tried to respond to all issues I saw related - but may have missed some :-(

<roba> 199?

kcoyle: About the doc outline, I will check other W3C docs.

<roba> ahh - yes thats a nick use case - will chase him for a response

kcoyle: like definition of terms, what the document will cover...

riccardoAlbertoni: Maybe an introduction about the conceptual model behind it?

<antoine> +1

kcoyle: Can we use DCAT and DCAT-AP as examples.

<PWinstanley> https://‌joinup.ec.europa.eu/‌solution/‌core-public-service-vocabulary-application-profile

<roba> we already use DCAT=AP as an example - but would be great to have Makx et al complete and clean these examples.

PWinstanley: Also the ISA Core Public Service vocabulary AP can be an option.

DaveBrowning: ODRL is another one.
… They provide a meta-model, the provide support for extensions, ...

<roba> using prov for DCAT-AP versioning and profile activities is great - maybe profiles are in fact sub types of prov:Entity

SimonCox: [explaining the use of PROV in a similar way for describing projects]

roba: What we need in the examples is to describe the roles, and decide whether they should be skos:Concept's / skos:ConceptScheme's or subclasses.

<antoine> I'd be happy to work on SKOS :-)

<Makx> Not quite sure what you're asking me to do

<roba> currently separate artefact - but aligning with prov may be a good idea?

AndreaPerego: Maybe also the PROV approach can be an example of building profiles - PROV is very generic, and they tell people that to do some more specific things you can create individuals / subclasses.

<Makx> @roba maybe you can explain a bit what you would expect in e-mail?

<roba> @Makx - look at DCAT-AP examples - create a separate file and try to describe all the DCAT-AP metadata you feel is necessaru - and revert back to group with questions as required.

<Makx> @roba where are the DCAT-AP examples?

kcoyle: We need also clarify the notions of profile / application profiles / metadata application profiles

riccardoAlbertoni: The conceptual model can be useful to address this.

kcoyle: Do we have a conceptual model?

<roba> @antoine - do you see class/concept duality (concepts that may have further semantics modelled as classes?)

riccardoAlbertoni: The work done in the Singapore framework, the profile desc and antoine's diagram, put together can be the basis for that model.

<roba> +1 - its just a subset of the singapore framework model

<antoine> @roba - it is doable but if there's a way to avoid it it's maybe better (and not only for OWL2-DL concerns)

<antoine> +1 riccardoAlbertoni

riccardoAlbertoni: There's also an example from DQV: generic classes and examples on how to use them by creating individuals / subclasses.

<roba> @antoine - hard-typing vs soft-typing is a pattern that exists in the real world

kcoyle: Should we also talk about how people define profiles? From documents to code to validation

all: [general agreement]

PWinstanley: It may be worth to talk also about how they support communities, which are their functions (implementing consensus, data sharing)
… Looking at the DCAT-AP example, they provide a collaborative framework ending up in domain-specific and/or country-specific extensions.

kcoyle: It seems that we can come up with quite a substantial document.

<roba> * internet issues

kcoyle: But now it looks difficult to see where profile desc fits in.

<antoine> +1 for what PWinstanley it's a harness/hub

all: [discussion on notion of profile and role of profile desc]

PWinstanley: The starting point is to say what a profile is.

kcoyle: We want to help people build profiles in their environment.

<roba_> guidance is that you should describe how your profile relates to other standards and what the artefacts do.. using profiledesc if you are in an RDF context

kcoyle: We are not going deeply on how to do things

PWinstanley: Agreed, this is actually not possible - there are different ways of doing that, each with their requirements.
… We need to have the minimal set of characteristics for making something an application profile.

SimonCox: The guidance should say: if you want to do that, you need to have, e.g., an artifact to describe a specific roles, etc.

<riccardoAlbertoni> +1 to SimonCox

<roba_> +1

<roba_> langauges are just standards - and likely to be profiles of standards :-)

<roba_> profiledesc uses dct:conformsTo to point to these

AndreaPerego: I wonder whether it would be useful to have a matrix describing the available formal tools, and what you can do with that (contraints definition, validation, etc.).

antoine: [missed that]

<roba_> * we are also hearing it all broken up :-(

<antoine> What I said: We could do extensive examples as Riccardo and I have done for DQV: https://‌www.w3.org/‌TR/‌vocab-dqv/

<antoine> to illustrate the various functions of the profile desc language

<riccardoAlbertoni> +1 to antoine

<antoine> I think the guidance document should work like a Primer to describing and publishing profiles - with Profile Desc as a tool to start doing this

kcoyle: Moving to the profile desc section
… Not sure how this should be presented in the doc.

SimonCox: Could be a specific chapter and/or used to provide the foundation for what said in the guidance doc

kcoyle: I was thinking on how ontologies are presented in W3C docs.
… This is probably what we need it here.
… This would make it more discoverable.
… The actual formal definition will be in another place.
… But the guidance doc will provide the documentation for it.
… The question is what happens if we update the ontology.
… I'm thinking of the future beyond the DXWG work.

<antoine> In addition to what Andrea said: whatever option we chose, we would probably have to update the guidance doc if we update the Profile Desc ontology, because the guidance doc would include examples with the Profile Desc ontology

<Zakim> antoine, you wanted to write my opinion about it ;-)

AndreaPerego: [mentioning the POWDER / POWDER-S example - https://‌www.w3.org/‌2007/‌05/‌powder-s#describedby ]

<antoine> https://‌www.w3.org/‌TR/‌vocab-dqv/ is a note

kcoyle: The guidance doc looks notish - it could be a note and not go to rec track.

<roba_> lets just iterate on profiledesc and decide if it works and how much of dcat it helps with - assume aiming at rec track and downgrade to note if unresolved issues ?

SimonCox: The guidance doc may be a REC (we may be able to point to existing implementations) - not sure about profile desc

<roba_> UCR will need many vocabularies to implement - profiledesc plugs a gap...

LarsG: The point is whether we can have RECs not listed in the charter

<Zakim> antoine, you wanted to flag another versioning concern

<antoine> if a document (the guidance) has to be updated everytime the ontology (profile desc) is updated then it should probably have the same status

<antoine> roba_ -1 actually the profile guidance will tell a more complete story than the profile desc

<PWinstanley> s/loos /looks /

<roba_> profile guidance will provide overview and use examples

<antoine> roba_: +1 on the fact that the guidance will indeed provide overview and examples

kcoyle: We probably need advise from W3C

<roba_> its a note - the ontology is a separate artefact - aim for rec track if it is small and stable and useful and implemented .. fall back to note if not realistic

<antoine> I'm afraid the advice from W3C will be a bit like 'do what you can and what you think is appropriate'. There are many patterns around...

kcoyle: [reading the charter]
… The additional vocs mentioned in the charter are not under REC track.

<antoine> if the profile depends on the profile desc and is on rec track

<antoine> then it can't depend on a note I think

<antoine> so the profile desc would fit as rec track

<antoine> of course it would be different if the guidance goes as note.

<antoine> the guidance is on rec track now but we could decide to move it to note if we think our stuff is not mature enough.

ack

ack

ack

<Zakim> LarsG, you wanted to say that SDW BP was downgraded

<antoine> LarsG +1

LarsG: Why not downgrading to note the guidance doc? This was done for the Spatial Data on the Web BPs

kcoyle: Yes, that could be an option

Conneg

LarsG: [presenting the RFC proposal]
… It is basically about an HTTP header with identifier for the profile, similar to the media type approach

AndreaPerego: What about inheritance relationships between profiles?

LarsG: This would require a hierarchy of profiles. This is not currently included in the proposal.

<roba_> extent?

all: [discussion on profile inheritance / hierarchies]

all: [discussion on HTTP headers, HTTP implementation requirements for profiles]

<roba_> negotiation should _not_ require reading profiledesc (or anything else IMHO)

DaveBrowning: We need to provide fallback mechanisms not requiring changes on the side of the server. Are we going that way?

<roba_> so it comes down to server resolves hierarchy or client resolves it and explicitly asks for everything ...

<roba_> client cant know what compliant sub-profiles a server offers

<roba_> unless we define a HEAD behaviour that requires delivery of the hierarchy tree of specific profiles offered by server

LarsG: If the server returns at list the list of profiles, then it is your job to find the one fitting you

<roba_> "lookup" is problematic - why not list the compliance with more general profiles in a HEAD response?

<roba_> audio is too hard to follow - i will check email if there is something my input required - otherwise really happy this discovery question is explored and happy with anything you think is implementable - profiledesc only needs to be semantically consistent - not actually used in the process IMHO

all: [discussion on different options, and pros and cons for supporting fallback mechanisms for profile conneg]

<roba_> * my lunch might be longer - great stuff all.

PWinstanley: One of the things to make sure is to fix the problem with the moderation filter on the comments list.

<roba_> * use profeiledesc-working branch...

<PWinstanley> progress is being made on Antoine's earlier comment about difficulties with the comment list and DSR and he are resolving

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌blob/‌gh-pages/‌profiles/‌index.html

<kcoyle> https://‌w3c.github.io/‌dxwg/‌profiles/

Jaroslav_Pullmann: I have some questions for the afternoon about how to proceed with UCR and other things.
… This includes proposals about extending the scope of DCAT

[lunch]

DCAT

<Jaroslav_Pullmann> URL to document/project: http://‌www.internationaldataspaces.org/‌en/‌ressource-hub/‌publications-ids/

Jaroslav_Pullmann: the above link is the context. INternational dataspaces is a partnership between companies and academe - the project has created a reference architecture model
… there is an ontology describing digital resources, esp datasets and data apps. The IDSA reference architecture has a layered approach
… The IDS project has varied forms of documentation of the model, the ontology etc. There are also associated resources to assist developers such as a Java model and other resource models developed out of the ontology classes
… Representations (we previously only referred to this in the context of ODRL) are described as UML. There are also faceted views of the (complicated) domain
… The facets package/encapsulate facts about domain elements. Facets are goverened by regulations
… There are internal processes of maintenance
… The project looks at Dataset or Distribution, but it views this from the perspective of function or concern
… views are related to layers
… The ultimate goal is products based on services
… There is scope for re-use of descriptions
… descriptions cover the range of artefacts from abstract to concrete ("Kind", > "Representation" > "Artifact")
… I think that the 'distribution' aspect of DCAT is intermingling concerns and the IDS approach would allow these to be untangled
… My invitation is not only that we look at the reference architecture and see what might be reused
… We could import the abstract concept of "Kind" into our DCAT work

("import" = be inspired by)

Jaroslav_Pullmann: Alejandra's work on bioCaddy has similar
… containment hierarchy is one of the most important design aspects of this IDS model

kcoyle: looking for a diagram in DCAT that we can contrast to this - e.g. the one above 5.1.

SimonCox: I was going to show one

<SimonCox> https://‌rawgit.com/‌w3c/‌dxwg/‌dcat-service-simon/‌dcat/#vocabulary-overview

Jaroslav_Pullmann: I'm bringing in the idea of 'concern-based' thinking

kcoyle: are there parallels with what Jaroslav_Pullmann showed?

SimonCox: in the past attempts were made to shoehorn into distribution, but we recently accepted that it made sense to have a separate class for services
… this is a straw man, but well worked out.
… There were some suggestions that distributions contained services
… but Andrea showed how this can work

Jaroslav_Pullmann: reinterpret Distribution and make them a sort of Service

<danbri> is the idea that 'distribution' tells us about a practical/concrete way of getting some specific representation(s) of a dataset?

DaveBrowning: ths is similar to the was we think wbout things

<danbri> (could be an HTTP download service, with or without content negotiation; or a Web service with query parameters etc.)

kcoyle: if we have 2 copies that are slightly different we need to repeat that distribution

AndreaPerego: I'm not sure if this is a common case - existing implementations the key question is where can I get the data?
… I was trying to work out where the download URL would be in your model?

danbri: simply repeat the property - could be a blank node

AndreaPerego: distribution is a reification between the data set and the file you're getting

SimonCox: the shape we have now is backward compatible

Jaroslav_Pullmann: the suggestion is to separate the concern of communication (accessURL and downloadURL) out.

AndreaPerego: in GeoDCAT-AP we link a pointer to a service in a specific way and a more abstract way. We need to know about a service otherwise the agent doesn't know what to do with it

Jaroslav_Pullmann: there is a plurality of protocols for describing APIs (Swagger, OpenAPI) etc

AndreaPerego: there is no specifcation ruling them all -and we don't need that. depending on the type of service we change the way that we point to it

Jaroslav_Pullmann: this would be a type of action for reading data and it would take parameters

AndreaPerego: in spatial data there is the notion of series (hierarchical) where the links to the subsets are not described

Jaroslav_Pullmann: we can use the type 'Kind' to handle this, by defining abstract access interfaces

AndreaPerego: it is important not to break what is being used already

Jaroslav_Pullmann: agreed. we are minimalistic. Key message is separate out concerns
… we will have >=2 implementations

SimonCox: there are a couple of things - the original DCAT backbone is there. We've introduced the superclass Dataset but there is scope for other subclasses. There are 3 specialisations of service: datadistributionservice, datatransformationservice and discoveryservice

properties that used to be seen on Dataset are now in CataloguedItem

SimonCox: there is the need to preserve the backbone

danbri: I like 'backbone'. but there is a spread of scope
… perhaps there is a need to narrow this

SimonCox: I was trying to accommodate the use of hasPart
… but rdfs:member also has merit

AndreaPerego: the use cases are coming from other communities

danbri: do library catalogues fall into scope?

AndreaPerego: in the geospatial domain it covers services

SimonCox: I know of examples including samples of rock. There are descriptions, which is different to a registry

kcoyle: this isn't how library catalogues are done

SimonCox: this has been most strongly informed by geospatial and cataloging rock samples

kcoyle: the landing point is a metadata description of a thing. up to know it has always been an information resource

SimonCox: maybe a description of rocks is a data source
… I don't think we'll stumble too much. In a catalogue people only look at instances.

kcoyle: I'm still stuck on the rocks example. what is rights about - rock or catalogue record?

SimonCox: issue is that these are in dcat:Distribution. ... but I'm showing stubs - there are no pointers here to rocks, just to metadata

kcoyle: if this was first developed with the idea of distributing only digital information then we need to think about where the 'real' things go

Dan: where is service in this?

<Makx> No I wanted to say something but Simon already said what I wanted to say

SimonCox: yes, in schema.org services are varied. The prototype here is webservice.

AndreaPerego: you're addressing something becoming increasingly required, esp public services. I don't see why we can 't use DCAT for this too

Dan: if we have library services, I can go and ask the desk or use the online catalogue

kcoyle: anaswering the phone is a different kind of service

Dan: there is such a wide scope

Makx: dan's point - we need to realise that we're talking about DCAT so retain focus.
… catalogueItem could be a book, but we're not dealing with that

LarsG: otoh, what digital thing cannot be described as data?

kcoyle: a service.
… so should that be inside DCAT or elsewhere?

<danbri> re scope, I was hoping we'd see things like "here is a pattern for describing time series dataset publications" from this effort; but that could be that I got wrong impression about goals

SimonCox: this requires different profiles of DCAT

<Makx> I agree with Dan. These are questions that people have in practice

danbri: I'm concerned that we are good around datasets but less in other areas. also, what are the communities wanting?

AndreaPerego: for the communities, not having a route to model services will prevent the publication of these data

kcoyle: is there a way to make this more modular?
… like danbri I'm nervous about bringing this into DCAT

SimonCox: I've added this to the branch

AndreaPerego: dct:hasPart is used for many other things - is there a more specific property

kcoyle: would you describe a service unconnected to a dataset?

AndreaPerego: yes

SimonCox: but that takes it out of scope of this group

kcoyle: how deep do you go in describing the service?

SimonCox: not much deeper,

Jaroslav_Pullmann: how do we support users in e.g. chatbot?

SimonCox: scope creep is something to be guarded against

kcoyle: they are all 'data' services

<Zakim> danbri, you wanted to ask whether Catalogs being (sometimes) also Datasets, would allow service aspects to be attached via their "dataset" side

<kcoyle> ack

danbri: there is a type in schema.org that covers all types of services, is there a subset that is appropriate for data services. We use dataset.
… would this tidy things

AndreaPerego: this would be confusing for people

SimonCox: there is a missing link Catalogue and CataloguedItem

SimonCox: the reason to have named classes is to have subclasses

danbri: axioms have their place, but it is not the reason we do things

kcoyle: only a distribution can have a distribution?

SimonCox: data transformation service might not

<danbri> From W3C AC meeting 18 years ago, https://‌www.w3.org/‌DesignIssues/‌NamespacesAreResources.html ... big debate on whether dictionaries belong in the library, and whether namespaces belong in the Web.

SimonCox: it couldhave relations with datasets but would have relations with other data

kcoyle: dataset is the conceptual thing - so how can a service be against a conceptual thing?

<Makx> +1 to karen

<Jaroslav_Pullmann> +1

<danbri> "Are books necessarily products? no... can a thing that's a book often be usefully described as a product, sure."; "Are catalogs necessarily datasets, maybe kinda, maybe no ... can a thing that is a catalog often be usefully described as a dataset, ... sure"

SimonCox: the case we had in mind was a service hosting a number of data services capable of subsetting and delivering in different representations

Jaroslav_Pullmann: we don't have an idea of representation at the moment
… we don't have the "Artifact" from the IDS model

SimonCox: but it has the format

kcoyle: the service will e.g. take statistics and convert to schema.org
… which layer would that go on?

SimonCox: it is data transformation but it would know about schemas and formats, but not about specific datasets

danbri: are there non-catalogued datasets whose interfaces will be related to what you're dealing with? e.g. archival services. I think catalogues are datasets

kcoyle: it seems we are at a similar point to the conversation this morning when discussion around profiles and DCAT - in this case should services be on their own?

AndreaPerego: one possible issue - even though we have the core we may need to modify it ... how do we model the resources in a catalogue. just using the definitionof dcat you can use anything that is not a dataset
… this could be overused/abused

kcoyle: there are other things that can be hasPart.

<danbri> x dcat:dataset y, will imply x dcterms:hasPart y via subpropertyof

<danbri> ... but other different properties are also subproperties of dcterms:hasPart; and those don't necessarily link x and y.

<danbri> if dcterms:hasPart is a subproperty of another property, then x and y would be linked by that relationship too

<AndreaPerego> AndreaPerego: Implicitly, you can put inside a dcat:Catalog resources different from dcat:Dataset's by dct:hasPart - as dcat:dataset is a subproperty of dct:hasPart

AndreaPerego: DCAT is the european std for cataloguing , and the absence of a method of including things other than datasets is restricting use.
… we shouldn't be too open, but we need to expand

kcoyle: we need to open scope carefully

Jaroslav_Pullmann: inappropriate terminology - having dataset at the top of the terminology.
… in updating DCAT what will happen to ADMS?

danbri: we need to channel enthusiasm, so the interest in DCAT needs to be constrained to ensure we don't re-invent RDF inside DCAT

SimonCox: we don't want overuse of dct:hasPart

Makx: re: ADMS - out of scope

<Jaroslav_Pullmann> ... o.k. - but will ADMS automatically import the updated DCAT?

Makx: but ADMS is a profile of DCAT and users use ADMS-AP, this is a different profile of DCAT for a different application

<AndreaPerego> Jaroslav_Pullmann, no there's no import mechanism,

<Makx> +1 to Andrea

<AndreaPerego> DataCite resource types: https://‌webgate.ec.europa.eu/‌CITnet/‌stash/‌projects/‌ODCKAN/‌repos/‌datacite-to-dcat-ap/‌browse/‌documentation/‌Mappings.md#mapping-1st-level

<Makx> @ Jaro: ADMS classes are subclasses of DCAT classes. If those do not change in ways that are not backwards compatible, there should be no problem

<Jaroslav_Pullmann> ... when DCAT URIs do not change and ADMS extends those (historical and new) definitions, then they will become availabe, e.g. adms:Distributions will link to DataServices etc.

AndreaPerego: based on existing communities we can get an idea of what gets put into catalogues

kcoyle: when we type things as text or sound what are we talking about?

kcoyle: creating a standard doesn't control behaviour, it just gives people a starting point

SimonCox: I would be comfortable refactoring the documentation -

<SimonCox> Looking at https://‌rawgit.com/‌w3c/‌dxwg/‌dcat-service-simon/‌dcat/#conformance

SimonCox: note the 'Access to....' bit
… datasets, distributions etc
… I added to the DCAT Profile chunk, inherited from the original doc

kcoyle: it could be definitions of

LarsG: but if we say profiles don't define vocab it couldn't be in

SimonCox: I updated the github to address this - subclassing is a restriction

kcoyle: , but in an RDF way subclassing extends
… is this about subclassing from DCAT?

SimonCox: no, I'm not meaning that. I'm meaning bringing in something from outside
… I am only making small changes to the existing structure

kcoyle: if the group accepts the service idea I'd put it in its own section in this document

SimonCox: at 5.7 we need to complete

LarsG: can a data distribution be read against a live DB?

AndreaPerego: yes, there are sparql endpoints, for example

SimonCox: lastUpdated can be 'now' or with a periodicity

Jaroslav_Pullmann: could this be related to the missing containment relation?

SimonCox: we may need to look at this now

AndreaPerego: people try to do a minimum in terms of metadata entry

Jaroslav_Pullmann: we are looking at wizards and other tools support in the IDS

general discussion on databases vs data services

<danbri> (looking for old w3c notes on rdf <-> uml, ... https://‌www.w3.org/‌TR/‌1998/‌NOTE-rdf-uml-19980804/ didn't really touch these issues, I think there's a 2006ish note that does, somewhere.)

discussion about agents and automation

danbri: will demonstrate way to use JSON-LD context to alias terms in JSON data to different RDF vocabularies, schema.org, etc

<danbri> Dan's presentation: https://‌docs.google.com/‌document/‌d/‌16c_STDu8Dzj-ioRNuGS2tlIFJamlx0-vRKBaPA5Wzfc/‌edit# plus copy content of https://‌gist.githubusercontent.com/‌danbri/‌8979469ddace192a5c0b8fc6e32fbc32/‌raw/‌dba54b89a689fdcd25b8162b70212a326fc0707d/‌gistfile1.txt into https://‌json-ld.org/‌playground/ as an introductory example.

danbri: has the floor
… partial writeup - JSON surface syntax <-> RDF information
… JSON-LD has concept of Context - define shortnames for ns, props, terms
… Context might be inline, or might be remote
… maps cURIs into shortnames
… allows you to hide multiple namespaces, less scary for web devs
… can apply different contexts to the same (surface) JSON --> mapping to different RDF vocabs
… demonstrate with same JSON --> ( schema.org | wikidata | DCAT-AP )
… provides environment to compare how it looks to data, web, search consumers
… will encourage Google to understand JSON-LD Context files
… possibly has relevance to Application Profiles?
… is this possibly in scope for DXWG, possibly for publication as W3C Note?
… will write up as a W3C blog-post in next few days

AndreaPerego: possibly syntax to capture mappings, in particular the common-core of (DCAT | ISO-19115) to schema.org to support indexing
… will never be comprehensive

Group finds it interesting but not sure it is a DXWG thing ... yet

PWinstanley: closing -
… 1. decision about next plenary telecon? Fortnightly date would be 2018-05-15 - too early?
… more sessions to consolidate f2f3 work?
… 2. DCAT FPWD about to land. Need to activate our networks to ensure community input

SimonCox: Profiles team do need to get cranked up!

Next plenary meetings on 2018-05-15, 2018-05-22, 2018-05-29 then fortnightly again

Action: kcoyle to send actions and resolutions to mailing list

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

<kcoyle> BIG THANKS TO RICCARDO!

<AndreaPerego> Thanks, Riccardo!

<LarsG> Very well organised, thanks riccardoalbertoni

<Makx> bye

<LarsG> bye Makx

<AndreaPerego> bye, Makx

Action: danbri to write his blog post

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

<AndreaPerego> [meeting adjourned]