See also: IRC log
<Yaso> OMG
<Yaso> Ok, just give me 3 min to webex + firefox setup :-)
<phila> last week's minutes
<phila> PROPOSED: Accept last week's minutes http://www.w3.org/2016/01/22-dwbp-minutes
<newton> +1
<phila> +0 (absent)
<Caroline> +1
<antoine> +1
<annette_g> +1
<RiccardoAlbertoni> +1
<PWinstanley> what is the password for webex
RESOLUTION: Accept last week's minutes http://www.w3.org/2016/01/22-dwbp-minutes
<phila> scribe: PWinstanley
<Yaso> https://www.w3.org/2013/dwbp/wiki/Meetings:Telecon20160129
Yaso: Agend for today is:
... issues for DQV
<RiccardoAlbertoni> yes,
Yaso: ricacardo is talkingabout
<phila> issue-190?
<trackbot> issue-190 -- "official" DQV reqs vs the implementation of our best practices (cf. the "5 stars" thread). -- open
<trackbot> http://www.w3.org/2013/dwbp/track/issues/190
RiccardoAlbertoni: issue
190
... talking about requirements for DQV, issues which are not
technical and of interest to the whole group
<antoine> https://www.w3.org/2013/dwbp/wiki/Data_quality_schedule
antoine: we can start with 190 and kill 179 once oand for all, then talk about the issues as ordered on the data quality schedule
RiccardoAlbertoni: starting with
190
... the point of 190 is trying to understand the requirements
we should consider in the data quality model; should we limit
the property of data that are intrinsic, or extrinsic
... we are already considering extrinsic (e,g,
accessibility)
... and also there is an example of DQV in which we state the
standards compliance of the metadata
... if we include all the dimensions then they are
extendible.
... Is there anything missing, or can we close 190?
antoine: I would like to add - would people expect DQV to be comprehensive?
phila: when reading the tracker I
understood it as saying can we include features not demanded by
the requirements. I think this is OK, there are obvious
assumptions that people make
... sticking only to requirements would be unnessarily
restrictive
... In addition, would the DQV as it stands be sufficient to
describe the dataset as an official dataset
RiccardoAlbertoni: I need clarification
<annette_g> what is a "company register"?
<phila> SEC register annette_g
phila: in a company register, an official dataset, then there are elements that can be aliased, but underlying that alias is an authoritative source that might be a legal name
RiccardoAlbertoni: I think this is more connected with the authority of the dataset
<laufer> Are you talking about things like certificates, phil?
<phila> No, authoritative datasets, like a land registry (who owns what), citizens register, social security numbers etc.
<laufer> I think that dqv is not a certificate... It can append certificates but dqv itself is not a certificate...
<RiccardoAlbertoni> +1 antoine
<antoine> Antoine said that if someone expresses the authority aspects as a sort of certificate then it is possible to express it in DQV
<phila> scribe: phila
annette_g: I think it's about the source
<antoine> phila: one org could produce datasets of different kinds
<antoine> ... no all datasets are authoritative
<antoine> annette: good point
<antoine> phila: the fact that we don't have a specific requirement doesn't mean we can't do more
<laufer> I think that dqv cannot transform the semantic of what is being described...
<scribe> scribe: phila
PROPOSED: Close Issue-190
RiccardoAlbertoni: If Antoine
agrees?
... No new use cases that we haven't considered yet
antoine: I think the resolution could be that we have new use cases but we';re not forced to do it
PROPSOED: We can handle new use cases but we're not forced to (for DQV)
PROPOSED: We can handle new use cases but we're not forced to (for DQV)
+1
<antoine> +1
<annette_g> +1
<Yaso> +1
<RiccardoAlbertoni> +1
<laufer> +1
<newton> +1
RESOLUTION: We can handle new use cases but we're not forced to (for DQV)
close issue-190
<trackbot> Closed issue-190.
<EricKauz> +1
<Caroline> +1
issue-179?
<trackbot> issue-179 -- The Working Group is considering to put all new classes and properties (together with the ones of the Data Usage Vocabulary) in the DCAT namespace. -- closed
<trackbot> http://www.w3.org/2013/dwbp/track/issues/179
antoine: We agreed that we can
put all our new classes and properties in our own (dqv)
namespace, not use dcat namespace
... Eric S pointed to previous discussion. So I think the
matter for today is to keep Issue-179 closed but say that the
resolution is that we have separate namespaces for DUV and
DQV
Yaso: So we're just re-enforcing what we agreed at the SP F2F
<antoine> http://lists.w3.org/Archives/Public/public-dwbp-wg/2016Jan/0055.html
PROPOSED: That we have agreed that DUV and DQV will use their own namespaces, not using each other's or DCAT
Yaso: We don't need to vote
... we have already agreed it and the mailing list shows
this.
No one makes any noise - taken as consensus
RiccardoAlbertoni: Other 2 issues
are issue-204 and issue-205
... They are a little technical
<Yaso> https://www.w3.org/2013/dwbp/track/issues/205
<Yaso> https://www.w3.org/2013/dwbp/track/issues/204
issue-2014?
<trackbot> Sorry, but issue-2014 does not exist.
issue-205?
<trackbot> issue-205 -- Representing dimensions and categories SKOS Concepts -- open
<trackbot> http://www.w3.org/2013/dwbp/track/issues/205
phila: I went through the mails
RiccardoAlbertoni: It seems there
are no objections for the solution C that tries to move the
heirarchy of the dimension and category classes made as sub
classes of skos:Concept
... Jeremy D wrote to the list just before this meeting but it
seems he's open to adding the classesd category and dimension
and metrics as sub classes of skos:Concept.
... So we havea some buy in.
... What do you think Antoine. Can we close at least one of the
two?
antoine: not right now. We probably need to get back to Jeremy and discuss a little further.
RiccardoAlbertoni: I don't think Jeremy is available for the next two weeks at least and we need to makae progress.
antoine: I'd prefer to close the issue with a clear suggestion of wording.
RiccardoAlbertoni: So we go on writing the section and show the relationships, in the way we have agreed and then close the issue once JD has provided his feedback
phila: +1 to RiccardoAlbertoni
<gatemezi> +1 to RiccardoAlbertoni
laufer: The DAQ vocab - will our
DQV have an alignment with respect to this issue?
... of the Category class
RiccardoAlbertoni: I;m not sure I understand. Are you asking about other vocabs that are asking this way of using SKOS?
laufer: I think we have some influence of the other vocab that is DAQ. The problem with the abstract class like category - they use that. What will be the alignment?
RiccardoAlbertoni: My impression
is that... what I was trying to discuss in the e-mail is that
basically if we go for solution C, we have no incompatibility
with the DAQ
... or at least the heirarchy descibed by Jeremy can be
included.
... The only way that we can have a clear statement is to
implement and see if any incompatibilities arise.
... it's not really clear if I;m wrong or niot
<Zakim> phila, you wanted to ask about SPARQL CONSTRUCT
phila: Can you write a SPARQL CONSTRUCT from DAQ to DQV for this?
RiccardoAlbertoni: Yes.
phila: Then I suggest you include that query in the document
RiccardoAlbertoni: It can probably be done without SPARQL but if we need it, we'll add it
Yaso: So I ask Newton or Carol is they have any specific issues to raise?
newton: We have these 2 issues we want to atlk about today.
<newton> issue-227?
<trackbot> issue-227 -- The document has three different indexes for the BP: by challenges, by benefits and the summary. Should we keep the three of them? -- open
<trackbot> http://www.w3.org/2013/dwbp/track/issues/227
issue-227?
<trackbot> issue-227 -- The document has three different indexes for the BP: by challenges, by benefits and the summary. Should we keep the three of them? -- open
<trackbot> http://www.w3.org/2013/dwbp/track/issues/227
newton: I think this was raised just before the publication of the last draft. Can we decide whether to keep one, 2 or three indexes
annette_g: I think it's fine to have multiple indexes, but I don't want them in the front. I'd vote for chosing one for the top, the shortest one, and put the otyhers ones at the bottom.
newton: Which one would you keep at the top? The BP Summary (auto generated list)
phila: +1 to annette_g
... Which ones do people find most useful?
newton: Actually, we don't have
this feedback
... Does the group have suggestions. For me, the challenges are
useful.
laufer: I think the first one is the one that lists all the BPs like an index. I think it's important for the next iteration is to clarify that we have multiple indexes and say what is the difference between them
<Caroline> +1 to laufer suggestion
laufer: then the use can choose
which one they want to use.
... What is the funstion of each index.
annette_g: Persoally I know I ue the summary one the most.
<gatemezi> I also like the challenges view
<Yaso> +1 to newton
Yaso: The summary is useful - the
auto generated list. maybe we put the other two at the
bottom.
... I think I agree with you.
<Caroline> +1 to newton's suggestion
laufer: I think that we have
differnet levels of users. Even within us, the 1st time you use
the doc you do it one way. Come back and you see it a different
way.
... The first time user might use a more visual method. Second
time, it's the list
<annette_g> +1 to Laufer
<RiccardoAlbertoni> I agree with laufer
laufer: I think we have the summary, and the corss refers. I think the latter go at the bottom
Caroline: I was going to ask whether Annette agrees - and she does.
<Yaso> +1
newton: So should those otehr indexes go after the glossary? Before?
Yaso: I'd say after
<annette_g> +1 for after the glossary
phila: Up to the editors I think on that one
<Caroline> ok
newton: OK, thank you.
PROPOSED: keep the auto generated summary where it is, but explain the other two indices and move them to lower down the doc, after the glossary
<Yaso> +1
<gatemezi> +1
<newton> +1
<Caroline> +1
<RiccardoAlbertoni> +1
<laufer> +1
RESOLUTION: keep the auto generated summary where it is, but explain the other two indices and move them to lower down the doc, after the glossary
<annette_g> +1
close issue-227
<trackbot> Closed issue-227.
<newton> ISSUE-20
<trackbot> ISSUE-20 -- Review use cases organization - change the order -- closed
<trackbot> http://www.w3.org/2013/dwbp/track/issues/20
<newton> 220
issue-220
<trackbot> issue-220 -- Should we include a more complexe example to illustrate provenance? -- open
<trackbot> http://www.w3.org/2013/dwbp/track/issues/220
newton: With the help of the group... we use a very basic example of provenance for that BP. Does the WG have a suggestion for a more complex example?
<gatemezi> I'd say there are more complex examples in the PROV Rec docs
newton: And should we include those complex examples? OR point to PROV?
phila: The DUV has some provenance examples.
<gatemezi> I'd suggest to put some basic examples and point to PROV for more complicated one
<laufer> I prefer simple examples and pointers to PROV
newton: OK, we'll keep this open for now
Caroline: Yes, we do need a lot
of help. WE're planning to give people specific tasks,
e-mailing people and making a tablke with the tasks so that we
can follow up
... We'll try and do that by next week. If someone sees
something they can help with before then, so much the
better.
(this after phila going on about 6 weeks to Zagreb and deadlines)
newton: We have the open issues
around APIs and all that ;-)
... It would be good to close that discussion.
Yaso: I think we should takae the
suggestion of addressing named individuals on that one.
... So I expect an e-mail from you.
<Yaso> https://www.w3.org/2013/dwbp/wiki/ZagrebF2F
Yaso: Please update the info
whetehr you're attending
... Phil made this page. We need info about participation, how,
whether you can get to Zagreb, can you attend remotely if
not
... So I think we're done for the meeting today
... thank you for calling in.
<laufer> bye all... nice wknd...
Yaso: Bye all
<RiccardoAlbertoni> thanks all Bye
<Yaso> Bye!
<annette_g> bye!
<gatemezi> Bye!