See also: IRC log
<trackbot> Date: 28 January 2015
@scribenick danbri
<trackbot> Meeting: CSV on the Web Working Group Teleconference
<trackbot> Date: 28 January 2015
<JeniT> ScribeNick: danbri
noting https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0043.html from Wim to discuss later
jenit: let's go through the list of issues that gregg highlighted, ie. https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html
<jtandy> (apologies - very limited work from me this week)
jenit: I went through this earlier, can we start w/ #80 ?
… unless otherwise let's assume closed #43, 76, 77, 78
<ivan> https://github.com/w3c/csvw/issues/80
jenit: #80 is re json-ld context's contents.
suggests resolution is an array of strings followed by an object
jenit: seems fine but suggest could just be string not required to have an empty object
<- jenit can you double check i got that right?
<gkellogg> Looking at audio settings
gkellogg.volume(7)
gkellogg: there are 3 possibilities, … there is string, a specific ref to our ns. 2nd: an array of string followed by an object. 3rd: just an object, ns is implied.
in 3rd case I'm weakly opposed to that as requires special knowledge
* /me nods, agrees
jenit: I suggested either 1st or 2nd, i.e. you could put either one of those into a metadata doc and it would be ok
gkellogg: lastly if an object is there it can only have language and base, i.e. not adding new term definitions
jenit: that makes it v restricted compared to full json-ld
gkellogg: if it were up to me, … it would be full json-ld. But I got msg from ivan et al to be more minimalistic.
… after experience and feedback we might move towards fuller form
<Zakim> jtandy, you wanted to ask whether people _can_ do full JSON-LD in their implementations if they want to
jtandy: presumably they could honour the json-ld stuff …?
jenit: not entirely true, because if it is a restricted subset a full processor would be too permissive and let things through that ought not to be accepted
jtandy: ok
I missed audio earlier in that sentence, can you type it?
<JeniT> .RESOLUTION: #80 JSON-LD must contain EITHER a string “http:/www.w3.org/ns/csvw” OR an array of the string “http://www.w3.org/ns/csvw” followed by an object which MAY contain @language and @base and no other values
<jtandy> +1
+1
<JeniT> +1
<ivan> +1
<gkellogg> +1
<JeniT> RESOLUTION: #80 JSON-LD must contain EITHER a string “http:/www.w3.org/ns/csvw” OR an array of the string “http://www.w3.org/ns/csvw” followed by an object which MAY contain @language and @base and no other values
<rgrp> hi all
<rgrp> sorry for late arrival!
gkellogg: did we resolve to close 43-78 as outlined?
jenit: yes
<rgrp> hoping to in a minute or so
rgrp, we're working through https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html … just passed #80
<JeniT> RESOLUTION: We will resolve #43, #76, #77, #78 as suggested in https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0050.html
<JeniT> https://github.com/w3c/csvw/issues/81
#81 is about aliasing of the json-ld keywords
#81 "Should JSON-LD keywords be aliased" – "Resolve not to alias keywords"
(that's gregg's proposal)
jenit: there are subissues. One was about dropping @type. I think we should drop having @type anywhere.
… only place it is remotely useful is for actual json-ld. If it is always optional they'll have to do something extra anyway.
ivan: am fine w/ that, but do we want to drop the corresponding typing from the json-ld conversion
jenit: suggest keeping it there, but not in metadata
jtandy: the metadata doc spec says "one of these has to be of that type", i.e. it is superfluous
<rgrp> danbri: i am happy to drop @type if we replace with @datatype (if we want json-ld type support for columns - i'm happy without)
<JeniT> .RESOLUTION: We remove @type properties in the metadata document
<JeniT> rgrp: what you want is being handled by the ‘datatype’ property currently
rgrp, don't tell me, I'm only scribing :)
[discussion of @type, which says different things to datatyping ]
jenit: it is still useful to have those terms defined in the vocab
<rgrp> JeniT: re datatype see https://github.com/w3c/csvw/issues/26
what was the verdict on #81 then? resolving @type first?
danbri: I Wouldn't want my file declared invalid just because i leave them in
jenit: then we'd have to expect them
… as we've said it would be an error if there is anything in there
gkellogg: json-ld is generally more permissive/flexible
jenit: @type is being used in places that common properties aren't
gkellogg; basically template and dialect
…otherwise anywhere a common property can exist, we can also consider @type a common property
jenit: if you're arguing that should allow peopel to do that, then we should have a rule that it must be this value
otherwise you get a WRONG metadata doc
we have to either say you can't put in @type or if optional it must be consistent with the vocabulary defined
gkellogg: in which case I'd rather leave it as-is.
ivan: I'm not convinced it is useful for anything.
… people will probably forget it, doesn't add info for anyone except those who care about rdf
jtandy: I thought that if we leave the spec as-is, … if people put it in or leave it in, that's fine; if they use wrong type, that's an error.
jenit: yup
jtandy: which seems fine. most people won't bother.
(I'm fine with the status quo)
jenit: seems sufficient support for status quo
<rgrp> I like @id to url :-)
only other thing in #81 was changing @id to url
<rgrp> or removing @id and url property
… or preferably removing @id or making it optional like @type and adding a url property
<rgrp> +1 to JeniT here
I'm agnostic. We're skirting around http-range-14 blablah with url.
jenit: semantic slipperyness, table vs thing table describes
gkellogg: a url property could be used just on table
jenit: yes only useful for pointing to the csv file that underlies the table.
jtandy: url property points to the csv file in which the table is described.
… allowing us to be a little bit ambiguous re identifying the table itself.
if someone did use @id they'd likely be talking about the table as opposed to the csv file
ivan: strictly speaking, and this is why having url is a good idea, … if the metadata file is json-ld, then the @id actually identifies the metadata
if i regard it as a json-ld content, that's what it means in json-ld
ivan: what really counts is the URL for the data itself
… if someone wants that id for the abstraction that's @id
(+1 for optional and url)
<rgrp> +1 JeniT proposal
jenit: proposing making @id optional and proposing an url property.
gkellogg: url property woudl also then be used on template
<JeniT> .RESOLUTION: make @id optional, add url property to point to CSV / template files etc
jtandy: would also need to ref table group?
<JeniT> +1
+1
<gkellogg> +1
<jtandy> +1
<ivan> +1
<JeniT> RESOLUTION: make @id optional, add url property to point to CSV / template files etc
<JeniT> RESOLUTION: otherwise close #81 with no other aliasing
next: 86
<JeniT> https://github.com/w3c/csvw/issues/86
https://github.com/w3c/csvw/issues/86 schema term ambigious
jenit: this one makes me roll my eyes… Because the rdfa context defines prefix 'schema:' to mean schema.org, then we can't use the property 'schema' to use something else in our document.
gkellogg: if we follow that chain, … that's how it is used as a property
jenit: i think it would be perfectly reasonable to have "schema:" as a prefix to mean http://schema.org/ … is there a way they can be disambiguated?
… pushing on this because schema is the term used in the table description format
jtandy: […] table groups / tables schemas .. .might be multiple
rgrp: the table group thing, … can i ask, is that grouping of tables within a group of csvs?
jenit: no, it is more like a group of csv files
rgrp: it's like having a [missed]
(rgrb, missed your comment can you retype?)
jenit: so in that case, as i'm the only one annoyed by this, … go with gregg's resolution
<JeniT> RESOLUTION: #86 change ‘schema’ to ‘tableSchema’ to avoid conflict with schema: prefix
<rgrp> rgrp: my point was that i'd raised multiple tables early on as in (tabular) data package - in fact default - you have a entry called resources and tables come under that ...
(on behalf of schema.org, we didn't mean to impose on anyone else's use of 'schema' in property names!)
<rgrp> so default is multiple files / tables - and i think that is a great idea - if it could be aligned with tabular data package that would be really good!
<JeniT> https://github.com/w3c/csvw/issues/93
jenit: next is #93 https://github.com/w3c/csvw/issues/93
… I just didn't understand the proposed resolution.
rgrp, [clarifies that he likes simplicity in standards]
#93: gregg, what's the suggestion here?
gkellogg: 2 things. We just got rid of @id, so no confusion between metadata and actual data
… also use of fragment ID
id in output, … subject of the output for the table, would be the csv location with the table fragment identifier
… that is basically taking some of jtandy's description in the csv2json doc
… i'd certainyl be willing to separate that out as a separate issue
… i think we've addressed the primary concern here
jtandy: there's a bit in here about whether to use the dcat terminology around terminology, versus the dataset, which i used in the rdf output
<rgrp> +q
to try to make sure that i'm clear about the diff between the csv files vs the abstract dataset that the csv file describes
rgrp, can anyone explain to me a user story, where a user will care, … not transforming to some other dataset, … who would care about the distinction
… who would it need to matter to?
jenit: only relevant to the rdf mapping
<JeniT> I really don’t want to have an HR14 discussion here
<rgrp> +1 JeniT
I'm fine not persuing this.
The distinction I mentioned was indeed different (but relates to the URis that the rdf mapping emits). I've interest in http-range-14 today!
<jtandy> (accepts)
<rgrp> +1 JeniT - but does that mean #93 is wontfix - i.e. no change
<JeniT> https://github.com/w3c/csvw/issues/96
action gregg to open a separate issue from #93 and close #93.
<trackbot> Created ACTION-61 - Open a separate issue from #93 and close #93. [on Gregg Kellogg - due 2015-02-04].
#96 about separate properties
"Should the cell-value URI Template be treated as a datatype? "
<gkellogg> PROPOSAL: I propose to follow @iherman's suggestion (essentially), and have three Column properties subjectUrl, predicateUrl, and objectUrl, all of which are URI Template properties. Furthermore, subjectUrl' replacesurlTemplate` as a Schema property (or becomes an inherited property).
<JeniT> https://github.com/w3c/csvw/issues/96#issuecomment-71834886
<rgrp> ack - i'm deferring as outside my expertise here :-)
jenit: … rather rdf'y terms, but otherwise fine. It would be good to have a Pull Request on github w/ the proposal in it.
<rgrp> JeniT: has my proxy :-)
ivan: can we separate two things?
… having these 3 properties with the names you propose. That is clean and we can all agree. But then discussion on which structures exactly these properties can be placed.
if we put e.g. property URIs as a possibility for the schema as a whole, … we may need additional variables for the templating mechanism
scribe:
ivan: I sent one comment 5 mins before call, … whether we allow a different subject per column.
that has consequences for the json and rdf output.
(Is that issue tracked?)
gkellogg: this also relates to whether the row values are in a list or not
ivan: i don't think so
… somehow we put that aside in one of our meetings, to just use a row id
jenit: why don't we resolve right now, to adopt 3 sep properties, …
… about property and value
(jeni's typing the proposal?)
<JeniT> .RESOLUTION: adopt three separate Url properties (about/property/value), editor to suggest exactly how that works within a PR
<gkellogg> +1
+1
<JeniT> +1
<ivan> +1
<jtandy> +1
jtandy: … and the 'about' url is the one with potential impl for the json or rdf conversions?
ivan: if we allow them to add in a column [did i get that right? --dan]
… there is a potential conflict if we go down that route
gkellogg: if we do not allow them in the column, that's an inconsistency
ivan: that would be easy to clear up.
jenit: #98, #101 ok as proposed?
<JeniT> https://github.com/w3c/csvw/issues/98
<JeniT> https://github.com/w3c/csvw/issues/101
[fine]
<JeniT> (101 is same as 96 really)
<JeniT> RESOLUTION: resolve #98 and #101 as Gregg suggests
editors to take on these resolutions
<JeniT> https://github.com/w3c/csvw/issues/128
jtandy: gregg, you suggested removing alis for xsd language, … i think it will still be useful
… and do what ivan suggested, changing where we have language to lang
gkellogg: i'm fine with that
jenit: you just wanted it one way or the other?
gkellogg: yes.
rgrp: some of the issues in tracker are quite ambigiously described
jenit: conversation in the issues can tend to meander, please try to be more strict
<rgrp> danbri: more than just having resolution here (which is sometimes just "accept #xx" we need to summmarize precisely what was agreed on that issue
<JeniT> .RESOLUTION: change ‘language’ to ‘lang’ so we can keep ‘language’ as meaning ‘xsd:language’
<gkellogg> +1
<ivan> +1
<JeniT> +1
<jtandy> +1
<JeniT> RESOLUTION: #128 change ‘language’ to ‘lang’ so we can keep ‘language’ as meaning ‘xsd:language’
danbri: i looked for things to argue with and fail, am supportive of closing the undiscussed issues as proposed
<rgrp> i'm really struggling also when reading the summary / issue to really understand proposal / resolution - if owners of issues could clarify with comment of current status proposal that would be really useful
<rgrp> thanks to gkellogg !
gkellogg: two PRs pending in git
169 and 171, if we can pull those it'll put us in a better state
jenit: any objections?
ivan: it would be good to do that
danbri: let's.
jenit: go ahead then
<Zakim> jtandy, you wanted to ask about coming calls
jtandy: regrets for next week's call
week after … is day before f2f
will there be a call?
jenit: no
jtandy: see you at f2f. I'll go through all the issues that I have opened and cross-reference them.
i'm massively busy abroad so actual editing time is limited.
ivan: if you have these issues properly listed etc i can take a look next week.
jtandy: i'll try to collate them on the wednesday.
<jtandy> ( a week on wednesday; 11th Feb)
Rufus/rgrp, will you be at https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02#Attendee_List ?
<JeniT> https://lists.w3.org/Archives/Public/public-csv-wg/2015Jan/0043.html
(if so can you record it in the wiki page)
jenit: we got a msg from Wim on the list about an alternative appraoch on the schema language
<rgrp> folks i have to drop!
… in interest of getting people involved, i'd encourage him to join the group and attent the f2f
jenit, we could have a small slot to discuss possible last minute contributions.
ivan, it is rather late in the day...
fwiw draft community group charter was at https://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0028.html
"This community group explores advanced techniques for mapping between tabular data (based on http://w3c.github.io/csvw/syntax/) and other data representations." etc