– DRAFT –
DXWG Plenary

<roba> * is it webex or me this morning?

<ncar> must be you roba!

kcoyle: Start by looking at the minutes for last week

Admin

<kcoyle> https://‌www.w3.org/‌2018/‌07/‌24-dxwg-minutes

kcoyle: Looking at actions and resolutions, always extensive. Antoine types really well.
… Two actions for Nick, we'll get to those. Resolutions for three requirements.
… Very productive meeting.

<kcoyle> PROPOSED: accept minutes of last meeting

+1

<annette_g> +1

<kcoyle> +1

<antoine> +1

<PWinstanley_> +1

<Ixchel> +1

<roba> +1

<Jaroslav_Pullmann> +1

Resolved: accept minutes of last meeting

<ncar> +1

kcoyle: Okay, done that. Next is to look at the list of open actions.

Open Action Items

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

kcoyle: Let's see if we have any to mark off.
… Won't go through DCAT ones, assume we'll do them in the DCAT meeting. One on Dave for the github dump.
… Dave ... is not on Webex.
… Nicholas has to establish a meeting (#148), which is in progress

ncar: That's right. Likely in the other time slot than conneg.

kcoyle: Suggested that you pick another timeslot for Australia and CET, might want to look at that.
… adding in west coast time makes it hard. See if there's something that works, as I'll be in CET in fall.

ncar: Will wait another half day for interest.
… only 10 hours difference, but this 6am slot does suit some of us here. Will put the inverse to the group and see if there's interest

kcoyle: What we've seen so far is 10pm in CET more than once a week is starting to provide stress. Lars can do one but not both.
… think we might be able to get more participation. There aren't many of us in the California timezone
… checked with Rob and Annette. Neither intended to be part of the group, so just me.
… don't want to make things more difficult

ncar: two of three timezones is easier.

kcoyle: 3 of 3 is hellish!
… update profiledesc documentation, and following that, work on some potential outlines
… I looked at the profileDesc docs, hasn't been done?

ncar: Thanks for hte prompting. Will try and do that today.

kcoyle: DOn't think we can do too much, have to get some consensus around the ontology before we can go very far
… it informs the nature of the guidance document.
… Sooner the better. That seems to be all of the actions that are likely to be discussed. Let's move on.
… Anyone able to update us on DCAT?

Updates

SUBTOPIC: DCAT

kcoyle: Anyone attend the mtg?

Jaroslav_Pullmann: Reference to projects with context of providing a dataset.
… One of the aspects that got discussed. The provenance of datasets, per project. Simon presented project ontology.
… all monitored in the meeting notes

roba: A little addendum. Discussion about specialized properties or qualified forms for describing things.
… Short term consensus around specialized properties for various types of relationships, but not fully resolved

kcoyle: Thanks, that's a hard one!

SUBTOPIC: Profile Guidance Group

kcoyle: Looking for a time, need documentation.

antoine: Maybe you were going to discuss about hte outline you proposed.
… Have a little question about how to discuss and make suggestions. Put that on the general mailing list, will go back to GH
… you said to suggest a new outline, but will make the thread on GH really long
… a small suggestion, can you just change the outline?
… easier to follow.

kcoyle: Yes, let me post what we're talking about

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌issues/‌242#issuecomment-408916364

kcoyle: GH is not the greatest place for comments on documents. You can't do what you can in google docs.
… don't know how we want to look at different suggestions and talk about them
… this particular one I posted is very similar, could pull them out and put them side by side, but this instead of breaking up between what is a profile and profile descriptions, it folds a lot into an administrative metadata section
… so you what is a profile, and then a number of chapters about the profile

roba: In terms of the way forward, I think we should follow standard practice. It's helpful to get a scope, and then we can discuss it and commit the first draft to GH
… then deal with it in terms of people submitting PRs to the draft
… hopefully in the normal way, with discussion, actions, people can propose improvements ... let's not put another system in place.

kcoyle: I agree
… we have 3 or 4 suggestions in the thread

antoine: A question to Rob -- are you suggesting to have commit suggestions, or have them in an issue?

roba: Too early in the morning :) If you have something that needs to be thrashed out, then we have an issue
… if there's a suggestion, then just put in a PR with a comment.
… If there's a significant decision point, then issues are the way to do it

