Re: New metadata draft

On May 21, 2014, at 10:02 AM, Jeni Tennison <jeni@jenitennison.com> wrote:

> Hi,
> 
> I’ve done some fairly substantial work on the metadata draft [1] to get the structure and content more towards where I think we want it to head, including trying to map the existing data package structures into something that makes (more) sense if we’re viewing the metadata documents as JSON-LD structures with a metadata vocabulary.
> 
> There’s still a lot of work to do (and loads of issues as you’ll see), but I think it’s a little more internally consistent now. Comments appreciated.

Some technical comments on the JSON-LD used within the document.

In ISSUE 1, you raise some questions within the JSON-LD context:

[[something here that maps the publisher onto an appropriate schema.org type?]]

Note that the JSON-LD context doesn't really describe dataranges beyond that for literals. So you map "publisher" to dc:publisher, and say that the default value is expected to be an IRI or BNode; you can't say that the type of that IRI should have a type of, say, schema:Person, if that's indeed what your attempting. For that, you need to revert to OWL or RDFS (or the schema.org rangeIncludes variation).

[[
don't know how to say the list is of Column objects
don't know how to detail the properties of the columns in context
]]

I modified this to the following: "columns": {"@type": "@id", "@container": "@list"}
Note that using @id within the term definition is not necessary if the term can already be expanded to an IRI (using @vocab, in this case). The @container: @list says that it is an ordered list, the @type: @id says that the default type for the list elements is expected to be an @id.

On ISSUE 2: a JSON-LD doc can always reference the context remotely. In fact, if the RDFS for the vocabulary is published at <http://w3.org/ns/table#>, the JSON-LD version of that vocabulary can also include the context itself, in addition to the RDFS definition. This would make a simple document look like the following:

{
  "@context": "http://w3.org/ns/table#",
  "@id": "tree-ops.csv",
  ...
}

ISSUE 19: This also means that the column values need an @id defined. You could avoid BNodes, by simply using a string which can be resolved as an IRI relative to the document location. If "name" had @type: @id, it would not be treated as a string, but as a property referencing an internally node. For example:

{
  "@context": [ "http://w3.org/ns/table#", {"@base": "tree-ops.csv#"}],
  "@id": "tree-ops.csv"
  ...,
  "columns": [
    {@id": "GID", "name": "GID", ...},
    {@id": "familyName", "name": "familyName", ...}
    {@id": "givenName", "name": "givenName", ...}
  ],
  "primaryKey: ["familyName", "givenName"],

If you made "name" a synonym for "@id", you wouldn't need to use @id either, but you'd need to be sure that "name" was used uniquely, as that could cause separate nodes to coalesce when turned into RDF. Alternatively, "name" could be a property of type @id, instead of string, in which case it would refer to a node having that @id definition.

ISSUE 37: I think you can use data-include in ReSpec to actually load the context definition into the document; should be able to syntax highlite it too.

Gregg


> Jeni
> 
> [1] http://w3c.github.io/csvw/metadata/
> --  
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Wednesday, 21 May 2014 20:08:06 UTC