PROPOSED accept minutes https://www.w3.org/2019/06/25-dxwg-minutes
<DaveBrowning> 0 (not there)
<annette_g> I regretted
RESOLVED approve minutes https://www.w3.org/2019/06/25-dxwg-minutes
Peter: Will skip ACTIONs of specific working groups.
… want to double-check re: DCAT that we are good for a meeting with Philippe on the 15th
… sub-group has not met for awhile
… an interesting discussion about "represents" - would like people here to pitch in
… Dave, Alejandra - are we good to go - to confirm with Philippe?
Alejandra: We discussed having a pre-meeting first. Some are not available tomorrow.
… So would be good to have at least one DCAT sub-group meeting to discuss feedback.
Peter: Should I push back - after 15th?
Alejandra: Depends on this meeting tomorrow.
Peter: Meeting on the 10th?
Alejandra: In sub-group can discuss if 10th is good.
Riccardo: Meeting next week is good. I am available tomorrow. Wonder about goal of meeting with Philippe.
Peter: Make sure ducks are in row for pushing to Rec.
<DaveBrowning> +1 on having a meeting to get our act together (on 10th).
<AndreaPerego> +1 from me to have a meeting on the 10th
Peter: He said it would take at least four weeks - and info on implementation only needed at end.
Riccardo: We are receiving alot of feedback - cannot say - depends how it goes.
… Any strong request for having CR before August - or need to discuss?
Peter: Will discuss together.
Alejandra: Qst about. We are getting feedback - great. Give more time, or some time assumed after which no need to wait?
Peter: Given that we have feedback, must triage - would anything make a normative change?
… Or editorial? If so, he is happy for us to deal with it while going thru CR process.
… So need to see if any show-stoppers. If not, handle during CR process.
Peter: Discussion on "represents" in https://github.com/w3c/dxwg/issues/966 ?
… A bit loaded, like "profile".
… Anyone up for that?
<annette_g> I haven't had a chance to read the thread
Tom: Gist of that thread?
Peter: Term "represents" has different meanings. DCAT resource "represents" - used alot - like "it's a profile of"
<Zakim> DaveBrowning, you wanted to check on DCAT meeting suggestion status
Peter: Conversation about "is a". "Denote" vs "represent" vs "describe", when metadata records are surrogates.
Dave: Re: DCAT subgroup meeting - consensus that those interested should get together next week to review status of incoming comments?
… GH commits have been straightforward.
Riccardo: Try to work with GH - check situation next week.
Peter: Re: 966, people closely involved - but helpful to get "naive readers" to flag areas of possible confusion.
… Also, people in DCAT group are mainly in data domain, and as we have discussed: vision is publn of catalogs on Web.
… Important in editorial polishing: remove ambiguities.
Peter: Two aspects: use of term "profile" as applied to our documents.
… We have three horses in the race.
… There were votes. Tom's horse appears to be winning: five votes. Karen. Antoine.
Antoine: Several comments on GH about latest version of Tom's definition.
… First would like agreement on fundamental principle that I can live with.
… Agree there should be two definitions.
… Other comments later.
<antoine> TomB: yes I was wondering about that
<antoine> ... it would be good if we have two definitions
<PWinstanley> TomB: responding to antoine - I was wondering also about 2 definitions, happy with that. We may want ways of distinguishing them - data profile and something else
Karen: Qst for Antoine: what are the two?
Antoine: One would represent something not necessarily based on another specification.
… The other would always be based on something.
… Idea to split our current definition. Based on, or not based on.
<PWinstanley> TomB: my understanding is that antoine has been highlighting the role of data profiling and JSON/LD profiles, neither of which are based on other specs - they are self-contained and it represents a significant other usage model, whereas DCAT types had a relationship with a base specification
Antoine: Our current definition can be uncoupled from qst whether based on something else.
Peter: Antoine, can these provide the basis for a Type 2 profile?
Peter: So situation similar to others? Can first form (JSON-LD, etc) - self-contained - can they be referenced by other profiles as base specification?
… If that were the case, similar to UNCFACT or specs where you have basic and aggregate business information entities.
… Coming back to taxonomies and profiles in other areas?
Antoine: I would not call the relation that of aggregation - rather derivation. But similar pattern.
<kcoyle> "derivation" is a good term!
Antoine: Want to remind: one argument for having the "basic" type - keen on having because already there in DCAT and CONNEG - it is already one thing that datasets can conform to - and that one can use for content negotiation.
… We should probably be careful not to say more than DCAT about these concepts.
<kcoyle> I would appreciate an email that clarifies these two things
Annette: When we first started, JSON-LD seemed like such a different thing that it would be confusing. Leaning to _not_ include JSON-LD in definition.
Peter: How would we distinguish?
Annette: JSON-LD is about media types and we are not about media types.
Antoine: Annette is right. JSON-LD profiles are indeed quite different. In fact not exactly about media types.
… Still about forms of data that are not the same sort of profiling. We should distinguish.
Peter: But distinction btw self-contained and those that have dependencies or derivations - merit in having that?
Antoine: Has nothing to do with JSON-LD notion.
Karen: Getting confused. Would like if someone could write up email clarifying what these are. Not sure what "self-contained profile" is.
<annette_g> Maybe we disagree on the Venn diagram: (specs (profiles)) or (profiles (specs))
Antoine: Peter, do you think this is useful? Understand why Karen is puzzled. Would like definition of something that may or may not be self-contained. Not focus too much on things that are self-contained.
Peter: Definition of profile for CONNEG document. Can we agree on one or two?
<antoine> annette_g I think it is (specs (profiles))
Peter: Or if we are going too deep into rabbit hole - we need to be pulled back: get something "good enough" for job at hand.
… As for voting: Karen was providing a few options that people could vote on - extend this a little but not too much.
… Sometimes we meander in these discussions, circle around.
… Has an effect on membership. Rob standing back until decided. Need something "good enough" - quickly.
<Zakim> TomB, you wanted to ask if if this has to do with usage of "profile" by JSON-LD community?
<PWinstanley> TomB: I was on a call recently - ultimately we need definitions that are intelligible for the average reader. In the JSON/LD there is a group mentioning profiles, and in wikidata there is another group. They are talking about profiles that are not based on other specs, so we need to say this but in a way that people who are not within these groups can understand
<kcoyle> There may be more than 2 types of profiles - I'd say there are "various" and we can talk about some but not be exhaustive
<PWinstanley> ... we need to formulate definitions clearly
Antoine: When we talk about two levels - my original mail from one week ago. Annette made the point that she is reluctant to call something not derived a "profile".
… Annette, are you comfortable?
Annette: Haven't fully grokked distinction.
Antoine: But your answer was insightful!
… I have identified two levels and tried to provide a definition that captured both.
… You said: if not based on something else, it is a specification.
Annette: Two separate things - two separate terms.
<PWinstanley> TomB: anyone have ideas on names? Data Profile and A N Other Profile?
<annette_g> specification and profile
<kcoyle> I like specification v profile
<kcoyle> this is why I'm confused!
<PWinstanley> TomB: the JSON/LD use case - if we are calling it a profile then what sort is it?
<PWinstanley> ... I don't have an answer at the moment
<PWinstanley> ... If we can just say that there is a significant CoP that has profiles about data (e.g. JSON/LD) and explain what is meant by profile in their context that would be enough, but we need a nomenclature
Annette: Not sure we want to address the JSON-LD thing - a "media-type profile"? A different type entirely.
Peter: Might be helpful even for the JSON-LD community - they will have the same confusion. Maybe we just need to make the statement.
Annette: Make clear that we are not talking about that.
Peter: What Tom was saying: smart readers "in the street" need to be able to grok these documents.
… Because everyone impacted.
Annette: Totally agree re: understand. Feel like we are arguing about terms that are pretty well understood.
Peter: If it needs to be separated, with different handles....
Antoine: We will not nail all of the ambiguities, but with JSON-LD we are not in a bad situation because "profile" parameter now refers, in the spec, to something they call "forms".
… Forms are more syntactic than what we are interested in.
Peter: Work out what to do over next week?
… Need to have clarity on what to put into CONNEG. We have three horses. Antoine has a fourth horse, with three heads :-) Helpful if we can all work on this idea of being a small collection of profile types, readily identifiable.
… Need handle for each. Something brief that characterizes each.
Antoine: I thought we were down to two.
Peter: We need to recognize that there are profiles we are not talking about - but we need to acknowledge them and guide them to the types we want to talk about.
<kcoyle> +1 to define in a way that one can recognize what we are talking about
Peter: Given the others a name and a short characterization.
Antoine: "Things that are not profile" for us.
… Things we are not trying to touch.
… If we put that into GH and have another round of voting and discussion - should be close to sewing up within 7-10 days?
<kcoyle> +1 to different github issue
Action: Antoine to start a fresh GH issue.
<trackbot> Created ACTION-342 - Start a fresh gh issue. [on Antoine Isaac - due 2019-07-09].
<riccardoAlbertoni> thanks, bye !!
<alejandra> thanks all, bye
Peter: We are making progress! Thanks for contributions. Same time next week!
Maybe present: Annette, Dave, Karen, Peter, Riccardo, Tom