09:01:11 RRSAgent has joined #csvw 09:01:11 logging to http://www.w3.org/2015/02/13-csvw-irc 09:01:24 Meeting: CSVW F2F Meeting, London, 2nd day 09:01:28 Agenda: https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02 09:01:32 gkellogg has joined #csvw 09:01:34 Chair: Jeni 09:01:42 rrsagent, set log public 09:01:51 rrsagent, draft minutes 09:01:51 I have made the request to generate http://www.w3.org/2015/02/13-csvw-minutes.html ivan 09:18:44 danbri has joined #csvw 09:19:38 jumbrich has joined #csvw 09:20:56 jtandy has joined #csvw 09:21:25 Agenda: https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02 09:21:32 scribenick: gkellogg 09:21:32 DavideCeolin has joined #csvw 09:21:37 topic: Foreign Keys and References 09:24:17 http://piratepad.net/URwa3CM9Vv 09:25:23 JeniT: how we handle having multiple interrelated tabular data files. 09:25:47 … An example is the public salaries use case (#4?) 09:26:14 scribenick: danbri 09:26:20 gkellogg: roles json is basically a table group referencing two tables 09:26:26 … the driving metadata file 09:26:31 references the senior roles 09:26:41 and the junior roles 09:27:44 junior people refer to senior people 09:28:01 … a foreign key rel from the col 'reportsTo' to the other with col 'ref' 09:28:29 what we've said here … we've created property urls, and a value url 09:28:38 so property expands to reportsTo and value uses a URI pattern 09:28:46 senior roles have more col definitions 09:28:50 ref name grade and job 09:29:51 this allows you to examinethe data, … a vaidator, ... 09:30:12 … looking at junior, … seeing reporting senior in 1st col, which would need to exist in the senior roles in the post-unique reference 09:30:26 e.g. 90238 is 3rd or 4th row 09:30:41 JeniT: a couple of observations 09:30:54 first is, two kinds of mechanisms for getting pointers between resources 09:31:02 one is thru primary and foreign key type mechanism 09:31:08 very database-oriented terminology 09:31:19 all primary key really says is that values in this column are unique 09:31:24 … each is different 09:31:45 foreign keys, or unique comb of values if multi-column, … must reference something that does exist in this other file 09:31:55 so quite a tight, validation oriented relationship 09:32:00 AND also we have 09:32:03 aboutUrl, valueUrl 09:32:08 these create the links in the output 09:32:15 for rdf and json generation 09:32:25 creates the urls for the things being identified in these files 09:32:35 could easily have an example that only had the one or had the other 09:32:48 gkellogg: in fact primary and 2ndary keys are not used in the transformation 09:32:54 ivan: there is a need for consistency 09:33:45 ivan: whatever is described in the f.key structure 09:33:52 vs what we use in the valueUri 09:34:00 you would expect those things would be essentially identical 09:34:05 woudl they ever differ? 09:34:20 jenit: usually they would match but it's a rope-and-hang-yoursel 09:34:26 f 09:34:35 gkellogg: consider two tables, ... 09:34:41 see http://piratepad.net/URwa3CM9Vv 09:38:13 we… used diff 09:38:18 q? 09:38:25 ivan: to be clear, avoid misunderstanding, ... 09:38:39 … source of misunderstanding, … column names used for interlinking 09:38:41 Zakim has joined #csvw 09:38:46 you invite him-her-it 09:39:13 gkellogg: … what we have is a primary key in the senior but not in the junior 09:39:32 (jeni takes to whiteboard) 09:39:51 jtandy: in junior schema how do you know that it is reportsTo in the senior? 09:40:20 ivan: template refers always to the local table value 09:40:28 …has nothing to do with the reportsTo of the other table 09:40:45 gkellogg::better to update the example accordingly? 09:40:53 jenit: let's start with something super simple 09:41:04 ivan: e.g. i would remove the reportsTo of the senior table 09:41:39 jenit: it is useful to have that example 09:41:59 danbri: at some point it crosses over into domain datamodel validation e.g. "no reporting cycles" problem isn't our problem 09:42:45 scribenick: gkellogg 09:43:03 jumbridge: this requires that columns have names? 09:43:13 iherman: yes, but there are defaults. 09:43:48 jumbridge: so, there may be a name or a title, but name is best for creating a reference. 09:44:41 … perhaps we should use “id” someplace in the metadata to show that this is an identifier? 09:45:06 jenit: I’d like to stay close to Data Package. 09:45:58 DavideCeolin: If I have two tables and want to say one refers to the other, I can do it using small markup in the FK specification. 09:46:21 jenit: we’ll go into issues. 09:46:27 https://github.com/w3c/csvw/issues/16 09:47:23 JeniT: Andy brought up the difference between “strong linkage” in databases, with strong validation requirements for the FK to find the reference, and the “weak linkage” in the web where something may not exist. 09:48:00 … He as concerned about not having to resolve URLs to validate links. When you’re at the process of generating them, they likely don’t exist anyway. 09:48:19 danbri: granularity was an issue as well, depending on there the data comes from. 09:49:00 JeniT: We have two mechanism, the first you have control by knowing what is coming together and having control of the metadata and are better able to make a strong statement about validation when using such cross-references. 09:49:29 … We also have the “weak linking” generation on demand where there is no check. It’s up to the metadata author to know what to use. 09:49:57 iherman: we have to define what a validation is expected to do. In this case, we probably require only weaker validation? 09:50:26 JeniT: When there is a primary key then a validator must verify that all referenced data exists and that all primary keys are unique. 09:51:20 jumbrich: so this allows just mapping one data without necessarily mapping the other. 09:51:57 iherman: you don’t have to check if the values in a column using an FK are actually present in the other table. The two tables are consistent in the roles example, as they do exist. 09:52:16 jtandy: if you declare it as an FK you must check that it exists. if you use a valueUrl, you don’t need to check. 09:52:51 … Because strict validation is a “beast”, you can only use the references within a single TableGroup. 09:53:18 ( if you want some examples with multi-table keys, https://github.com/w3c/csvw/tree/gh-pages/examples/tests/scenarios/chinook ) 09:54:41 jeniT: there is a subtlety in the examples ... 09:55:14 … In real life, there is a government office that says all departments need to publish senior and junior roles, and all adhering to the same schema. 09:56:24 … They also define a list of departments, with say name of department, and website. 09:58:14 … When departments publish the senior/junior roles pairs, the “dept” column will typically all be the same pointing to the identifier of a particular department, so the FK needs to reference the departments.csv file. 09:59:10 … The TableGroup then needs to reference the departments CSV and schema. 10:02:24 jumbrich has joined #csvw 10:02:38 iherman: the person creating the description probably shouldn’t say what data not to export. 10:02:55 gkellogg: But, this could be specified in user-deined metadata, and is undercontrol of the user. 10:03:28 jumbrich: I might want to refer to other resources without pulling them in. 10:04:29 JeniT: the closest thing we have is to use the same table group to describe related resources and generate the URL for a “team” in any output. Youl would then use that URL to reference the team, for references and identification. 10:05:09 jumbrich: I might have a relation table, and a couple of tables where things are used, and I might want to point to something for additiona information. 10:05:48 DavideCeolin has joined #csvw 10:06:10 … I might be able to build search on top of the metadata where I could use FK information to infer information about the various tables. 10:06:18 jtandy: I think that’s a normal FK relationship. 10:07:25 iherman: there’s also a difference between what a validator and a transformer will do. 10:08:23 … The FK spec is conceptually disjoint from the valueUrl and transformation. The FK is only there for validation. 10:08:46 jumbrich has joined #csvw 10:09:06 jtandy: if you use PKs, that might change how you serialze. 10:09:19 https://github.com/w3c/csvw/issues/16 10:09:55 JeniT: FK references are for validation purposes... 10:14:10 jumbrich has joined #csvw 10:14:45 danbri: what do we say about the results of being invalid? Are we creating a culture so that things can’t proceed if they’re invalid. 10:16:05 JeniT: a validator may work in strict and lax modes, where it fails at the first problem when strict, but just reports all issues encountered when lax. 10:18:02 https://github.com/w3c/csvw/issues/31 10:18:09 rrsagent, pointer? 10:18:09 See http://www.w3.org/2015/02/13-csvw-irc#T10-18-09 10:18:29 rrsagent, make logs public 10:18:36 jtandy: this looks out of date now, I suggest close as “expired”. 10:18:47 iherman: it will come back if we have a “skip” flag. 10:19:07 "Should primary keys be skipped from cell level triple (or k/v pairs) generation? #31" 10:19:15 JeniT: if you use valueUrl, you only get ??? 10:20:16 https://github.com/w3c/csvw/issues/130 10:21:25 jtandy: Alain has provided some alternate JSON structure that uses identifiers as properties rathern than an array. 10:22:38 … If you didn’t define a PK, there’s not necessarily one thing that is unique, and such an index structure is available. 10:23:03 … We agreed that PK is for validation, but necessarily only for validation. 10:23:27 JeniT: this is the purpose of aboutUrl, which _may_ be associated with the PK, but not necessarily. 10:23:53 jtandy: the index and object works for some, but Tim Robertson seemed to object. 10:25:14 JeniT: I think we should only define one JSON output for ease of scope. 10:25:59 jtandy: so the “standard” publishing mechanism is an object per-line, and converting to an ‘indexed’ mechanism is “triveal”, and outside the scope of the spec. 10:26:33 … We may say that implementations could have alternate output forms. 10:27:00 ('templating and transformation'?) 10:27:33 iherman: I like to have a conceptual similarity between the JSON and the RDF transformations, and for the time being they are quite similar. 10:27:52 rrsagent, pointer? 10:27:52 See http://www.w3.org/2015/02/13-csvw-irc#T10-27-52 10:31:50 https://github.com/w3c/csvw/issues/66 10:32:32 "Composite primary keys and foreign key references #66" 10:33:14 jtandy: for exmple my PK may be based on givenname & familyname, and you’re making stuff up as you go along. 10:33:47 JeniT: you can use aboutUrl to combine such columns together to get what you want. 10:34:56 … You can’t say that one column points to two values, but you can create an aboutUrl which uses both name and a valueUrl in the other to create the same reference. It works for RDF, but not for validation. 10:35:34 rragent, pointer? 10:35:55 rrsagent, pointer? 10:35:55 See http://www.w3.org/2015/02/13-csvw-irc#T10-35-55 10:36:50 danbri: if you had postal codes in each country, then the combination of country code and postal code will be unique. 10:40:31 jtandy: TableGroups contain resources and may contain schemas? (yes) 10:41:32 JeniT: because there are two different types of FK references you might make (departments example), one always points to the same resource, and the other to different values based on cell values. 10:55:51 Topic: URLs and metadata 10:56:18 jumbrich has joined #csvw 10:57:09 https://github.com/w3c/csvw/issues/74 10:57:36 https://github.com/w3c/csvw/issues/74#issuecomment-72854167 11:00:42 https://github.com/w3c/csvw/issues/191 11:02:13 diverted onto https://github.com/w3c/csvw/issues/91 11:02:55 https://github.com/w3c/csvw/issues/191#issuecomment-73497474 11:09:43 gkellogg: in json-ld … there are rules for term expansion 11:09:54 … the prefix expansion is more naturally dealt with as part of #91 than this. 11:10:03 What we're doing here is saying it is a URL template property 11:10:08 when you apply template, result is a string 11:10:14 which in #91 will be made into an url 11:10:21 jenit: fear we'll get stuck on exact wording 11:10:27 … can we capture direction of the resolution 11:10:32 … will ref #91 11:10:37 … and editor action will be needed 11:10:48 capturing basic thing, … these properties are string properties 11:11:42 from piratepad, copying: 11:11:52 resolved: The order of processing is as described in https://github.com/w3c/csvw/issues/191#issuecomment-73497474https://github.com/w3c/csvw/issues/191#issuecomment-73497474http://piratepad.net/ep/search?query=issuecomment-73497474. These properties are string properties, the URL template is expanded first. Any resolution (ie expanding prefixes & resolving against a base URL) is done after that expansion. Editor action to make this so. 11:12:02 https://github.com/w3c/csvw/issues/91 11:12:12 "What is default value if @base is not defined in the metadata description #91" 11:12:14 s/#91/#191/ 11:13:46 jenit: bunch of issues … 11:13:56 how link urls which are bases are resolved 11:14:09 how url templates following their templates, what base url they get, how they are then treated, what base url gets used on that 11:14:25 and then whether we want to provide some level of control within the urltemplates to enable people to expand based on a different base url 11:14:29 1st - link properties 11:14:33 like reference to the csv files 11:14:47 those link properties should be resolved in the same way that they are resolved in json-ld 11:14:53 i.e. if there is an @base in the context, use htat 11:14:59 otherwise metadata doc in which that link is found 11:15:04 requires to you expand them prior to merging 11:15:11 or keep track of where original comes from 11:15:23 gkellogg: that's where language in merge now says 11:15:37 before merging both A and B make any link URIs absolute relative to the base of that metadata 11:15:48 ivan: isn't there also a language about merging the @base? 11:15:56 gkellogg: for @base there is 11:16:00 works pretty much like object merging 11:16:05 ivan: but then why do we merge @base? 11:16:16 gkellogg: point is that after normalizing, context isn't necessary any more 11:16:20 ivan: let's make that explicit 11:16:34 … conceptually every metadata file needs to be normalized before merged 11:16:46 gkellogg: @base and language can dissapear 11:16:57 you still need the default metadata since that is how you define prefixes etc 11:17:11 ivan: i don't think we do that 11:17:19 jenit: they're never explicitly put inthe @context 11:17:29 … gregg is saying that conceptually there is such a context 11:17:46 and if you are using basic json-ld processing, then implicitly we'd pull in everything from that context doc 11:17:54 gkellogg: need not be just implicit 11:17:59 we need to figure out what we want to do 11:18:17 jenit: you were both in agreement that the @base and the @lang were redundant by the time you had gone through the normalization 11:18:22 ivan: that's correct 11:18:31 gkellogg: but there is a conceptual or virtual base url of the metadata 11:18:38 besides an explicit @base declaration 11:18:43 jenit: yes, the location of... 11:18:48 gkellogg: or the 1st in a set, ... 11:18:54 jenit: that, I don't, ... 11:19:02 ivan: comes back to #199 11:19:43 jenit: i think we agree that the link properties are resolved against the base url, maybe the @base from the context, or it may be the location of the metadata file, during normalization of the metadata file, and prior to merge. 11:19:55 [[[If the property is a link property the value is turned into an absolute URL using the base URL.]]] 11:20:00 jenit: 2nd piece of this, is what happens to these url templates 11:20:09 these can't get expanded until you are actually processing data 11:20:19 at which point you have your merged metadata as basis of what you are doing 11:20:33 if you have lost your base url, or not got, what to resolve against becomes tricky 11:20:44 also - jtandy's 1st assumption, that those would be resolved against url of the csv file 11:20:51 so when you had template like #rownum=5 11:20:59 then that would be ref to something within the csv file 11:21:05 not relative to any of the metadata files it might be in 11:21:13 which raises the usability perspective, ... 11:21:27 … it might be better for the url templates to be ref'd against the csv file 11:21:35 to have that as the default 11:21:54 gkellogg: i won't stand in way, but am not enthusiastic 11:22:03 … you can always avodi trouble by having absolute urls 11:22:22 jtandy: we just need to be clear on what happens when not an absolute url 11:22:41 ivan: raising q: is it not confusing for authors, that we have 2 diff ways of absolutising urls 11:22:48 depending on whether they are link properties or templates 11:23:01 … a completely diff approach would be that we don't do this under normalization 11:23:07 instead use the table url just like for templates 11:23:21 jenit: how do you resolve the table url? that's the link property 11:24:18 gkellogg: json-ld has an url expansion algo 11:24:43 … nominally each json-ld doc has a location which can overide @base 11:24:52 ... 11:25:16 if we say it is undefined, this would be the only doc (format) i've dealt with in which you start off with a base and then lose it along the way 11:25:50 ivan: talking about confusing, … that means I get a merged metadata, and the various templates in that metadata will expand differently 11:25:59 … the templates will expand depending on where they come from 11:26:06 gkellogg: no, there's a single base url notionally 11:26:11 ivan: then i don't understand the issue 11:26:24 gkellogg:I think we said it's the csv file it is expanded against 11:26:32 that's what i reacted to , saying that this is weird, … 11:27:06 jenit: [missed] 11:28:14 discussion of detail of mess starting with the csv file vs metadata 11:28:33 jtandy: key issue to my mind, uri templates only get expanded once you've done all the merging, ... 11:28:38 … only at that point, 11:28:44 gkellogg: only at row processing stage 11:28:55 jtandy: … templates get expanded, … urls get resolved, … 11:29:12 gkellogg: which we're saying is the expanded url property of the table 11:29:17 jtandy: at least we always know what that is 11:32:41 jtandy: to clarify, this is for the metadata doc, and by time we get to conversions, this will all have been expanded? 11:32:42 [yes] 11:33:39 phila_reception has joined #csvw 11:33:40 jenit: do we in abstract table data model need url in each cell not just value 11:33:46 i.e. what you'd get from value url 11:33:52 gkellogg: that is the value of the cell 11:33:55 jenit: no 11:34:04 -> example in piratepad 11:34:28 DavideCeolin has joined #csvw 11:34:31 scribenick: gkellogg 11:35:37 iherman: just to clarify, linkproperty values can be CURIEs/PNames 11:36:27 https://github.com/w3c/csvw/issues/121 11:37:29 gkellogg: discussion of expanding urls, we talked about json-ld, then asked about URL spec 11:37:37 reason for that is that url spec doesn't deal with prefixes 11:37:42 scribenick: danbri 11:37:50 ivan: spec-wise it is fine, but if i read that doc it is like some of the HTML5 specs 11:38:05 jenit: does it specify the behaviour that we want it to specify 11:38:13 … there is no other good url spec to reference 11:38:28 jenit: i think it is at least consistent to point to the json-ld one 11:38:42 phila has joined #csvw 11:38:45 ivan: that's why i asked what i asked. back then it went into a whole set of things that were v json-ld specific, with prefixes etc. 11:38:48 …that was my fear 11:39:08 … it goes into all kinds of detail on context processing 11:39:27 gkellogg: we are using a context, we have one defined that defines all of our terms, that is the one used when expanding these values 11:39:36 jenit: let's defer this, maybe discuss over lunch, ... 11:39:54 gkellogg: if we choose something else let's say it is intended to be consistent with json-ld iri expansion 11:40:09 ivan: one thing it does introduce, … and we do not, is issue of syntax for bnode identifiers 11:40:16 gkellogg: but we can constrain the value space... 11:40:37 Zakim has left #csvw 11:41:00 jenit: suggest resolve as "we'll summarize the algo from json-ld spec, extract bits that are relevant, and say it is intended to be consistent with the spec 11:41:06 gkellogg: yes, can do that 11:41:20 … re bnodes i think it is intent of group to avoid using a bnode syntax where URIs can be used 11:41:40 ivan: maybe we need some sort of appendix 11:41:50 saying this is json-ld compatible, but with these-and-these restrictions 11:41:57 e.g. that we restricted what can go into a context 11:42:08 … that we have restricted yesterday the evlaution of common properties, etc. 11:42:17 … i.e. there are a number of places where we restrict json-ld 11:42:23 [general agreement] 11:42:57 resolved: We will summarise the expansion processing that is necessary for our purposes, and say that it is intended to be consistent with JSON-LD IRI expansion. We do have some restrictions on what IRIs can be used, eg we don't allow blank node syntax. 11:43:20 topic: Conversion issues 11:43:34 from https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02#Friday_13th_February 11:43:45 will revisit after lunch. 11:44:03 topic: Conversion Details 11:44:33 https://github.com/w3c/csvw/issues/83 11:44:43 Extension Conversions: #83 "Possible error in "optional properties" for Template Specifications: source #83" 11:45:03 jenit: this is about when we have these extension conversions, we have said we want to enable extensions to work on results of a conversion we have already defined 11:45:10 e.g. we have already defined json and rdf 11:45:19 … can we make e.g. a post-processor that sits on top of the RDF 11:45:26 maybe it might use SPARQL CONSTRUCT 11:45:42 (the use of XML in the orig issue was a typo) 11:45:58 this lead to q of what the source looks like for post processing 11:46:07 gkellogg: how does this relate to accept headers? 11:46:20 e.g. my impl creates an abstract graph 11:46:37 … Accept: can turn into a prioritized list of formats 11:46:47 seems like the type of thing that a tabular data processor might do 11:47:16 danbri: assumes an HTTP REST deployment model? 11:47:23 ivan: seems like an impl detail not relevant here 11:47:34 … more … if you want Turtle, this is the processor you can use, etc etc 11:47:44 options of tools or http or online tools … i dont think we should go there 11:47:57 ivan: only thing, what in metadata descr params need to be specifiable 11:48:17 gkellogg: seems reason why Accept has a prioritised list, so you get something you can handle even if not best 11:48:32 jenit: in my head, the source thing here was only taking 2 values 11:48:45 … and when you said post-processing woudl be delivered an rdf graph 11:48:52 you wouldn't be specifying 11:48:59 you might never serialize 11:50:38 danbri: not comfortable assuming all in memory / API access, unix pipe model is quite likely 11:50:45 ... 11:50:56 jenit: you (jtandy) are assuming serialized output? 11:51:03 jtandy: i'm v happy saying we don't serialize 11:51:33 that json stays just in memory 11:51:42 gkellogg: i believe json in memory defined in ecma 11:54:36 gkellogg: diff between target format and template format? 11:54:47 … mustache vs RDF 11:55:34 jenit: either you'd be operating over the rdf using a mustache template, or to create rdf/xml, would be a basic thing ... 11:56:07 danbri: would fancy alternate mappings always use json or rdf mappings? or sometimes raw? 11:56:12 jenit: can go back to the base also 11:56:27 fwiw this was the closest we got to a demo using R2RML : https://github.com/w3c/csvw/blob/gh-pages/examples/tests/scenarios/events/attempts/attempt-1/metadata.json 11:56:34 https://github.com/w3c/csvw/tree/gh-pages/examples/tests/scenarios/events/attempts/attempt-1 12:56:37 jumbrich has joined #csvw 12:58:10 gkellogg has joined #csvw 12:58:53 jtandy has joined #csvw 12:59:03 scribenick: danbri 12:59:05 topic: Conversions 12:59:23 jenit: given that we have abouturls, property urls etc etc, i.e. pretty flexible way of making triples from a row in the table... 12:59:23 DavideCeolin has joined #csvw 12:59:33 …what does this imply in terms of what else is needed to be flexible about that structure 12:59:37 or should we be constraining it 13:00:00 https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02#13:00_-_14:30_Conversion_Details 13:00:05 issue #66 already closed 13:00:19 so https://github.com/w3c/csvw/issues/66 does not need discussion 13:00:53 https://github.com/w3c/csvw/issues/64 13:00:57 "Suppression of columns in mapping #64" 13:01:05 ivan has joined #csvw 13:01:16 jtandy: sometimes in the stuff you want to push out through RDF or JSON conversion, you might not want all of the cols in the tabular data to appear in the output 13:01:24 I would just like to be able to say "don't include this column" 13:01:34 … seemed trivial but ppl objected 13:01:50 gkellogg: [missed] 13:02:01 … re naming, we mix hyphens and CamelCase 13:02:05 jtandy: should be CamelCase 13:02:15 s/jtandy/jenit/ 13:02:16 so "table-direction" is wrong 13:02:27 jtandy: so that was my requirement, it would be cool if you could do that 13:02:44 jenit; and properties 13:02:57 jtandy: Gregg's suggested optimzation for skipping an entire table, it could be an inherited property 13:03:08 so you could say it up at the table level, schema... 13:03:19 gkellogg: suppressing table would handle all its cols 13:03:26 ivan: strictly speaking this is not the same 13:03:33 because if I have common properties 13:03:37 if i say I skip the table 13:03:48 if i refer back to this AM's discussion, i want to supress the generation of everything 13:03:53 if i have a flag on a table, is fine 13:04:07 … if just a space keeper for all the cols, you would generate common properties 13:04:11 jtandy: you are correct 13:04:16 therefore we should have a suppress col 13:04:20 gkellogg: i don't see that 13:04:27 if it is on the table that is how it is interpreted 13:04:38 ivan: let's not conflate the interpretation of this 13:04:51 jenit: surely having the same property does not ... 13:05:16 "this suppresses the conversion output from the thing that it is on" would be a fine def, to avoid having repeated similar terms 13:05:31 ivan: but I might want to do what I said earlier, just common properties 13:07:17 resolved: We will introduce a `suppressOutput` property, on individual resources or on columns, which would mean that no output was generated from that table or from that column during a conversion. This is not an inherited property. 13:07:20 rrsagent, pointer? 13:07:20 See http://www.w3.org/2015/02/13-csvw-irc#T13-07-20 13:08:07 jtandy: before we get to phantom cols, … aboutUrl on cols? 13:08:30 gkellogg: we resolved that aboutUrl etc are common properties 13:08:38 can appear in col, schema, … 13:09:16 ivan: there may be cells where the generated triples have a different subject 13:09:23 jenit: let's discuss that 1st 13:10:02 "whether it is useful helpful to have different about URLs on different cols … 13:10:14 jtandy: that would really help my use cases 13:10:21 q+ to agree a lot 13:10:29 … we need multiple entities per row 13:10:44 ivan: if we go there, fundamentally not against it, … the structure of the generated rdf needs rethinking 13:11:00 currently we make a predicate 'row' etc etc… this structure becomes meaningless 13:11:08 gkellogg: in average case it works out fine 13:11:21 way reads now, the row resource, iri is from 1st cell 13:11:32 jtandy: no, subject of row comes from aboutUrl in schema 13:11:46 jenit: purely what you generate as triples 13:11:48 Zakim has joined #csvw 13:11:50 q+ 13:11:56 jtandy: i believe this is an inherited property 13:12:05 so if you define it at schema level, … 13:12:19 [can't capture realtime and listen, backing off from detail] 13:12:57 q? 13:13:06 ack danbri 13:13:09 gkellogg: some times it does have value to use row 13:14:32 ivan: where do i put these extra triples? 13:14:40 jenit: "the output" :) 13:14:57 jtandy: if we are processing on a row-by-row basis, we look at those across a row that share a subject, and emit them together 13:15:09 the issue we have got is that the entities which are talked about lose an implicit relationship to the table they are in 13:15:24 jenit: what kind of relationship … 13:15:56 https://github.com/w3c/csvw/issues/179#issuecomment-72072147 13:15:57 issue may be discussed in tracker under 'phantom col' 13:16:19 gkellogg: imagine a doap description of a software project, referencing a foaf description of a developer 13:16:48