Re: Labelled graphs

On Wed, 2012-04-25 at 15:08 +0100, Andy Seaborne wrote:
> 
> On 25/04/12 14:48, Sandro Hawke wrote:
> >
> > On Wed, 2012-04-25 at 14:06 +0100, Andy Seaborne wrote:
> >
> > [taken out of order]
> >
> >> And there are other things in the charter.
> >
> > Yes, indeed.   Many of us keep saying that other things need to take
> > priority, but perhaps we're not saying that loudly enough, and perhaps
> > our actions (sending lots of email about graphs) speak even more loudly.
> >
> > I would support a plan to fork graphs off onto another meeting time and
> > even another mailing list until there is consensus among the people
> > participating in that alternative forum.
> 
> Yes, for the semantics, not the syntax which (1) is already out there 
> anyway, refining details would be a step forward, and (2) ought to 
> survive future changes/revisions to the semantics.  RDF is extensible in 
> that way!
> 
> ...
> >>> To be clear, are you saying you would like the entirety of this WG's
> >>> output concerning "named graphs" to be a Recommendation for the grammar
> >>> of TriG?
> >>
> >> No.  I'm suggesting we must at least provide that.  It would be a step
> >> forward.
> >
> > Agreed.
> >
> >> Given the discussions, I am not convinced that fixing one semantics is
> >> desirable.  I see different viewpoints, from different use cases, all of
> >> which have merit.  Deciding the semantics now feels like research, there
> >> not being one as input.
> >
> > To me, it feels like what we did in making RDF 2004.
> >
> > (Of course, you could say that was a mistake, but it's hard to know
> > where we'd be otherwise.)
> >
> > The problem is, I think, that the only way to find out if some design
> > works is to convince a lot of people to try it at the same time.   How
> > can you do that?  It looks to me like the way we do that in the Semantic
> > Web community is to make it a W3C Recommendation (or a least Candidate
> > Recommendation).
> 
> In this case, it will be a quite long period to know if it works.  It's 
> not the toolkits - it's the data publishers and data consumers, and the 
> data interchange that is the test of the utility.

Agreed.

> The context is different from RDF 2004, there was a much smaller RDF 
> world then. At that time, the need was a revised standard and more risk 
> was appropriate (speculative design, research, whatever you want to call 
> it).

As I recall, the 2004 group worked very hard to maintain backward
compatibility with the installed user base, which they considered much
too large and important to inconvenience.

So, it's all kind of a matter of perspective.  The community is still
tiny compared to where I believe it will be, if this thing catches on.

But, yes, it is certainly larger now.

> That's not how I see things now - RDF is out there and in use by a much 
> larger community. Hence do the minimum needed and separately, work on 
> more.  If the proposed semantics work out, great.  If they get revised, 
> why also cause the minimum (syntax, graph packaging) to also fallback?
> 
> > I suppose another approach would be to have a back-room chat amongst the
> > people behind some key SemWeb tools (eg Jena).   But is that better than
> > the W3C process?
> 
> It's not a reason to bypass W3C.
> 
> > We could set a very high bar for CR on this, if we
> > want to make sure it doesn't get to Rec until "it actually works".
>  >
> >> I think the best approach is to define the absolute minimum, and publish
> >> the semantics as based on that.  This means if the semantic proposals
> >> are found wanting (not in a technical sense, but in a utility sense c.f.
> >> reification) others can also emerge.

Your mention of reification helps me clarify my concern here: I'm afraid
trig will just be like RDF Reification in the current specs.  Because
it's just a syntax, with no semantics, people use it in different and
incompatible ways.

It seems to me we get exactly one chance to specify the semantics of a
language, and that's when we specify the syntax.   After the syntax is
out there, we can't change the semantics without breaking things,
because everyone is already using it with their own semantics.

(There's an argument that we're past that point already -- that existing
trig and SPARQL usage of named graphs without standard semantics is
what's making it so hard to settle on the right standard semantics.)

> >> This isn't giving up - it's realising there is a minimum and
> >> possibilities on top of the core basics.
> >>
> >>   >  I note that our charter says:
> >>   >
> >>   >           Required features
> >>   >                 * Standardize a model and semantics for multiple graphs
> >>   >                   and graphs stores
> >>
> >> My conclusion currently is that there are different ways of using named
> >> graphs in applications and they are all valuable.  The use cases are not
> >> met by some common semantics choice directly.
> >>
> >> Even if they can all be built on one common semantics (and this itself
> >> is not obvious to me - I can see different strands still running), it
> >> can still end up too complicated in practice.  So we can meet the letter
> >> of the charter and still not improve the situation.
> >
> > Among the people who want to work on this, I'd like to see if we have
> > consensus on a few simple bits, like the sameAs entailment test earlier
> > in this thread, or the idea that the default graph is asserted.
> > Maybe we can do that today, or maybe today's telecon can be spent on
> > other things we need to do.
> 
> Yes but it's up to the chairs as far as I'm concerned (/me says "the 
> right thing").  It might be useful for a group to go off and come back 
> with a complete proposal for discussion in the WG as it may be easier 
> for the wider WG to engage with a complete proposal rather than emails 
> on particular points.  Maybe - different styles work for different people.

Agreed.  I'm fine with whatever is going to get the rest of the
deliverables done, preferably soon.

     -- Sandro

>  Andy
> 
> >
> >      -- Sandro
> >
> >
>

Received on Wednesday, 25 April 2012 14:28:17 UTC