Re: ? the graph imperative [ Re: RSP call on 10.6

Hi James - There is nothing to prevent all the statements of a stream
element from being in the default graph - the named graph can be empty.
This does indeed seem like the logical approach when using vocabularies,
like SSN or HL7, where there is a reified Observation that has temporal
properties as well as other data properties.  The named graph is really
there for vocabularies that *don't* have such an observation concept.

I think the best way to tackle this is to try to develop some examples to
see if it is possible to get something reasonable out of the structure as
it is set up. I was planning on working on the examples next anyway.

In addition to the two running examples I had planned originally, we could
add, say, an example where the timestamp predicate is
https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationResultTime or
http://purl.oclc.org/NET/ssnx/ssn#observationSamplingTime

Tara

On Sun, Jun 12, 2016 at 1:48 PM, james anderson <james@dydra.com> wrote:

> good afternoon;
>
> at the close of the call, i raised a question about why a model was chosen
> which requires that each element be described by statements in a single
> graph.
>
> the response from the call’s participants was inconclusive as to the
> necessity.
> “punctuation” was suggested as a reason, but that does not convince as it
> conflates a processing constraint with the encoding and that in turn with
> the data model.
> as the issue is presented in the wiki, however, several alternative means
> would exist to effect punctuation without involving the graph term to this
> end.
>
> since then call, i looked for use cases which employ such a model, but i
> found none.
> everything i found keeps the element statements in the default graph - or
> at least in the same graph as the statement which associates the element
> with a temporal value.
>
> if one retains the requirement, that the temporal qualification is in the
> default graph, then the general form of a graph pattern which would project
> the element is something on the order of
>
> { ?predicate a rsp:TemporalPredicate .
>    ?element ?predicate ?temporalValueOrResource .
>    { { ?element domain:predicate ?domainValue }
>       union
>      { graph ?element { ?subject domain:predicate ?domainValue } }
>       union
>      { graph domain:graph { ?element domain:predicate ?domainValue } }
>    }
> }
>
> while the rsp proposal limits the model to
>
> { ?predicate a rsp:TemporalPredicate .
>    ?element ?predicate ?temporalValueOrResource .
>    { graph ?element { ?subject domain:predicate ?domainValue } }
> }
>
> problematic is, this does not describe the data models which are now used
> and there is no clear advantage this change.
>
> best regards, from berlin,
> ---
> james anderson | james@dydra.com | http://dydra.com
>
>
>
>
>
>