Re: Three solution designs to the first three Graphs use cases

On Wed, 2012-02-01 at 17:37 +0000, Andy Seaborne wrote:
> >>> Doesn't the charter say what you want?  It says:
> >>>
> >>>         Care should be taken to not jeopardize existing RDF deployment
> >>>         efforts and adoption. In case of doubt, the guideline should be
> >>>         not to include a feature in the set of additions if doing so
> >>>         might raise backward compatibility issues.
> >>>
> >>> I certainly don't see us doing anything to break SPARQL, and (sorry if
> >>> I'm being slow) I'm not really seeing why you'd have to change your
> >>> internal representation structures, no matter what we decide for
> >>> TriG-type stuff.
> >>
> >> I simply can't afford that additional join.
> >
> > If your systems had to do serious work through an interface that used
> > graph literals as its only way to do graph reference, that would be a
> > problem, yes.   I think in practice we're going to have to do some kind
> > of hybrid approach, and I'm thinking that might solve your problem here.
> >
> > So, anyway, you want quads, a la SPARQL.  Are you okay with the WG
> > mandating that quads always have TriG/state semantics or always have
> > TriG/equality or do you see some other way to address the highlighted
> > use cases (shared crawler, archiving crawler, endorsement, and keeping
> > inferred triples separate)...?
> 
> To me, anything that frames the decision as "mandate" is at odds with 
> the charter text on jeopardize existing RDF deployment.  We know there 
> are many different usage patterns today; we have to start from there.

I think a mandate is fine as long as it's on a new system or a new
format.   For instance, if we decide we need a multigraph format with
formal semantics, and it's *not* N-Quads or TriG, then I don't see a big
compatibility problem. 

> I prefer that we to publish documents as "best practice" notes saying 
> "if you want to do this UC, you can (even should) do it this way".

I think some things, formats and/or vocabularies, need to defined to
make it possible to solve these use cases.   Those definitions will
involve mandates.   The use of those formats/vocabularies would likely
be optional, but if you're going to use them, the spec will say how they
have to be used.

> Annotation triples that record the relationship of URI to graph value is 
> a way of doing that.  It also covers the time cases we discussed today.

I'm not yet convinced it solves the time cases, but I agree it's good
from a compatibility perspective.

    -- Sandro

>  Andy
> 
> >
> >>> I guess the problem is: how do we provide interop between people who are
> >>> currently doing things in different ways?   It looks to me like the
> >>> current designs I'm talking about are all sort of isomorphic,
> >>> transformable into each other at the input and/or output stage, so that
> >>> systems can do whatever they want internally.   Maybe I just haven't dug
> >>> deeply enough.
> >>
> >> Well, there's one approach that is very common (quads) and a bunch that are rare (quints, graph literals, multi triples). In my eyes that doesn't make them equal contenders.
> >>
> >> There's a reasonable argument that quads were popularised by SPARQL, but I don't really think that's the case, and the why is irrelevant anyway.
> >
> > I'm not opposed to quads or SPARQL at all; I'm just trying to understand
> > what's reasonable to add (or even change *shudder*) to provide solutions
> > for the use cases.
> >
> >       -- Sandro
> >
> >
> >
> 
>

Received on Wednesday, 8 February 2012 14:10:52 UTC