Re: Simplifying assumptions and suggested issue resolutions

Wow:-)
> On 21 Jan 2015, at 19:24 , Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
> We seem to be having a problem closing out issues on the issue tracker, and the meetings are too sparsely attended (IMO) to make real progress there.

Yes, I think we do have a problem here.

> I think the time has come to make some simplifying assumptions that can allow us to move forward on some metadata issues:

I add my votes below... At some point we should also go through the admin to add a note and close them

> 
> #43 "ignore invalid metadata files located through link header" - resolve in favor, and treat like any other metadata files

Agree

> 
> #76 "Metadata Merge I" – resolve by agreeing to my merge language in PR #169 to merge all metadata sources.
> 
> #77 "Metadata Merge II" – resolve by agreeing to my merge language in PR #169 to merge all metadata sources.
> 
> #78 "Metadata Merge III" – resolve by agreeing to my merge language in PR #169 to merge all metadata sources.

Yes, can be closed; the new merge algorithm have taken over.

> 
> #80 "JSON-LD context" – resolve as a string array of a string followed by an object, where the string MUST be "http://www.w3.org/ns/csvw". The object MAY contain @language and @base and MUST NOT contain any other values.

"as a string array" -> "as a string or an array" :-)

Agree

> 
> #81 "Should JSON-LD keywords be aliased" – "Resolve not to alias keywords"
> 

Agree

> #86 "schema term ambiguous" – resolve to rename the "schema" property to "tableSchema" to avoid confusion with schema.org

Agree (but will need editor action)

> 
> #93 "metadata and mapped data conflation" – Resolve to continue to use the #table fragment identifier on the table metadata @id to make these distinct. (Also, if it exists, the #tablegroup fragment on the TableGroup @id)

Not sure about that. I believe there are still some confusions around the exact usage of @id. Indeed, what happens if @base is not explicitly defined? What is then the base for relative URI-s (eg when generating RDF?). These are all related...

That being said, this is issue #91 but is left open...

> 
> #96 "cell-value URI template" – Resolve as suggested in my last comment on that issue.

Agree

> 
> #98 "row reference" – resolve to always emit a csvw:rownum triple referencing the source row. We may later consider making this optional.

Yes, this is what we discussed yesterday. Let us go for this now.

> 
> #101 "predicateUrl, urlTemplate and default" – See #96

yes

> 
> #128 "language term ambiguous" – Remove alias of xsd:language

I must admit I do not understand the issue. What is the problem in having "datatype":"language" alongside with the term "language"?

> 
> #136 "confusion on arrays and atomic values" – Resolve by agreeing to my merge language in PR #169 to merge all metadata sources.

To make it clearer to others, we are talking about

http://htmlpreview.github.io/?https://raw.githubusercontent.com/w3c/csvw/merge-semantics/metadata/index.html#merging-metadata

I think your language does not handle this yet. In the second block of bullet items the second and third items still talk about arrays and atomic values as separate things, whereas the document defines atomic values as numbers, booleans, strings, or arrays.

> 
> #142 "value space for common properties" – Resolve to allow just the six forms of literals and URIs described in that issue, and not more involved JSON-LD content.
> 

I agree, although I still have to think and answer to your comment on the JSON LD output.


> #144 "Metadata merge order" – Resolve by agreeing to my merge language in PR #169 to merge all metadata sources.

I agree in general, with one editorial issue. The procedure you describe may end with a set of column descriptions without a 'name'. Maybe we can say that, at the end of the overall merge, if the 'name' is not set for a column, its value is set to the value of 'title' (or should it be normalized due to the template requirements?). That would mean the rest of the specs, notably the transformations, simpler...

> 
> #145 "overal metadata" – Resolve by agreeing to my merge language in PR #169 to merge all metadata sources.

Agree

> 
> #150 "Merge and common dc properties" – Resolve by agreeing to my merge language in PR #169 to merge all metadata sources.

I am not sure. My original issue was that the 'title' is not defined on the table level, only 'dc:title' is used. How does your PR solve this?

> 
> #166 "datatype handling and template expansion" – Resolve to use post-conversion values without performing value separation.

Agree.

> 
> #169 (PR) "Update merge semantics" – Accept PR but may tweak creation of embedded metadata to be independent of metadata @language.

The issues covered by #169 are fine with me, acceptance of PR is also an editorial issue that I leave up to the editors...

> 
> #170 "Need for Core Tabular Data" – Resolve to only use annotated model for conversion as being essentially equivalent given merge model.

I agree in principle, but...

- I think having a clear separation in the syntax document, even if informal, is useful. But all other documents can/should ignore the concept
- The syntax document must have a section defining the 'default' metadata to a core tabular data.

> 
> #171 (PR) "Specified formats for dates & times" – Accept PR with possible improvements later.

For the sake of discussion, this is:

http://htmlpreview.github.io/?https://raw.githubusercontent.com/w3c/csvw/date-time-format/metadata/index.html#parsing-cells

I am fine with it.


> 
> Furthermore, the following issues can simply be closed:
> 
> #22 "type vs datatype" - no change

Agree

> 
> #87 "title term ambiguous" – Close with no change.

Agree

> 
> #97 "property name for row relation to table" – Close, as we have settled on csvw:row.

Agree

> 
> #113 "csvw:Table in output conflation"

Agree, it was a F2F resulution

> 
> #116 "Blank node shorthand" – Resolve to close with no change.

Agree

> 
> #149 "@context explicit" – Duplicate of #80, and close the same way.

Indeed.

> 
> 
> Thats more than enough for one go. Based on discussion, we can either resolve, close, or prioritize for next F2F meeting or telecon discussion.
> 
> If we can agree to some of these now, it will take a lot off of our plate, and give us the chance to make some headway between now and the F2F, which I think is important.
> 

Thanks for initiating this, Gregg!

Ivan


> Gregg Kellogg
> gregg@greggkellogg.net
> 
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704