Should the table entity in the RDF mapping of core tabular data be explicitly identified?

[6a6d74]

Should the table entity in the RDF mapping of core tabular data be explicitly identified (e.g. as [CSV Location]#table)?

[iherman]

What would it provide us in practice?

Ivan

On 15 Dec 2014, at 11:42 , Jeremy Tandy notifications@github.com wrote:

Should the table entity in the RDF mapping of core tabular data be explicitly identified (e.g. as [CSV Location]#table)?

—
Reply to this email directly or view it on GitHub.

---

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

[6a6d74]

It means that we can refer to the table entity itself; most of the RDF triples in the output relate to this entity. It would be nice (but only nice) to be talking about something with a real identifier rather than a blank node.

[iherman]

Ah, I see, I am fine with this.

Ivan

On 16 Dec 2014, at 16:41 , Jeremy Tandy notifications@github.com wrote:

It means that we can refer to the table entity itself; most of the RDF triples in the output relate to this entity. It would be nice (but only nice) to be talking about something with a real identifier rather than a blank node.

—
Reply to this email directly or view it on GitHub.

---

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

[JeniT]

The problem with using something that looks like example.csv#table is that the interpretation of that fragment identifier has to be done based on the media type of example.csv. In this case it's CSV, which means interpreting according to RFC7111 which doesn't include a definition of #table.

So technically we can't do that. Better, I think, to have the table be a blank node with an explicit pointer to the CSV file that it originates from (eg via dc:source).

[iherman]

On 04 Feb 2015, at 18:04 , Jeni Tennison notifications@github.com wrote:

The problem with using something that looks like example.csv#table is that the interpretation of that fragment identifier has to be done based on the media type of example.csv. In this case it's CSV, which means interpreting according to RFC7111 which doesn't include a definition of #table.

Oops:-) You are right.

So technically we can't do that. Better, I think, to have the table be a blank node with an explicit pointer to the CSV file that it originates from (eg via dc:source).

That would work for me

Ivan

—
Reply to this email directly or view it on GitHub.

---

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

[gkellogg]

This is an opportunity to take advantage of a possible @id field in the table metadata. We changed this to be url to reference the csv file, but being JSON-LD, it may have an @id, none the less. Note that if it doesn't, it's identifier is a blank node. But this does offer a way for the metadata author to control the Table identifier.

[iherman]

On 05 Feb 2015, at 16:18 , Gregg Kellogg notifications@github.com wrote:

This is an opportunity to take advantage of a possible @id field in the table metadata. We changed this to be url to reference the csv file, but being JSON-LD, it may have an @id, none the less. Note that if it doesn't, it's identifier is a blank node. But this does offer a way for the metadata author to control the Table identifier.

Yes but that is again different: "@id" gives an identity to the metadata and not to the table data in, say, RDF form. It is the same duality as @language vs. lang...

Ivan

—
Reply to this email directly or view it on GitHub.

---

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

[gkellogg]

Indeed it does.

You can see my interpretation of what generated RDF (and JSON) might look like on my gkTransformation branch: https://github.com/w3c/csvw/tree/gk-transformations/tests. Not that it is necessarily perfect, but it would be good to see if we are in general agreement, at least if common properties are restricted to the Table.

[iherman]

@JeniT note that the prov information, which is already part of the csv2rdf document (though not fully kosher as is, see #174). That being said, the source is pretty much buried down in the prov information, so a redundancy may be o.k.

[danbri]

See http://www.w3.org/2015/02/12-csvw-irc#T17-58-27

[JeniT]

Resolved at Feb F2F: if there is a @id on a table description or a table group description in the metadata, this can be used as the resource identifier in the RDF, otherwise they are blank nodes.

[6a6d74]

csv2rdf doc now updated as per resolution.

If the Table resource is identified in the metadata description, then the RDF output will use an IRI for the resulting node - else a blank node is used. Same for TableGroup.