W3C home > Mailing lists > Public > public-rdf-wg@w3.org > September 2012

Re: Dataset Syntax - checking for consensus

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 26 Sep 2012 15:13:20 +0100
Message-ID: <50630D80.1020109@epimorphics.com>
To: public-rdf-wg@w3.org


On 26/09/12 00:14, Sandro Hawke wrote:
> I'm not sure how much progress we'll be able to make on dataset
> semantics tomorrow, so I thought I'd draft some proposals on dataset
> syntax.   The chairs can put this on the agenda is they like (but it's
> too short notice for these decisions to be binding yet).  I'm thinking
> it would be useful to see how close we are to agreement on these issues.
>
> If you followup with votes, please use -1 for Formal Objection, 0 for
> abstain, +1 for approve.   Numbers in between are fine, too.

Good idea.

My notation:
"-0.99" -- I am not formally objecting here but think it is not the 
right thing to do.

> PROPOSED: We will produce a W3C Recommendation for a dataset syntax,
> similar to TriG and to SPARQL's named graph syntax.

+1
and n-quads as well.

> PROPOSED: We'll request a media-type for this syntax which is different
> from the media-type for Turtle.  (That is, we will not consider this
> language to supplant Turtle and take over the name, becoming the new
> "Turtle", as was once proposed.)

+1
and application/n-quads as well.

> PROPOSED: Our dataset syntax will allow for the expression of empty
> named graphs, whatever their semantics might be (to be decided). The
> syntax is an empty curly-braces expression, as in "<g> { }".

+1

> PROPOSED: Our dataset syntax will have some standard mechanism (to be
> determined within the next few weeks) through which a Dataset
> serialization can include some RDF data about the Dataset (that is, some
> metadata in the form of an RDF graph).

-0
I would like to see this as describing good practice.
It should not be a syntax issue.

-0.5 to mandating anything.  Too early/unproven.

> Below, there are groups of proposals which are alternative solutions to
> a design issue.   If you approve of more than one of the alternatives,
> please vote "+2" for your favorite.
>
> * Name of the dataset syntax
>
> PROPOSED: We will call our recommended dataset syntax "trig",
> capitalized to Trig as needed.

0

> PROPOSED: We will call our recommended dataset syntax "TriG", but
> informally and in the media type, "trig".
+1


> PROPOSED: We will call our recommended dataset syntax "TriG", and use
> that capitalization everywhere.

-0.5
Media types are normally LC.

> * Use of equals sign, like <g> = { <s> <p> <o> } .  This is not in
> SPARQL but is in traditional TriG, for compatibility with N3.

Note: you have also put a "." after the named graph block.

> PROPOSED: In our dataset syntax, a "=" MAY appear between the name and
> the graph.

-0.8
(and only a mere touch of compatibility stops that being -0.99)

> PROPOSED: In our dataset syntax, a "=" MUST appear between the name and
> the graph.

-0.99
"=" is owl:sameAs

It's not being used that way here - confusion will result.


> PROPOSED: In our dataset syntax, a "=" MUST NOT appear between the name
> and the graph.

+1

This is the one area where incompatibility with existing trig is no 
problem to me.

Has anyone seen "=" in real TriG in the wild?  I haven't.

>
> * Use of the "graph" keyword, which MUST be used in SPARQL and MUST NOT
> be used in traditional TriG.
>
> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph"
> MAY appear before the name, in a name-graph pair.

+0.1

(I didn't worry about PREFIX; I don't worry about GRAPH)

> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph"
> MUST appear before the name, in a name-graph pair.

-0.99

> PROPOSED: In our dataset syntax, the case-insensitive keyword "graph"
> MUST NOT appear before the name, in a name-graph pair.

0
>
> * Use of curly braces { <a> <b> <c> } around the default graphs.   They
> MUST be used in traditional TriG, and MUST NOT be used in SPARQL.
>
> PROPOSED: In our dataset syntax, triples of the dataset's default graph
> MAY be surrounded by curly braces.

+0

> PROPOSED: In our dataset syntax, triples of the dataset's default graph
> MUST be surrounded by curly braces.

+0.5

> PROPOSED: In our dataset syntax, triples of the dataset's default graph
> MUST NOT be surrounded by curly braces.

-0.99

Caution: "n-quads in TriG"

> * Some designs for carrying for metadata

Should not be a syntax issue.
It's a layer on top of the basic syntax.

> PROPOSED: In our dataset syntax, we'll say that metadata goes in the
> default graph

+0.1: "suggestion", "recommend"
metadata is a nice


> PROPOSED: In our dataset syntax, we'll say that the default graph goes
> inside curly braces and the metadata goes outside curly braces

-0.2
Can't SPARQL.

> PROPOSED: In our dataset syntax, we'll say that metadata goes inside a
> set curly braces after a keyword "meta".
-0.3

> PROPOSED: In out dataset syntax, we'll have a keyword "meta" followed by
> "default" or the name of a named graph, to indicate to readers where the
> metadata is.

-0.9
Can't SPARQL.

>
>
Received on Wednesday, 26 September 2012 14:13:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:51 GMT