kcoyle: Okay, anyone else?

<antoine> ok we could try

*tumbleweed*

... Anyone here in the profile negotiation group

... any comments?

ncar: Rob A, Rob S and I are all there, we just haven't met ... so nothing to report
… administratively, we have the new timeslot, this hour plus 24 hours
… every two weeks, starting tomorrow

kcoyle: Okay great!
… I assume UCR document is same status?

SUBTOPIC: UCR document

kcoyle: ?

roba: Jaro offered to look at a PR as an alternative

Jaroslav_Pullmann: Thank you. I looked at it, it amde sense, so I accepted and merged

<roba> +1

Jaroslav_Pullmann: Don't know how to proceed with UCR docs, I'm approaching holidays in August. How to incorporate requirements into UCR doc.
… how urgent is this? Tasks to be done in the next days, or is end of August okay?

<roba> if we get consensus on text i can edit in - there is a lot of deduplication to do again

kcoyle: Don't see anything urgent. Easier to refer to when it's all together, but we have this messy google doc to use in the mean time
… don't see any urgency
… there are some sort of black out times for documents coming up related to vacations of W3C, and TPAC.
… but that's only for new documents or new FPWDs. Update process doesn't need to go through that

PWinstanley_: We're due for a couple of FPWDs in Q4. Need to keep an eye on our schedule.

kcoyle: Are you reading Q4 as the beginning, middle, end... ?

PWinstanley_: October to December. Given a F2F coming up, we should be close to publication or potentially on the cusp of it

TPAC

kcoyle: Meeting is 24th of October, on the meetings page. Can use that time to finalize whether the docs are ready to go out or not

<PWinstanley_> https://‌www.w3.org/‌2018/‌10/‌TPAC/#WeekGlance

kcoyle: Alejandra signed up and noted the expense compared to non TPAC meetings
… assumed that TPAC would be a good time to meet. Didn't realize that it's quite a bit more expensive. Ends up being 110 euros a day
… don't know if that is going to stop anyone from attending
… in the future I won't assume we'll meet at TPAC, especially as the next one is in Japan
… Can begin to think soon about inexpensive place to meet for F2F after October
… early 2019 if someone has space to offer, that would be great
… if you're planning to attend, the cheapest rate you should sign up

PWinstanley_: If you're an IE, and not at a member organization, then there's a fee waiving scheme
… not sure if Alejandra for example is in a member institution

<Zakim> azaroth, you wanted to talk about TPAC

<PWinstanley_> azaroth: to say that while TPAC is expensive to get to and attend, it is valuable for cross-WG discussions

<PWinstanley_> ... there is scope for meetings between e.g. JSON/LD group and the profiles subgroup

kcoyle: Makes me also think, are there cross-group discussions we need to set aside time for?

antoine: A message to send to W3C. I agree with Rob -- every additional day costs 110 euro, makes it quite difficult.

<PWinstanley_> +1 to azaroth

antoine: if one wants to attend groups other than the ones we're involved in, it gets very expensive

kcoyle: Let's turn to requirements
… the ones we have left on the list, there's also some use cases, but hope the requirements let us work on the guidance document...

<kcoyle> 12.6 Requirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation.

kcoyle: will start with the Europeana requirements
… what comments on this?

Jaroslav_Pullmann: Comment from previous discussion... still agreement to meet at TPAC. Rates are changing this evening.

kcoyle: Today is last possible day for lowest rate

roba: Wanted to vote in favor of the requirement. Haven't written up use cases for OGC, but we have profiles in schematron.
… not very expressive but appropriate for an XML based standard. We have that constraint being partial description of the profile

+1 from me for the requirement

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

<kcoyle> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌ProfileRoundup

kcoyle: Understand that Europeana also uses schematron. We added this to the profile roundup page
… it is at the beginning list of types of languages and tools
… schematron definitely on there
… within our task is to look around and have a good list of the more mainstream tools
… in terms of actionable profiles

