– DRAFT –
DXWG f2f @ TPAC 2018 - Day 1

<SimonCox> Hi folk - I will not join the meeting this morning, but intend to join the first part of this afternnon's session when the discussion of DCAT will occur

<SimonCox> (though it will be late for me 22:30-24:00)

content negotiation requirements

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Arequirement+label%3Aprofile-negotiation

kcoyle: asking LarsG for advice on how to get through quickly

LarsG: are we just looking for what is / isn't in scope, or are we having a longer discussions. we need to have plenary approval or requirements and saying that it is in scope is sufficient. We also need a shhort discussion per requirement

LarsG: on #290 the requirement is about the use of tokens as an alias for a profile URI

LarsG: in my view it is not controversial, but might need to be reworded
… we don't use tokens in the IETF, but would consider if it was a reuquirement

roba: seen references in W3C working draft that use tokens - so it is in real use. question is how does the server recognise the token. I would like it discussed in the IETF discussion to see if it is a requirement

<Jaroslav_Pullmann> FYI: please find the profile requirements based on the previous discussions (spreadsheet) here: https://‌rawgit.com/‌w3c/‌dxwg/‌ucr_profile_requirements/‌ucr/‌index.html#ProfilesRequirements

proposed: accept requirement shown at github #290

<LarsG> +1

<kcoyle> +1

<RiccardoAlbertoni> +1

<AndreaPerego> +1

+1

<roba> +1

<antoine> +1

<DaveBrowning> +1

