

dataset stuff as an extension or optional feature

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 04 Jun 2013 10:28:34 -0700
Message-ID: <51AE23C2.40508@w3.org>
To: Steve Harris <steve.harris@garlik.com>
CC: RDF WG <public-rdf-wg@w3.org>, "public-rdf-comments@w3.org Comments" <public-rdf-comments@w3.org>
On 06/03/2013 02:40 AM, Steve Harris wrote:
> As may be obvious I'm very much in favour of testing out changes to the language in the real world before committing them to specs. I (obviously) understand that not everyone agrees, but that's an opinion I've formed from having worked with various SW-related specs over the years, and being involved in some of the groups.
> The cost of non-standard extensions to the specs is pretty small - look at SPARQL 1.0, practically everyone extended that, but the extensions were brought together quite successfully in SPARQL 1.1.
> The counter cost, of including badly thought out features (arguably like bNodes-as-variables themselves) is pretty high.
> There are often features that are no-brainers, and everyone agrees should have been in earlier specs, but clearly this isn't one of those.

I'm trying to figure out if this would work.  It might be a good path 

As a thought experiment, lets consider that the WG decides to not allow 
blank node graph names and also to not follow my semantics proposal from 
yesterday [1].    So then a group of us (everyone who supports these 
proposals -- maybe just me, maybe dozens of people) publishes a spec, 
"Enhanced RDF Datasets".    Let's say that an Enhanced Dataset (1) can 
have blank node graph names, (2) has the "bound" semantics from [1], and 
(3) is recognized by some content in the dataset (something like { <> a 
:BoundDataset }).

How would this end up any different from doing this in this WG's 

In terms of normativity/conformance, I think it would be almost exactly 
the same as defining these features in rdf-concepts/rdf-mt and saying 
the implementations MAY support them.    Since semantics are already 
optional, the only change is that it's saying Datasets MAY allow blank 
node graph names.  But we have lots of evidence that they already do, 
and you seem to  be suggesting we continue to allow that, to support 
experimentation, etc.

So I think the only disagreement is over (1) editorial issues (things 
not affecting conformance, like whether the concepts are presented as 
optional in rdf-concepts or in a NOTE or SUBMISSION), and (2) whether 
datasets MAY, SHOULD, or MUST support blank node graph names.     Since 
we keep talking about Skolemization as an option, it's pretty clear to 
me no one is arguing for MUST.  So then it's between MAY and SHOULD.   
On that, I don't have strong feelings.

So, that gives us several options, all of which seem okay to me. There 
are lots more options that are slight variations on these, I'm sure.   
In order of my decreasing preference:

D1.   We include something like bound semantics [1] and 
blank-node-graph-names in rdf-concepts (and rdf-mt if appropriate), with 
the blank-node-graph-names being optional, as a "SHOULD", with 
Skolemization provided as an alternative.   (I'm not entirely clear what 
the SHOULD applies to, since I don't exactly know what an 
"implementation" of RDF is.     But I think we can handle that)

D2.   Same, but with a "MAY"

D3.   We document this stuff instead in a WG NOTE, and rdf-concepts 
mentions it briefly

D4.   We document this stuff in a WG NOTE, and rdf-concepts holds its 
nose and pretends it doesn't exist

D5.   The WG ignores this stuff, and some rebel band (just me, if 
necessary) publishes it as a Semantic Web IG NOTE or a Team Submission 
or even some non-W3C document.

D6.   The WG says something in its specs that makes D5 require violating 
the RDF specs.

I think I can live with D1-D5.    And D1-D3 will leave me feeling okay 
(maybe even proud) of how we handled this.

So what's left is:
    - is this spectrum of options about right? is my analysis right?
    - where on the spectrum is WG consensus (probably use WBS for that; 
maybe leave it "At Risk" and get wider feedback)
    - hammering out the details of something like [1] among the people 
who want something like that
    - make sure there's nothing in the specs that contradicts/forbids 
this stuff (avoiding D6).

Sound reasonable?     BTW, I plan to attend tomorrow's call; I may have 
said I wouldn't due to being at SemTechBiz, but the timezones make it okay.

         -- Sandro

[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0020.html
Received on Tuesday, 4 June 2013 17:28:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2013 17:28:40 UTC