roba: The proposed requirement doesn't talk about specific languages, it's an interesting one, different langauges have different expressivity, and that's the nature of it
… the second point is whether there's a requirement to specify the language, and if there's a canonical list of those languages
… can we have URIs for the languages, to say what it's written in? might be a requirement?

kcoyle: Are there languages that do not self identify?

roba: Is there an identifier to reference the language itself by?

kcoyle: Not talking about hte document, but is there a property to say it's written in a language external to the doc. Meta-metadata

roba: Is it a requirement to discover the language the constraint is written in, without reading the constraint doc?

kcoyle: Don't see it.

roba: Don't see it explicitly mentioned anywhere

annette_g: I think it should be in there some where
… I have a niggle with it, it reads more like a solution than a requirement. There's an underlying requirement that I'd like to see it written as
… have to have a way to figure out the language is closer to an actual requirement

kcoyle: How would you like it to be worded?

annette_g: ... I'd need to look at the use case more carefully
… Not sure the best way, I think we're just missing things here.
… do we need to accept all possible schemas? Do we narrow it at all?
… this is deciding a solution before understanding the real requirements

kcoyle: Is there the assumption that we would be not leaving this wide open, that people could do this if they want, but that we provide more guidance as to acceptable languages?

kcoyle: Do people understand the question?

antoine: Also in favor of not closing the set of languages. Want to represent that by ... in the requirement
… if that's not open enough, then happy to reformulate to say the list is not closed.
… second point about what rob said on making a requirement for assigning URIs to languages, I'm in favor of it, but it could be a derived need from the requirement.
… the requiremnt says that profiles are impelmented in schema languages, and profiles should be in profile desc, then profile desc needs enough information, which would include the language identifiers

roba: Didnt' see it as prescriptive, but in the real world, they're not perfect. Need to have a requirement that it is allowed
… do have a situation where the language needs to be able to be identified, without necessarily grabbing every possible one down to look at
… don't think we should specify that it has to be a URI, that seems like a solution
… could be a specialized property instead, e.g. shaclConstraint
… not very nice, but a possible one. Requirement is that we support partial constraints. Profound implication -- the profile is different from the constraints
… the shacl doc would not BE the profile, but a partial expression OF it
… this drives the profileDesc design to separate these out

<Zakim> azaroth, you wanted to be -1 on preselecting languages

roba: didn't read it as prescriptive so happy

<antoine> azaroth: preselecting languages seem very closed world and not very future-proof

annette_g: I didn't read the list as prescriptive, comment as to open or not is a solution question rather than a requirement
… just trying to get at what the requirement is. I think it's that we want to support existing expressions with as little change as possible
… this is more complex than just saying it's a requirement, we've had some discussions around modularity and inheritance, that we haven't figured out how it will be dealt with
… might be things we need to express things that aren't possible in various languages
… could be just the file extension, but it merits some thought

kcoyle: What do you suggest we do with the requirement?

annette_g: Turn it into something that says that our guidance is as friendly as possible to existing languages

kcoyle: Could also be future?

annette_g: true. Use case is that people have already implemented?

kcoyle: Might be that there's languages that haven't been used yet. DOnt' want to support only existing ones.

annette_g: Support existing and others that are likely to be used

kcoyle: Don't think we know what's likely to be used, which is why it's open
… can we vote on it, and then add rewordings to the google doc? Acceptable?

<kcoyle> PROPOSED: accept Requirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validationRequirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation

+1

<kcoyle> +1

<Jaroslav_Pullmann> +1

<antoine> +1 (for half of it)

<annette_g> 0

<roba> +1

<DaveBrowning> +1

<PWinstanley_> +1

Resolved: Requirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation

kcoyle: I think anyone can suggest rewordings.
… Okay. Can we do the next one?
… number 127

<kcoyle> 12.7 Requirement: data publishers may publish data according to different profiles, either simultaneously (in one same data "distribution") or in parallel (via content negotiation).

kcoyle: Comments on this?

+1 to this :)

kcoyle: The direction that conneg is working in

annette_g: We're specifying that using a distribution or conneg, is that necessary for the requirement?

