Re: RDF WG Resolutions

Apologies for not making the meeting. Edinburgh would likely take the
opposite view and support blank nodes as graph names. This is not
really a last minute addition, it has been something that we have
advocated from the beginning on the grounds of consistency -- fixing
this now simply means it doesn't have to be fixed in a future
iteration of the standard. I am pleased that the WG has decided to
reverse the earlier decision to disallow this. Since blank nodes act
as variables in the SPARQL I don't think there is a serious
inconsistency.

One thing that is not clear to me is whether this means that the
"default graph" is still a special case, or if it is just another
graph that could be referred to by statements through a bnode.

Cheers,
-w

On Wed, 15 May 2013 18:10:55 +0100, Richard Cyganiak <richard@cyganiak.de> said:

    > It is likely that DERI will formally object to the resolution to
    > allow blank nodes as graph names. It's not required to fulfil
    > RDF-WG's charter, throws RDF and SPARQL out of alignment, and
    > has significant implementation costs. This is something for a
    > future N3 working group, not something that should be added at
    > last minute before LC.  Richard


    > On 15 May 2013, at 17:10, Gregg Kellogg <gregg@greggkellogg.net>
    > wrote:

    >> We have two resolutions from the RDF WG today:
    >> 
    >> The first is a resolution to allow Blank Node identifiers to be
    >> used as graph names. If this stands, it resolves an at-risk
    >> issue:
    >> https://www.w3.org/2013/meeting/rdf-wg/2013-05-15#resolution_2. We
    >> shouldn't try to remove this from the LC2 document yet, as the
    >> last word may not have been said on this.
    >> 
    >> The second resolution allows us to publish
    >> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/WD/json-ld-api/20130516/index.html
    >> as LC2 tomorrow:
    >> https://www.w3.org/2013/meeting/rdf-wg/2013-05-15#resolution_3.
    >> 
    >> The assumption is that, prior to PR, we will resolve the newly
    >> introduced useNativeTypes issue by moving the flag from fromRdf
    >> to expand, with a pass-through from other algorithms. This
    >> would put the application programmer in charge of using native
    >> or canonical representations of numbers and booleans, and
    >> eliminates any round-tripping issues. If expanding with
    >> useNativeTypes=true, values with a numeric or boolean datatype
    >> but a string representation would be converted to JSON numbers
    >> or booleans, including xsd:decimal. If set to false, native
    >> types would be transformed back to either xsd:boolean or
    >> xsd:double values. Of course, we may want to tweak this some
    >> more.
    >> 
    >> Gregg Kellogg gregg@greggkellogg.net
    >>

Received on Wednesday, 15 May 2013 17:32:27 UTC