W3C home > Mailing lists > Public > public-rdf-comments@w3.org > December 2013

RE: BNF expression of RDF Concepts (ISSUE-176)

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 5 Dec 2013 12:48:27 +0100
To: "'Richard Light'" <richard@light.demon.co.uk>, "'Eric Prud'hommeaux'" <eric@w3.org>
Cc: <public-rdf-comments@w3.org>
Message-ID: <01ac01cef1af$ea475fc0$bed61f40$@lanthaler@gmx.net>
On Thursday, December 05, 2013 12:25 PM, Richard Light wrote:
> > On 05/12/2013 10:28, Eric Prud'hommeaux wrote:
> This would have to be relatively abstract, in that the Concepts
> recommendation isn't specifying a serialization format, like Turtle.

Exactly. I fear that including BNF into Concepts would thus be very
confusing. We tried hard to separate the abstract syntax from concrete
syntaxes in RDF 1.1.

> > Given the timing, it may not be possible to include this at all, or to
> > include this in a normative section. Will you accept either of those
> > outcomes?
> Yes.  I realise that I have come to this discussion at a point where
> you are about to finalise this document. Also, I am interested to
> hear whether there is wider support for this idea from within the
> developer community, but do not take it for granted that such support
> exists.

I personally am against this for the reason stated above. BNF is, IMO, of
very limited use if it isn't describing a data format but a data *model*.
Could you please elaborate a bit on why you think

> it would introduce standard naming conventions, and structures,
> which could be followed in whichever programming language was being
> used for development.  

If RDF triples are stored in a relational database for example, do you think
developers would benefit from the BNF? What if it is stored as JSON-LD in a
database such as MongoDB or perhaps ElasticSearch?

In any case, I've raised ISSUE-176 [1] to track this. We will get back to
you with an official shortly.


[1] https://www.w3.org/2011/rdf-wg/track/issues/176

Markus Lanthaler
Received on Thursday, 5 December 2013 11:49:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:44 UTC