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

>>> 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 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".

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.

 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, 1 February 2012 17:38:32 UTC