<Jaroslav_Pullmann> +1 (find it here: https://‌rawgit.com/‌w3c/‌dxwg/‌ucr_profile_requirements/‌ucr/‌index.html#RPFALIAS)

<ncar> +1

<LarsG> that's with ncar's proposed re-wording!

Resolved: accept requirement shown at github #290

LarsG: rewording is from ncar first comment

kcoyle: we break at 09:30
… next is #289
… reqording from ncar

LarsG: I think we accept with rewording follwing discussion a couple of months back

proposed: accept #289

<AndreaPerego> +1

<RiccardoAlbertoni> +1

<antoine> -1

<ncar> +1

+1

<LarsG> +1

<kcoyle> +1

<roba> have some reservations about wording too

<roba> i think it is a "combination of" needed

<Jaroslav_Pullmann> +1 (https://‌rawgit.com/‌w3c/‌dxwg/‌ucr_profile_requirements/‌ucr/‌index.html#RPFSREQ)

antoine: I would like clarification - I like the beginning of the text, but not the last bit

<antoine> +1

antoine: the rewording is better, but can I change the title of the requirement

proposed: accept #289 with antoine's rewording

<DaveBrowning> +1

+

<AndreaPerego> +1

<RiccardoAlbertoni> +1

<kcoyle> +1

<ncar> +1

<antoine> 1

Resolved: accept #289 with antoine's rewording

<roba> +1 (belatedly)

LarsG: next is #288 . it goes back to use case 5.5 talking about the graph of metadata, but in my mind that is a solution and not a requirement, so this is controversial as a requirement

kcoyle: skip this and come back to it tomorrow

Action: LarsG to make a suggestion to deal with #288

<trackbot> Created ACTION-240 - Make a suggestion to deal with #288 [on Lars G. Svensson - due 2018-11-01].

roba: I'm chasing up the same clarification as antoine

Jaroslav_Pullmann: according to the spreadsheet we have this marked as 'approved'

kcoyle: the google doc record shows that the group didn't get this far with the considerations

kcoyle: on to #287

<roba> re 288 - i think machine readability is a requirement - the solution would be choice of a specific vocabulary and graph shape required.

LarsG: there is a rewording suggestion by antoine and this was discussed in a telecon in June, removing the word 'modular', and say that some data can conform to several profiles at once

kcoyle: looks like we already approved it

kcoyle: going to #286 ... according to the spreadsheet this is approved, the wording is different in the googledoc

<antoine> https://‌docs.google.com/‌document/‌d/‌13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/

antoine: when I do the rewording do I keep the links?

kcoyle: yes
… next up is #264

LarsG: this use case is about discoverability of profiles, but I couldn't read this requirement from the use case. can roba clarify?

roba: the description should match the profile the conneg relates to

Action: roba to clarify #264

<trackbot> Created ACTION-241 - Clarify #264 [on Rob Atkinson - due 2018-11-01].

Jaroslav_Pullmann: is the requirement as it is able to be approved?

kcoyle: no, we await clarification
… next up is #265

LarsG: it is in scope

Jaroslav_Pullmann: there was a legacy requirement which was prior to github that covered this

<Jaroslav_Pullmann> prev. version: https://‌rawgit.com/‌w3c/‌dxwg/‌ucr_profile_requirements/‌ucr/‌index.html#RPFN

<roba> action completed.

<roba> https://‌github.com/‌w3c/‌dxwg/‌issues/‌264 updated

AndreaPerego: I've a similar concern, why are we not talking about data profiles, or just 'profiles', otherwise it is just about negotiating the profile you want back

<roba> metadata => data +1

kcoyle: that comment came up on the profile guidance by annette, we replace 'metadata' with 'data' generally. We can add this as an issue

AndreaPerego: for me there is no difference between data and metadata

kcoyle: let us create an issue, make a comprehensive decision

Action: AndreaPerego to create an issue about metadata vs data in relation to #265

kcoyle: proposed: accept #265 but with the change from 'metadata' to 'data'

<trackbot> Created ACTION-242 - Create an issue about metadata vs data in relation to #265 [on Andrea Perego - due 2018-11-01].

<kcoyle> proposal: accept #265 but with the change from 'metadata' to 'data'

<roba> +1

<LarsG> +1

+1

<AndreaPerego> +1

<RiccardoAlbertoni> +1

<DaveBrowning> +1

<antoine> +1

<ncar> +1

Resolved: accept #265 but with the change from 'metadata' to 'data'

kcoyle: next up is #266
… this has a number of parts

LarsG: 'other profiles' means profiles other than the one that the data conformed to in the response

kcoyle: there might need to be a little more context

ncar: this is a core requirement. it was narrowly scoped, but it is a general principle.
… it applies across all realisaitons we can think of

kcoyle: we can accept in principle

proposed: accept #266 in principle, and realise that there might be some rewording

<LarsG> +1

<ncar> +1

antoine: I'm trying to change the github and googledoc at the same time. please slow down

<kcoyle> +1

<roba> +1

<RiccardoAlbertoni> +1

+1

<AndreaPerego> +1

<Jaroslav_Pullmann> +1

<DaveBrowning> +1

<antoine> +1

resolveed: accept #266 in principle, and realise that there might be some rewording

kcoyle: next is #267

<AndreaPerego> https://‌github.com/‌w3c/‌dxwg/‌issues/‌267

LarsG: that is not a profile negotiation requirement, so need to change the label

roba: there was a decision to split content negotiation and profile negotiation

kcoyle: so is this in scope elsewhere

roba: yes, it relates to distributions not profiles

AndreaPerego: is this in scope of profile guidance

roba: maybe not

Jaroslav_Pullmann: maybe the keyword 'profile' could be removed?

roba: profile guidance is the wrong tag, dcat should be there

antoine: I'm going to solicit roba's help in understanding the 2 pages in the googledoc about this.

roba: I will review and port to github

Action: roba to go back through the discussion, come to a conclusion, discuss with antoine and work out what requirement #267 actually meant

<trackbot> Created ACTION-243 - Go back through the discussion, come to a conclusion, discuss with antoine and work out what requirement #267 actually meant [on Rob Atkinson - due 2018-11-01].

<AndreaPerego> 'dcat' label added to https://‌github.com/‌w3c/‌dxwg/‌issues/‌267

Jaroslav_Pullmann: makes sense to consider profile as well, so the constraints on packaging.

kcoyle: that takes us through requirements. We can summarise later

LarsG: #217 - is this still awaiting approval?

<AndreaPerego> https://‌github.com/‌w3c/‌dxwg/‌issues/‌217

kcoyle: We have already covered that - there is a duplicate in github, and we will deduplicate at some time

<roba> ok refreshed - its definitely a DCAT expressivity problem - data distribution services will need to describe both the service profile(s) and the data payload profile(s)

antoine: I think we need to dedupe now

AndreaPerego: the dupe is #212

Jaroslav_Pullmann: and #268

kcoyle: we need to tidy up the issues as soon as Jaroslav_Pullmann has the document written

Jaroslav_Pullmann: the gdoc is outdated

LarsG: do we merge or remove ?

kcoyle: I suggest we remove #217 (the earlier one) and when the UCR group is confident it has finished, they can be closed

kcoyle: labelling in github has been ad hoc
… We have completed the task and between now and break we can return to 8:30-8:45
… an email was sent to the list and after a chat with dsr and Philippe Le Hégaret we wanted to look at how we manages the additional resources (examples etc) and also the Profiles Ontology
… Philippe suggested that one way to clarify the Profiles Ontology was to issue it as a FPWD. We asked about the style of the doc and his response was that he needed to see the proposed doc before he could make a decision

<kcoyle> PWinstanley: we need a group decision; does anyone have any objection to issuing a first public working draft

<ncar> Profiles Ontology, as published at https://‌w3c.github.io/‌dxwg/‌profilesont/, is currently formatted as a Rec FPWD

AndreaPerego: publishing on the rec track is fine, as long as there are no shortcomings from bringing it forward on the rec track

RiccardoAlbertoni we did the DQV as a note

DaveBrowning: Did you also talk about examples

<antoine> PWinstanley: the examples could be packed up with the document

<antoine> ... provided they are not updated separately from the doc.

dsr: it is a matter of how they are curated

DaveBrowning: in the case of DCAT there are several examples that might be useful and might be curated separately

dsr: you can have an informative link to github and curate them separately
… critical stuff can be bundled with the main document

ncar: we have an example of profiles that use this ontology we would want to publish those alongside the ontology document. the link has yet to be included, but there is in the github a folder of examples.

kcoyle: put those into the document prior to publication, just a small section pointing to the github area

proposed: we decide to publish the profiles ontology as a first public working draft

<ncar> +1

<kcoyle> +1

+1

<DaveBrowning> +1

<roba> +1

<Jaroslav_Pullmann> +1

<RiccardoAlbertoni> 0

<AndreaPerego> +1

<LarsG> 0

<antoine> 0

Resolved: we decide to publish the profiles ontology as a first public working draft

<roba> yes its conformsTo

Jaroslav_Pullmann: when looking at the DCAT 2PWD and discussing runtime behaviour, can we link a profile to a distribution. is this covered by conformsTo?

<ncar> If it's the content, it;s the Dataset that needs to conformsTo, not the Distribution

AndreaPerego: looking at what is currently used for packaging, this is mainly relating to format. I don't know if they can be called profiles

kcoyle: it sounds as though conformsTo becomes ambiguous - it could relate a data set to a standard, or a profile.

<roba> its up to DCAT to work out hopw to use conformsTo (its already ambiguous - profile is just another option for a relevant standard)

<roba> prof:Profile rdfs:subclassOf dct:Standard

AndreaPerego: thinking about packaging, I have 2 scenarios: compressed package containing the same things (like shape files) and this is essentially a format. In a more heterogeneous zip file, the format is the zip file, but I don't see how this can be linked to profile, it is just a packaging

<roba> see note on action https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌243

ncar: it is for DCAT to work out what is missing from the profiles ontology

<roba> "its definitely a DCAT expressivity problem - data distribution services will need to describe both the service profile(s) - which may introduce containers and the data payload profile(s) for data within those containers The conneg requirement may be for negotiation of the container - for example Accept-Encoding can ask for gzip, which has a container and a manifest."

<Jaroslav_Pullmann> My point is asking the profile (guidance) and DCAT groups to consider stating a static relation between a Distribution and a Profile (e.g. by extending the dct:conformsTo prediate)

roba: see my comment above. These are communal concerns; format, packaging and profile are open questions for working out what conformsTo relates to . The DCAT group may be able to provide guidance

kcoyle: tomorrow we will discuss interdependency of documents, and this is germane to that discussion.

<roba> i think the goal is to minimise interdependence

kcoyle: it is set for tomorrow afternoon, Lyon time, and perhaps we need to move to the morning to allow Australian colleagues to contribute. Should we change the order of tomorrow's discussion?
… work it out by the end of the day

Jaroslav_Pullmann: I didn't find this information in DCAT, and perhaps it should be

roba: if there is something we can do to help DCAT by creating extra roles in the profiles ontology then we can do that
… the minimisation of interdependencies is a key point to keep in mind

kcoyle: we should eliminate dependencies

break now for no more than 40 mins

https://‌photos.app.goo.gl/‌Ji4okxktTpqUUF7A8 is the photo of the post-it notes

<ncar> I'm back

kcoyle: [reporting about the work done yesterday on the prof guidance doc]

Picture of post-it's: https://‌photos.app.goo.gl/‌ptHGcZKgqdFivPNY7

<ncar> Got it thanks

<kcoyle> https://‌raw.githack.com/‌w3c/‌dxwg/‌guidance-restructuring-LyonOct24/‌profiles/‌index.html

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

kcoyle: restructured guidance prepared by antoine

antoine: we started from a very long list of reqs and recommendation.
… the idea was to split that list to structure the different parts of the doc about what we want to day about profiles
… first conceptual model, then publication of profiles
… extended a bit the part about admin metadata which have their own reqs, to be refined.
… We also had some discussion about the model, aligning what is in the prof descr ontology.
… We drafted also a proposal for the conceptual model, not having impact of the doc structure.

<PWinstanley> antoine: speaking through some post-it notes

antoine: about the motivation: introduction already very long, and we wanted to add also motivations (karen suggested some text not yet in the doc)
… conceptual model can provide good introduction on the overall content of the doc.
… the new section on functions and roles was picked from what roba and ncar suggested

ncar: [mentioning how to use a slash namespace for organising content]

roba: [asking about how this kind of "registry" will be managed @ W3C]

philippe: We have plenty of registry, but we don't have a consistent way of maintaining them. I can bring Ralph in this room who knows better.

<antoine> The PR is at https://‌github.com/‌w3c/‌dxwg/‌pull/‌489

<PWinstanley> AndreaPerego: we talked before about having the profile ontology as a FPWD, knowing that we might have a note

<PWinstanley> ... are roles going to be stable over time

<PWinstanley> ... maybe roles should be maintained seperately from the profiles ontology

<PWinstanley> ncar: the namespace for w/g things is stable, but the roles should be separate

antoine: We should then discuss the voc of roles before going to that. The registry is about an operational things. We'd better discuss the document now.

kcoyle: [reading post-it's]

antoine: what karen is reading is also at https://‌github.com/‌w3c/‌dxwg/‌pull/‌489

roba: I think this is a positive steps in general.

antoine: note that the list is actually coming from 2 different GH lists, so I kept existing duplicates.

antoine: The model will be in Section 2 (What is a profile?)
… It is supposed to include a picture linked to from the text.
… [reading and explaining the text]
… so the section is organised in 3 layers: profile, manifestation, distribution
… then there's the notion of role, possibly to be attached to manifestation or distribution (to be discussed)
… This basically matches the different levels in the prof ontology.

<riccardoAlbertoni> +1 to use "distributions of manifestations" rather than "distributions" alone as antoine has just done..

roba: I some concerns that some of the high level definition
… some of the reqs are probably to specific (e.g., implying profile of a schema)

kcoyle: are there profiles which are not about schemas?

roba: for instance services

kcoyle: services would be probably out of scope for DXWG

roba: I would nonetheless restrict the scope in the requirements.

antoine: Note this list of must and should is coming from previous reflections, and it is not reflecting completely our reqs. The end result may not be this set of things.

roba: ack'ed

kcoyle: [looking now at profile publication]

antoine: this is the point where things become "meta-meta" - applying profile negotiation with profiles

LarsG: coming back to antoine said - indeed we need to talk about that. We were also talking yesterday about profiles of profiles
… e.g., a SHACL distribution of a profile can be considered as a SHACL profile

kcoyle: In the document, when we talk about profiles, we talk about all these things (PDF, SHACL docs) as profiles?

<roba> q

roba: The profile should be conceptual thing, not the "logical" representations (may they be a PDF, schema, etc.)

<ncar> The pre-DXWG work, Geoscience Australia, profile of ISO19115 that is a collection of things: http://‌pid.geoscience.gov.au/‌def/‌schema/‌ga/‌ISO19115-1-2014

antoine: Indeed we should refer to the conceptual thing

<ncar> My current test, dummy, DC AP and Prof Ont profile: https://‌github.com/‌CSIRO-enviro-informatics/‌csiro-epub-dcap

<ncar> thanks

PWinstanley: [raising the issues about whether we should have profile distributions in packages]

<roba> antoine is correct

<Zakim> LarsG, you wanted to say that we should talk about resource vs. representation and not about dataset vs distribution in order to keep up with web architecture lingo

<riccardoAlbertoni> +1 to lars

LarsG: Probably we should not just use the DCAT view (distributions) but we should rather use more generic Web architecture terms as resources and representations.

<roba> we have dcat approach as an "alignment" for that reason

<DaveBrowning> +1 for LarsG observation

ncar: We can establish what could/should be in a profile by documenting existing profiles and test profiles using Profiles Ontology - a test we already have - and then actually implementing the example descriptions

riccardoAlbertoni: The use we make of the notion of distribution is a bit ambiguous.
… I think we should start using "distribution of ..." to remove this ambiguity.

antoine: agreed. I'll put it into a note in the doc

<alejandra> https://‌en.wikipedia.org/‌wiki/‌Functional_Requirements_for_Bibliographic_Records

alejandra: Manifestation reminds me of FRBR

<PWinstanley> AndreaPerego: the FRBR was always complicated for people outside of the library field. I'm concerned about the multiple uses of distribution. Profile is conceptual... but a constraint can be expressed in different ways / encodings

<PWinstanley> ... because in ADMS we had the same sort of problem, and the separation wasn't made. To get to the doc or machine-readable representation I need to take 2 steps rather than 1

<PWinstanley> ... This case is particular, we need an intermediate entity

<PWinstanley> antoine: there could be a shortcut between identifier and encoding

<roba> +1

<PWinstanley> ... a preference could be expressed by the client

<PWinstanley> .... in terms of the service, I don't think there is a requirement for serving something in the miggle

<PWinstanley> AndreaPerego: in ADMS they were served togther using conformsTo

riccardoAlbertoni: We have 2 conceptual models, one from the prof ontology and the one prepared by antoine.
… It may be worth creating an action to put them together, so that we can discuss about the same model.

antoine: Yes, and actually we have already started looking into it (it's in the non-visible post-it's).

Action: antoine to integrate the profile schema diagrams

<trackbot> Created ACTION-244 - Integrate the profile schema diagrams [on Antoine Isaac - due 2018-11-01].

antoine: noting ralph is here

roba: [explaining to ralph the issue]
… we need to create a voc for a non-exhaustive list of roles, that may be updated over time, but without the need to modify the parent spec.

ralph: This was addressed with various group. We don't have a design pattern. The Social Web WG did something, so we can have a look at that.
… If the registry is not meant to be normative (so if the list of "names" is not normative), this shouldn't be a problem.

antoine: maybe we can go for a mixed solution. The roles we identified based on reqs will go in the voc, then we can provide guidance on how to extend it, and they can be placed elsewhere.

<riccardoAlbertoni> +1 to the antoine's proposal about using the same pattern OA used for motivations

<Zakim> LarsG, you wanted to ask if extensions would be in the same ConceptScheme (easier for validation...)

ncar: [missed]

<ncar> I would like to guard against the mixed proposal from Antoine. Experience from the ISO is that if some items are listed in a normative doc, and extended items are listed elsewhere, only the normative items will ever get use, not the extended terms

antoine: The roles in the REC cannot be draft, they are supposed to be strongly motivated.

<ncar> People just look only at the normative document, regardless of suggestions that they can/should extend it

ncar: I think eventually the options we have are based on whether W3C offers or not a registry function

ralph: This may happen, but we don't have it now

ncar: so we may be able to do this in the future

antoine: We may be careful about a possible registry service, as organisation developing extension may want to own them

AndreaPerego: I have also concerns, as there would be a need of a governance body, in case these extension will end up in W3C space

antoine: I would propose to have provisionally the roles inside the same file of the voc, and then we re-consider it if/when the registry function is in place at W3C

roba: At the moment, we have roles in a separate file, and then we can merge it later with the voc once we take a final decision.

antoine: Fine with me, provided that we agree we can re-visit this decision later.

ralph leaves [thanks for your help!]

kcoyle: let's go on.
… we are now at the profile ontology

<roba> agree with antoine

antoine: here we should explain why we need a profile ontology

PWinstanley: what about the privacy / security statement

alejandra: Dave Raggett said that we need to have it in any case

AndreaPerego: descriptive metadata may be about people (contributors, authors, maintainers)

antoine: so we can have a note mentioning that

<Zakim> LarsG, you wanted to point to the conneg version of s&p

alejandra: We looked into it for DCAT, and there's a questionnaire for that

<alejandra> this is the security and privacy self review questionnaire: https://‌www.w3.org/‌TR/‌security-privacy-questionnaire/

<LarsG> https://‌github.com/‌w3c/‌dxwg/‌issues/‌461#issuecomment-432632021

AndreaPerego: The issue is anyway about publishing names of people, their email addresses, etc. And there's also the issue that not attributing authorship/ownership may infringe IPR.

kcoyle: we should ask advice from the privacy people at W3C

antoine: coming back to the main topic. Can I merge this PR?

kcoyle: roba, what do you think?

roba: fine with me

kcoyle: So, we can go to lunch now.

We will begin again at 13:30 CEST (within 1:15 h).

[lunch]

DCAT and questions relating to what constitutes "done", and outreach

<PWinstanley> alejandra: remember to define timetable

<PWinstanley> DaveBrowning: I can start with an opinion; looking at where we are, the outstanding requirements (based on github issues) we have 34 requirements still open and another 40 issues that are not 'requirements'

<PWinstanley> ... The big question is significant requirements are for illustrations / guidance on good practice usage. Because we have modularised DCAT the 'correct' answer of how to use is best shown as an example

... but we could have a registry of examples that we could use in a reactive way to questions

... this will be time-consuming, and needs organisation. Normative things are fewer and perhaps easier to sort

<DaveBrowning> https://‌docs.google.com/‌spreadsheets/‌d/‌1aQqV5Dl3blsjk-Htx5bWZbXghvVZhl1mKOix4aAfL0g/‌edit#gid=0

... In this link the spreadsheet shows each DCAT requirement that is still open, and I have classified them (Column E). "ProvideAWay" means, essentially, provide an example. Red indicates items we have to address because they are important and need to be dealt with in the normative text.

... There are several issues relating to mixed aggregations of files in e.g. zips, and this is a cluster of questions related to the DCAT spec.

... There is a single requirement (tagged Red) to do with 'related datasets' but it is the only requirement that we have that poses the question of supprting subsets.

... Identifiers; relations between datasets, and multiple files are the 3 areas that need attention

alejandra: I agree with the main points you raise. I'm concerned if we have only to the end of november. We have only received one comment to date, it was quite critical and related to data services. If we (hopefully) get more comment, how do we handle?

DaveBrowning: I agree, if we get comments we need to have the time to handle comments

AndreaPerego: We have to reply to each comment; this has to be recorded

AndreaPerego: related datasets -?

DaveBrowning: There are a couple that fade into each other - input and output datasets; this then becomes a conversation about provenance

alejandra: there is also the point about subsets

DaveBrowning: One thing about DCAT is that it is flat and alll about registering datasets.

<alejandra> relationships between datasets included other stuff apart from sub-datasets

<alejandra> https://‌www.w3.org/‌TR/‌dcat-ucr/#ID32

DaveBrowning: perhaps it is not a big change, but we need to do the work

<alejandra> https://‌www.w3.org/‌TR/‌dcat-ucr/#ID47

. Services are tagged in yellow

<SimonCox> I made a proposal about related datasets here: https://‌github.com/‌w3c/‌dxwg/‌wiki/‌Qualified-relations#related-datasets

Jaroslav_Pullmann: how does this grouping relate to the UCR?

DaveBrowning: versioning ones are the same as the UCR. "ProvideAWay" is where we show what things that are away from the DCAT spec can be done (using other vocabs, perhaps)

Jaroslav_Pullmann: we haven't considered if this is complete. e.g. ADMS features haven't been included - relationships (partOf, instanceOf, exampleInstanceOf, etc)

<AndreaPerego> About input dataset, there's also an example here: https://‌github.com/‌w3c/‌dxwg/‌wiki/‌Provenance-patterns

Jaroslav_Pullmann: the grouping should help us see if the document is feature complete

DaveBrowning: identifiers come up several times, and our responses need to be coherent

kcoyle: Of these, which do you think are essential before Rec track?

DaveBrowning: Red ones, but some - e.g. multi-files, will also address the ADMS one

<alejandra> temporal coverage should also be addressed IMO

DaveBrowning: These are the structurally important ones which need illustrations close to the normative text

riccardoAlbertoni: assuming we are not able to deliver the final version by Nov, shall we define a non-normative doc to sweep up what we want to cover but that doesn't need to be in the normative doc?
… I think that part of the work to date is stable. but other parts need more elaboration. Is there the opportunity to shift things

DaveBrowning: yes. looking at the non-requirement issues many are crosswalk ones

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Adcat+-label%3Arequirement

DaveBrowning: there are a series of 'alignment' issues

<alejandra> some (or all?) of these alignments could become examples of profiles

kcoyle: this was a question we asked Phillipe; the alignments can be links to informative files, or they can be included in the package. If the latter then they are harder to vary over time, but providing a link to e.g. a github folder allows more flexibility

SimonCox: discussion on relationships between data sets - there has been work done on this, well worked out proposal done some weeks ago at 13:48

<SimonCox> I made a proposal about related datasets here: https://‌github.com/‌w3c/‌dxwg/‌wiki/‌Qualified-relations#related-datasets

SimonCox: this hasn't yet made it into the document; it is based on Prov-O, but the predicates in that vocab were not suitable

DaveBrowning: we've done a bit on quite a few of theise things

AndreaPerego: I am in favour of having them outside the doc, informative not normative

antoine: I'm in favour of having them outside. they will date, become less interesting over time

alejandra: some could become subjects for profiles examples, so we need to consider this

kcoyle: are you thinking of an examples document?

<riccardoAlbertoni> +1 to andrea and antoine's ( about having the mapping defined as not normative, as they depend also on the mapping target)

DaveBrowning: when discussed last week the notion of a good primer was seen as potentially very valuable, but this is hard to write. We could try but doing it well is hard to achieve

kcoyle: If we put the effort into completing the normative DCAT doc, could a primer be written after that (it is only informative)?
… we could hang onto the idea and see if there is scope for doing that whilst we await feedback

SimonCox: The list of alignments are not essential for the normative doc, moving them out is not a problem

proposed: keep the examples out of the normative document and provide a link to their location

<antoine> +1

<AndreaPerego> +1

<SimonCox> (However, the alignment with schema.org - which is the only complete one - might stay?)

+1

<DaveBrowning> +1

<LarsG> +1

<kcoyle> +1

<Jaroslav_Pullmann> +1

<alejandra> the examples in the proposal refer to alignments

<alejandra> +1

<riccardoAlbertoni> +0

proposed: keep the alignments out of the normative document and provide a link to their location

<antoine> +1

<LarsG> +1

<kcoyle> +1

+1

<riccardoAlbertoni> +1

<AndreaPerego> +1

<alejandra> +1

<DaveBrowning> +1

<SimonCox> +1

resolveded: keep the alignments out of the normative document and provide a link to their location

Resolved: keep the alignments out of the normative document and provide a link to their location

<SimonCox> (Perhaps persist the schema.org alignment in an Appendix?)

<DaveBrowning> Agree with SimonCox re keeping one...

danbri: schema.org structure around datasets is roughly the same as DCAT. schema.org has stepped back for the duration of DXWG on making changes, but we want to move closer to the changes in DCAT and so it will be better to hold the alignments in a place where they are easy to update

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌blob/‌gh-pages/‌dcat/‌rdf/‌dcat-schema.ttl

<danbri> (there's also "DCAT mapping" vs "DCAT plus DCAT-AP plus Stat-DCAT-AP, Geo-DCAT-AP, ...."

<danbri> )

antoine: in Europeana we are working on schema.org mapping. there are certain things that are not easy to deal with ... can we make some mapping non-normative.

AndreaPerego: since schema.org subset for datasets is based on DCAT should the mapping stay with schema.org, so that maintenance is easier?

danbri: I'd like to get our definitions updates. this doesn't mean that schema.org needs to be their primary home

kcoyle: I see that this makes normative statements between DC and Schema.org with DCAT being a third party.

<SimonCox> How are they normative?

<SimonCox> The reference to this mapping is in a part of the DCAT document labelled 'non-normative'

kcoyle: it seems difficult to see these as normative untill the mappings have been agreed. Should this be 'normative'?

danbri: I would keep it out, so that it is flexible and easily updated

<SimonCox> It says quite clearly in https://‌w3c.github.io/‌dxwg/‌dcat/#dcat-sdo that the mapping is non-normative!

<danbri> SimonCox, we lost Zakim

alejandra: It isn't normative.

<SimonCox> WHere did the 'normative' notion appear from. This discussion is a red-herring.

kcoyle: we need to be able to keep things in sync

<LarsG> + to ask about transitiveness of owl:equivalentProperty

<kcoyle> Simon, even if non-normative, once in the document it will be hard to change

alejandra: google dataset search makes use of DCAT. If that continues, can we just leave schema.org annotation etc to Google?

danbri: questions on extensions tend to be geo etc; we are unlikely to switch to DCAT being the primary focus

SimonCox: concerned about the direction of the discussion - we talked about 'normative

<danbri> FWIW I had a quick look in schema.org repository, for equiv term mappings to Dublin Core (or other things at purl), https://‌gist.github.com/‌danbri/‌00dd111e84922073f030a46fa425e5c9

SimonCox: and this is not the case, they are not thought of as normative

kcoyle: I agree - the issue is that DC itself is in the process of creating an alignment to schema.org, and if that differes then having the alignment outside of the doc makes it more flexible for changing it

<Zakim> LarsG, you wanted to ask about transitiveness of owl:equivalentProperty

LarsG: general sense of 'unwellness' with the W3C publicaiton process for the html doc whereas the turtle can be updated easily
… second point is a problem with schema.org crosswalk with equivalent type

<SimonCox> As the pink note says: "This alignment of DCAT with schema.org is provisional and non-normative. Feedback is invited in the issue tracker."

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues/‌251

<LarsG> the aligment dct:format owl:equivalentProperty schema:encodingFormat and dcat:mediaType owl:equivalentProperty schema:encodingFormat implies dct:format owl:equivalentProperty dcat:mediaType

<danbri> SimonCox, re "dct:type
… owl:equivalentProperty
… schema:additionalType", I think on the schemaorg side it is closer to rdf:type, but I've heard that argument used in DC too, that dct:type is basically rdf:type

<danbri> also schema:encodingFormat allows URLs for things without known media types

Action: LarsG to add action on owl:equivalentProperty confusion

<trackbot> Created ACTION-245 - Add action on owl:equivalentproperty confusion [on Lars G. Svensson - due 2018-11-01].

<SimonCox> rdf:type comes with RDF entailments. dct:type is just a classifier.

<danbri> Microdata didn't allow us to have multiple types from different namespaces, hence additionalType; in rdfa etc we aid to use rdf:type instead

<SimonCox> ... and also rdfs:entailments (re domain and range constraints, for example)

DaveBrowning: I think that it is desirable in the normative text, but in a non-normative section, to show the reader an illustration alignment.

<danbri> maybe skos:closeMatch is worth using for some of these

DaveBrowning: we need to just demonstrate the principle
… schema.org is a good one to do because of its wide exposure

<danbri> https://‌schema.org/‌additionalType "This is a relationship between something and a class that the thing is in. In RDFa syntax, it is better to use the native RDFa syntax - the 'typeof' attribute - for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally."

<SimonCox> SKOS mapping properties might be a better option ... except I was a little unsure about domain-range entailments

<Zakim> danbri, you wanted to give the only 2 problems I'm aware of with the mapping 1) it hasn't been widely reviewed (incl. by me, despite Simon's invitation); 2) Schema.org tries to re-use terms where possibly so "equivalent" might not be equiv enough for some tidy-minded folks

danbri: kcoyle is correct in that there are problems with the mappings - under-review is one of them. How do we know a good mapping? what is the test? Soemtimes this is just reciprocal respect between two communities rather than using them in a computational system. The Google search results for

DCAT and Schema.org are not necessarily 1:1 exact .

<SimonCox> SKOS mapping relations have skos:Concept for both domain and range ...

... if we have them in a repo we can refer to them. Is anyone expecting to use them computationally?

DaveBrowning: I'm interested in showing acknowledgement - we know the prior art

<danbri> see also shapes discussion https://‌github.com/‌SEMICeu/‌dcat-ap_shacl/ and https://‌github.com/‌SEMICeu/‌dcat-ap_shacl/‌issues/‌32

AndreaPerego: we did a mapping from DCAT-AP to schema.org, but we are only using it with SPARQL queries. I think we have some SKOS definitions. The queries do the mapping, they are agnostic to the properties

phila: have you considered replacing DC with Schema.org in DCAT?

<AndreaPerego> DCAT-AP to schema.org here : https://‌ec-jrc.github.io/‌dcat-ap-to-schema-org/ . And I was wrong: we don't have SKOS, just SPARQL

danbri: what we have put up is public datasets reflected into a KG ... there is a python API, pandas dataframes etc.
… DCAT is bigger in Europe, it deals with datasets. The challenges in the next years are how to get deeper into the datasets. the upper level metadata distracts from the harder work deeper in the datasets
… switching schema description is minor, compared to the hard stuff

<Zakim> LarsG, you wanted to ask if it makes sense to publish ttl files if the mappings are not to be used in a computational setting

LarsG: if those alignments are not to be used, why do we publish them in OWL or Turtle at all, why not just a table or diagram in the HTML doc. The publication in the Turtle form implicitly suggests that we are wanting to use in a computational env

danbri: we have RDFa using OWL. There is less in the interfaces because we don't know the audience

kcoyle: given that this is an informative section of the doc, even though there are OWL statements, they might not need to be in the doc. Perhaps a table might be useful, make it more 'open'. We could then refer via a link to the turtle file
… that would get us by the OWL property issues

<danbri> FWIW view-source:https://‌schema.org/‌Dataset you see RDFa + OWL, <link property="owl:equivalentClass" href="http://‌purl.org/‌dc/‌dcmitype/‌Dataset"/> etc. I believe the reason we don't sohw this in the human-facing doc is that we don't want to send innocent humans to a Turtle-only page.

alejandra: I agree that they were originally prior art, the next step is to use them computationally. The form might be improved. We are being distracted by this issue
… we need to deal with identifiers, subsets, etc

<DaveBrowning> +1 to alejandra view

+1 to alejandra

<AndreaPerego> +1 from me as well

<riccardoAlbertoni> +1

<SimonCox> I agree that the owl:equivalent* axioms are possibly a bit strong in some cases (and incorrect in the case Lars pointed out) so a different notation might be used in the HTML document

<danbri> +1

AndreaPerego: I would be cautious to use these alignments for computational work; there are gaps between schema.org and DCAT. spatial coverage differences exist; so crosswalks are not just matching classes and properties

<SimonCox> Thanks for clarification about schema:additionalType - so it is a kludge to get around limitation of RDFa!

danbri: schema.org has had geo, but it needs to be improved

<danbri> SimonCox, rather a limitation of microdata (which leans towards monolithic single namespaces, whereas we want to be able to e.g. use Wikidata for 2nd types)

<danbri> SimonCox, thinking through schema:Dataset vs http://‌purl.org/‌dc/‌dcmitype/‌Dataset etc., it would be good to have the turtle give human-readable URLs for latter alongside the "official" term URIs, so that human-oriented hyperlinks could point to friendly human docs

DaveBrowning: we understand the approach we want to take with examples. We are agreed on the classification as shown in the spreadsheet. I've tried to estimate the work, but haven't been able to - it is difficult to estimate.

kcoyle: can you prioritise?

DaveBrowning: versioning is important. tbd asap. this will help other conversations across the doc. after having sorted versioning we might see other things in a different way
… I want to start with that.
… after that identifiers is crucial;

<SimonCox> Dataset relations is v important IMHO

DaveBrowning: multi-files is stand-alone

<alejandra> I'll update the milestone with these issues we are considering as priority: https://‌github.com/‌w3c/‌dxwg/‌milestone/‌14

LarsG: the inner and outer media types need to be addressed

<SimonCox> ... and I'm afraid there is a new concern around the 'Distributions' issue which I mentioned today https://‌github.com/‌w3c/‌dxwg/‌issues/‌411#issuecomment-432851965

DaveBrowning: services is in yellow because we've done a lot, but the feedback hits on things like perms, rights, and so on, and it needs to be tidied up. I think it is required for the final doc. We are 90% there and we need to complete

<AndreaPerego> About input datasets: https://‌github.com/‌w3c/‌dxwg/‌wiki/‌Provenance-patterns

AndreaPerego: for the input data sets i've drafted in the wiki that needs to be included. I will reshape. There is also the chunk SimonCox drafted in the qualified relations bit
… We need to have evidence that people are using identifiers in the ways we think -
… the point is that identifiers can be identified by a property or by a type
… if we want to get to rec track we need evidence of implementation, and this is an example

danbri: we prefer web URIs and would like to move towards the wikidata approach

SimonCox: The comment before on distributions relates to something I've written recently
… where distributions are informationally equivalent

<danbri> the good thing about Wikidata is that they record the identifying string but also collect the URI templates that map them into URIs, e.g. {'viaf', '1234'} -> https://‌viaf.example.org/‌record/‌1234/

SimonCox: in the link there is a potential solution to a (new) problem that reflects existing practice in a number of data catalogues
… I think it is important and to be inclusive with holders of big catalogues we need to look at incorporate this linking to distributions

<danbri> For Wikidata, https://‌www.wikidata.org/‌wiki/‌Wikidata:Identifiers#Properties_to_store_external_identifiers then there's a link within "A SPARQL query gives all identifier properties with their datatype and class." section.

DaveBrowning: It is good to see real examples, esp time series where a set of data that accumulate over time and is published in chunks and is thought of as one data set. We need to ensure that as we weaken the information equivalence we need to provide guidance for a machine discovering that there

is full information at the dataset level

SimonCox: we need to attend to the different roles a distribution has in relation to a dataset

DaveBrowning: lookng at the non-requirement issues is something I need to do

kcoyle: we need to know what has to be done to know when this version is "done", and then work out how much more time is needed

kcoyle: sorting out schedule, there is a publishing moratorium coming up in Dec 2018, so if we try for mid Jan 2019 for cand rec

kcoyle: Thanks to alejandra and to DaveBrowning for all their hard work in getting to the 2PWD

<AndreaPerego> proposal: great thanks to editors for all work done on DCAT!

<AndreaPerego> +1

+1

<riccardoAlbertoni> +1

<SimonCox> I will go to bed now, will not rejoin the meeting.

Resolved: great thanks to editors for all work done on DCAT!

<AndreaPerego> *\o/*

<SimonCox> I have my next telcon in <6 hours ...

<AndreaPerego> [coffee - back in 30 mins - 15:50 CEST]

Outreach for DCAT

AndreaPerego: we need to sort out how we gather and record implementation evidence
… otherwise we need to find out the demand

kcoyle: I don't know how to prove usage?

AndreaPerego: there is an implementation doc

DaveBrowning: I like the idea, there will be cases where we know where to seek implementation

AndreaPerego: when we pull ideas from e.g. ADMS, can this appear as an implementation?

kcoyle: we can say we learned from it, but probably cannot depend on it as being an implementation

riccardoAlbertoni: in DQV we didn't have to demonstrate adoption.
… as ADMS has been out for some years there is likely to be an implementation. If a term is used in a normative way how do we find examples?

AndreaPerego: There is acceptance across groups with DQV (e.g. by DWBP & SDWBP)

kcoyle: DQV is explained as a good idea, something for people to look at

<antoine> present_

antoine: for DWBP and vocabularies I've run surveys to see the breadth of usage

<Zakim> LarsG, you wanted to ask about uptake vs APs

LarsG: potential issue - people submitting data to portals using older standard
… I've been tweaking our system to have one set of data descriptions to see if our modifications work, and also squeezing this into the DCAT-AP.de. this doubles up workload for publishers
… we need to show at least 2 independent examples of use

<antoine> SKOS implementation report: https://‌www.w3.org/‌2006/‌07/‌SWD/‌SKOS/‌reference/‌20090315/‌implementation.html

AndreaPerego: we can use Makx review - we can use the existing DCAT-AP-XX

https://‌docs.google.com/‌spreadsheets/‌d/‌1WSNx-wKY6oNU3Az-gAPH_IPK__aYT9wIPZcZcezibbs/‌edit?usp=sharing

This link is to an analysis of DCAT-AP species

it might be used to develop some notion of usage of terms, but we need to check if they area *actually* used

<alejandra> the W3C process document: https://‌www.w3.org/‌2018/‌Process-20180201/#Reports

<AndreaPerego> Latest (I think) implementation report of DCAT-AP: https://‌joinup.ec.europa.eu/‌document/‌report-dcat-ap-use

danbri: who exactly is the community - current users or potential users?

kcoyle: can we add these ideas to the spreadsheet

<danbri> for socrata, you could search 'socrata' in Google Dataset Search, and fid https://‌toolbox.google.com/‌datasetsearch/‌search?query=socrata

alejandra: we work with NIH and another data commons pilot from NIH is ongoing, people are interested in schema.org,

AndreaPerego: we can provide various serialisations

we can use rdflib for conversion

AndreaPerego: there are statistics
… against the european data portal

<danbri> Here is a quick python notebook with the two Google examples (Schema.org & DCAT) in N-Triples form, in rdflib: https://‌colab.research.google.com/‌drive/‌1FKoN3HR69vqVN3fVH36E3MRkB7wSXGEt

Action: PWinstanley to coordinate querying European Open Data Portal to estimate current class and property useage to use in assessing confirmation of implementation

<trackbot> Created ACTION-246 - Coordinate querying european open data portal to estimate current class and property useage to use in assessing confirmation of implementation [on Peter Winstanley - due 2018-11-01].

<Zakim> danbri, you wanted to raise two more outreach points: can you help us improve Google's DCAT example to have similar level of expressivity to our Schema.org example? Also https://‌github.com/‌ckan/‌ckanext-dcat

danbri: when doing outreach for datasets we were looking at schema.org and also dcat, and we have promoted a CKAN add-on. Check this for compliance
… second things is RDFa and Drupal. We need a DCAT example t

<danbri> my goal is that the DCAT (=rdfa here) example in https://‌developers.google.com/‌search/‌docs/‌data-types/‌dataset a) works and b) is similarly exprssive to the Schema.org and c) is up to date w.r.t. this WG's current efforts. But can't do without help.

danbri: anyone want to partner with me to do it?

PWinstanley: I offer to help

<danbri> see also https://‌colab.research.google.com/‌drive/‌1FKoN3HR69vqVN3fVH36E3MRkB7wSXGEt for raw materials

Action: PWinstanley to work with danbri on making sure that the DCAT (=rdfa here) example in https://‌developers.google.com/‌search/‌docs/‌data-types/‌dataset a) works and b) is similarly exprssive to the Schema.org and c) is up to date w.r.t. this WG's current efforts.

<trackbot> Created ACTION-247 - Work with danbri on making sure that the dcat (=rdfa here) example in https://‌developers.google.com/‌search/‌docs/‌data-types/‌dataset a) works and b) is similarly exprssive to the schema.org and c) is up to date w.r.t. this wg's current efforts. [on Peter Winstanley - due 2018-11-01].

<alejandra> https://‌www.w3.org/‌2018/‌Process-20180201/#Reports

alejandra: about the process and finding what terms are being used
… I've found the document describing it
… it's not about individual properties but rather seeking for implementation that are relevant for their 'market'

AndreaPerego: for DCAT it could be about vendors replacing some of their stuff with our DCAT elements
… there's are are already DCAT impementation. The different story is for the new elements.

PWinstanley: can we look at continental coverage of our contacts?

kcoyle: if you have other contacts, please put them in the spreadsheet

UCR

kcoyle: we have almost finished discussing all our requirements
… we need an update of the UCR

Jaroslav_Pullmann: working on update wrt profile reqs

<Jaroslav_Pullmann> Start of the updated section: https://‌rawgit.com/‌w3c/‌dxwg/‌ucr_profile_requirements/‌ucr/‌index.html#RPFID

Jaroslav_Pullmann: discusses the content of the doc above
… legacy requirements are still present
… I'm comparing old and new, spotting differences
… things that we could create new requirements from
… the rest is based on Google docs
… I create requirement identifiers
… as the ToC can't use full labels
… At the beginning we had groups of requirements. It's a huge bunch for profiles

kcoyle: we could sub-group them
… then we could reorganize as we did for the list of (very old) requirements

antoine: Jaroslav_Pullmann we could do it together

Jaroslav_Pullmann: we have the problem of several places being sometimes outdated
… we need responsible for the different areas
… we can take it offline
… on DCAT we could look and re-organize the requirements for which we are feature-complete or not.

AndreaPerego: this is a question of whether sthg is in scope or not for DCAT
… we could go out of scope.
… we need example

kcoyle: the question is, whether this is an approved use case
… I don't think we will bring in new use case

Jaroslav_Pullmann: I don't see the need for implementing them, but we could gather them if they are relevant

kcoyle: only for future work.

Jaroslav_Pullmann: I don't know how to proceed for when the coverage of a requirement is not explicit.
… for DCAT the coverage of the rquirement is in-line notes

kcoyle: first we need the UCR document updated
… and then have a discussion with the DCAT group

kcoyle: I don't know when one notes 'unfinished business'

Jaroslav_Pullmann: this is important for the design
… the existing notes will be thrown.

PWinstanley: we should have a basket in the document somewhere, maybe in the wiki, noting this.

Jaroslav_Pullmann: a statement about particular constructs being motivated by the requirement.

DaveBrowning: we've dropped the note
… it is retrievable in the previous versions

<Zakim> AndreaPerego, you wanted to mention that something similar was done in the SDWBP section listing the gaps (what was not addressed): https://‌www.w3.org/‌TR/‌sdw-bp/#conclusions

<AndreaPerego> SDWBP section listing the gaps (what was not addressed): https://‌www.w3.org/‌TR/‌sdw-bp/#conclusions

AndreaPerego: in the BP there is a section with the gaps

https://‌www.w3.org/‌TR/‌2009/‌NOTE-skos-ucr-20090818/#R-IndexingRelationship

<PWinstanley> antoine: I wanted to find out if it was done in SKOS

<PWinstanley> ... there are links in the W3C issue tracker and the final decision

<PWinstanley> ... we need good curation on github

<PWinstanley> ack Jaroslav_Pullmann

Jaroslav_Pullmann: there is an evidence section

PWinstanley: links to and from github issues

DaveBrowning: the ChangeLog could play the role

PWinstanley: Change history
… it goes to the github issues but not the requirements

kcoyle: I think it won't be in the files but our wiki pages remain, we could create a document there.

kcoyle: coming back to the general discussion, I would recommend to remove the old material.

Jaroslav_Pullmann: we need to take care of these which are not covered

kcoyle: if they're not covered, it's because we didn't approve themn
… we've gone through UC and R thoroughly
… we could only have gaps in the UC
… we don't have to update our old doc

Jaroslav_Pullmann: the UCR doc doesn't need a lot of work then.

kcoyle: replace the old stuff and do a bit of organization
… Usually UCR docs are frozen. Our problem is that we passed on profiles requirement and had to come back

Jaroslav_Pullmann: the text should be in there. We need ordering.

antoine: we need one last sanity check, that the re-wordings are all aligned.

AndreaPerego: (new topic)
… a while ago I created an outline

<AndreaPerego> Profile language matrix: https://‌docs.google.com/‌spreadsheets/‌d/‌1Zty4jTzhG0_1xoJlDOMq1XeHelIwVP2-STw6_-_ZxR4/‌edit#gid=0

AndreaPerego: This says what one can do with one language
… It's there, we can complete if it's useful
… It's also a way to say what we mean by 'profile language'

kcoyle: as most of these things are standard, it would be good to have a reference to them in our document.

AndreaPerego: should we add it to the Guidance doc

Action: Antoine to add a reference to https://‌docs.google.com/‌spreadsheets/‌d/‌1Zty4jTzhG0_1xoJlDOMq1XeHelIwVP2-STw6_-_ZxR4/ in the Profile Guidance doc

<trackbot> Created ACTION-248 - Add a reference to https://‌docs.google.com/‌spreadsheets/‌d/‌1zty4jtzhg0_1xojldomq1xeheliwvp2-stw6_-_zxr4/ in the profile guidance doc [on Antoine Isaac - due 2018-11-01].

AndreaPerego: it's very drafty

LarsG: why isn't there a 'Y' on XMLSchema and validation?
… and Schematron?
… and XSLT?

AndreaPerego: adds two 'Y's in the table

<AndreaPerego> [meeting adjourned]