<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)
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]
<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
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]
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
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
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]
Succeeded: s/ofmonths /of months /
Succeeded: s/reqording/rewording/
Succeeded: s/workind/wording/
Succeeded: s/ hange/ change/
Succeeded: s/runtilme/runtime/
Succeeded: s/ https://photos.app.goo.gl/Ji4okxktTpqUUF7A8 is the photo of the post-it notes/..../
Succeeded: s/how to how/how to use/
Succeeded: s/de Hegueret/Le Hégaret/
Succeeded: s/[missed]/We can establish what could/should be in a profile by documenting existing profiles and test profiles using Profiles Ontology - a tast we already have - and then actually implementing the example descriptions
Succeeded: s/tast/test
Succeeded: s/We don't have design pattern/We don't have a design pattern/
Succeeded: s/inside the same file/inside the same file of the voc/
Succeeded: s/some proposals/a proposal/
Succeeded: s/ANnex/Appendix/
Succeeded: s/I don't think it is normative/It isn't normative
Succeeded: s/normo/normative
Succeeded: s/q^/q+/
Succeeded: s/13:50 CEST/15:50 CEST/
Succeeded: s/by DWBP/by DWBP & SDWBP
Succeeded: s/DCAT-AP-DE/DCAT-AP.de/
Succeeded: s/acainst/against/
Succeeded: s/the/there's a/
Succeeded: s/then/tehm
Succeeded: s/tehm/them
Succeeded 11 times: s/karen: /kcoyle: /g
Succeeded: s/what can do/what one can do/
Succeeded: s/q¨/q+/