some options for issues#rdfSemantics

I just updated the entry for rdfSemantics in the issues list. I'ts as
neutral as I can manage. Please try to prepare for straw polls on these
3 options tomorrow:


        some notes by DanC in preparation for 18 Oct telcon, based on 4
        Oct discussion:
        
           proposal:
           LC design
           redundancy
            optional
         parameterized
           entailment
         query options
        dataset
        dataset
        dataset
        service options
        service may
        support any
        dataset(s) it
        chooses, by
        loading from the
        web, by
        inference, etc;
        must fail if a
        sepecific
        dataset is
        requested and
        not supported
        (same as LC)
        service may
        support any
        dataset it
        chooses, and in
        any entailment
        mode it chooses.
        Entailment modes
        include rdf
        simple
        entailment,
        abstract syntax
        entailment, RDFS
        entailment, etc.
        (e.g. OWL DL
        entailment, OWL
        full entailment)
           use case:
           results of
            querying
        equivalent graph
           should be
         equivalent (14
              Sep)
        No
        yes, though
        clients need to
        be prepared to
        ignore
        redundancy in
        answers
        yes, though
        clients need to
        be sure they're
        talking to a
        SPARQL service
        that does the
        right kind of
        entailment
           use case:
        Building a Graph
            (14 Sep)
        yes
        no; a service is
        never obliged to
        return redundant
        solutions
        yes; a service
        that advertises
        "abstract
        syntax"
        entailment gives
        the desired
        answer
          spec impact
        none
        change
        "subgraph" to
        "rdf simple
        entailment";
        allow redundant
        bnode answers
        (not clear how
        this interacts
        with optional
        etc. though the
        fact that the
        tests already
        work this way
        suggests it
        doesn't)
        change
        "subgraph" to
        "appropriate
        entailment";
        define abstract
        syntax
        entailment and
        choose a URI for
        it; chose a URI
        to rdf simple
        entailment;
        perhaps
        standardize URIs
        for RDFS,
        OWL-DL, OWL-Full
        entailment
          test impact
        tests with
        sorted results
        are OK; test
        with unsorted
        results also
        need indexes or
        other nonces
        that distinguish
        otherwise-redundant results
        none; the tests
        already work
        this way
        add entailment
        parameter to
        manifests; add
        tests for rdf
        simple
        entailment vs
        abstract syntax
        entailment vs
        RDFS entailment
        (plus tests for
        interactions
        with optional
        etc.?)
         implementation
           experience
        several service
        implementations
        (ARQ, librdf,
        [what's steveH's
        thing
        called?], ...)
        all service
        implementations
        of LC spec (ARQ,
        librdf, [what's
        steveH's thing
        called?], ...)
        plus any
        implementations
        that use lean
        graphs (e.g.
        cwm)
        librdf, ARQ
        support
        "abstract
        syntax"
        entailment; cwm
        supports
        rdf-simple
        entailment. I
        gather steveH's
        system supports
        RDFS entailment,
        or something
        close (hmm...
        how does this
        interact with
        the GRAPH
        stuff?)
        support
        WG, as of 14 Jun
        ?
        bparsia@isr.umd.edu, franconi@inf.unibz.it, ...?
        opposition
        pfps, ...?
        ?
        ?



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E