Jaroslav_Pullmann: I could imagine conneg as related to data services

<roba> dct:conformsTo

Jaroslav_Pullmann: where dynamic data is being retrieved, otherwise the distributions are set. How are profiles indivcated? Do we have a predicate for this already?

<annette_g> suggested rewording: Requirement: data publishers may publish data according to different profiles.

roba: A profile is a specification, so dct:conformsTo

;)

<Zakim> azaroth, you wanted to be in favor of examples

<annette_g> maybe add "e.g."?

<roba> I read as examples - may make this more explicit

<antoine> annette_g++

PWinstanley: slightly similar thing with DCAT stuff, a bag of assorted datasets thrown in to a specification. sometimes you have the same data in JSON and XML, stuff like that
… want to keep an eye on both

+1 to e.g.

kcoyle: I've added e.g. inside the parentheses. I'll copy it from what Antoine has given

<kcoyle> PROPOSED: accept 12.7 Requirement: data publishers may publish data according to different profiles, either simultaneously (e.g. in one same data "distribution") or in parallel (e.g. via content negotiation).

+1

<annette_g> +1

<antoine> +1

<DaveBrowning> +1

<PWinstanley> +1

<roba> +1

<Jaroslav_Pullmann> +1

<kcoyle> +1

<kcoyle> RESOLVED accept 12.7 Requirement: data publishers may publish data according to different profiles, either simultaneously (e.g. in one same data "distribution") or in parallel (e.g. via content negotiation).

kcoyle: expletives ... Rob go ahead

<kcoyle> RESOLVED accept 12.7 Requirement: data publishers may publish data according to different profiles, either simultaneously (e.g. in one same data "distribution") or in parallel (e.g. via content negotiation).

roba: A comment for editing ... publishers may do this, we can't stop them. We just need to accept that this is happening. The requirement we can do something about is that there's a way to identify which profiles are being published
… a requirement to recognize reality, not to do something about it.

+1 to roba

kcoyle: I think we've gone beyond the myth that we have control over things :)
… Gone through the numbered ones. Another one I can't quite paste in ...

<kcoyle> It should also be possible to derive requirement in terms of description of profiles vs their implementations/schemas and how all this should be served.

antoine: I can save Karen the effort ... it was more like a note to say that from our use case, I can derive requirements as to what profiles can express in terms of data constraints
… the specific expressivity in a profile. I've not done that as I saw that we already had requirements about this.
… Don't know if they're complete or if it's desirable to seek such completeness. Question to the group - should I go back to the use case and add to the expressivity requirements?

kcoyle: We have some expressivity requirements

antoine: we have several, and the most important ones
… I was referring to the work done in the DC community in the WG that karen and I co-chaired where we identified a couple dozen possible things that can be expressed in a prfile
… it was whether we should go that route, or if we should stay at a high level
… and focus on the most important parts, leaving open what could be expressed in a profile

<kcoyle> https://‌github.com/‌dcmi/‌repository/‌blob/‌master/‌mediawiki_wiki/‌RDF_Application_Profiles/‌Requirements.md

kcoyle: [unscribable]
… we can look at this as the group starts work. Other ideas will come up as the document takes form. Can bring it back to he plenary if there's things beyond the requirements
… does that seem okay?

<antoine> +1

+1

kcoyle: We have the DC information there, there may be some others. We have the ODRL profiles to look at.
… I thnk as this document comes together we'll be going back to examples to see if there's anything we missed
… if the group is okay to work that way

roba: agree to that. need to be high level and recognize that there's different tpes of profiles
… what's common is the way that they deal with interoperability and data exchange
… the ability to support them in a more coherent way than word docs scattered around the web is what we're looking to achieve

kcoyle: Yup! We'll set this one aside, not an actual requirement. We have the information in our list of documents, so can get back to it
… thank you to Rob S for scribing, thanks to all for being here, will talk again next week

<roba> * go antoine!

kcoyle: Peter and I will chat to see what we want to cover.
… would like to talk about profile description documentation
… ahve gone through most of the requirements

<annette_g> bye all!

Thanks all!

<PWinstanley> bye!