RDF Working Group Teleconference -- 23 May 2012

<trackbot> Date: 23 May 2012

i think i am supposed to scribe - but i didn't do it in a looong time so will probably need some help :)

<scribe> scribenick: yvesr

<sandro> trackbot, start meeting

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 23 May 2012

Guus: propose to accept minutes of last week
... resolve to accept minutes

<manu1> RESOLVED: Accept minutes from last week.

<gavinc> RESOLVED: accept the minutes of the 16 May telecon

Guus: the pending review list is empty
... First, proposal to split the turtle document in two
... turtle / n-triples

<Zakim> manu1, you wanted to voice concerns about TURTLE / N-Triples.

manu1: general concern that it is moving in the wrong direction
... it would be best if Turtle would be *the* language to express RDF natively - primary RDF serialisation language
... I am not going to raise a formal objection

gavinc: ntriples will still be a subset of the turtle language - the main change is to the document structure
... there are a lot of things that only apply to ntriples
... having them in a separate document makes the turtle document easier to write

manu1: could send the wrong message to the RDF community
... turtle should include n-triples and n-quads
... it should be the same language

gavinc: it is saying that n-triples shouldn't have its own media type, quite a strong statement
... we would have quite a lot of objections to that

Guus: it should all be solved by a very clear statement
... the reasons for splitting the document are very strong

manu1: n-triples and turtle have so many similarities that not merging them will be confusing
... to the web developer community

ivan: i understand where manu is coming from, but it is more a question of image rather than technology
... perhaps we should re-brand n-triples as 'mini-turtle'?
... the title should make it clear that it is the stripped-down version of turtle
... the document which describes n-triples is describing a small subset of turtle

<sandro> +0.5 "miniturtle"

gavinc: it should include language saying that you should use turtle

<Zakim> manu1, you wanted to say make it TURTLE Lite and I'm happy.

manu1: make the name of the document turtle-light or mini-turtle and i am happy

<sandro> actually, "microturtle" may be better. It's MUCH smaller than turtle.

gavinc: calling it n-triples is causing problems, because it's not exaclty what is known as n-triples now

cygri: this working group isn't about bringing new stuff to new communities, it is also serving the needs of the existing RDF dev community
... from this point of view it does make sense to split the documents and it does make sense to keep the same name

<ericP> manu1, how do you like "The N-Triples Sublanguage of Turtle"? ('cause i think that we want current N-Triples use cases to migrate to this new form.)

cygri: i would be concerned of inventing new names for things that have been around for a long time

<sandro> how about: RDF N-Triples - a microturtle syntax :-)

<Zakim> manu1, you wanted to talk about existing users.

Guus: let's keep this brief

manu1: the people who are already using it shouldn't be confused by a change of name
... as they're already using it

ivan: gavinc can find something nice

Guus: there are strong arguments for splitting the document into two, i'd propose we resolve that

PROPOSAL: Split the Turtle document into two - turtle and n-triples

<ericP> +1

<sandro> +1

<manu1> +1

<tbaker> +1

<gavinc> +1

<Arnaud> +1

<ivan> +1 with the proviso that the n-triple document's title may be different

<manu1> +1 (as long as we name the new N-Triples document with a clear TURTLE Lite) message.

<sandro> ( TinyTurtle )

<cygri> +1

RESOLUTION: Split the Turtle document into two - turtle and n-triples

Guus: first question was the whitespace question in Turtle

gavinc: this is whitespace in n-triples
... if there are whitespaces rules, they are at the top of the appendix, not in the grammar part of the appendix, and they should be in the grammar part as well

Guus: so we reached consensus on this

gavinc: yes, we reached consensus

ericP: there was some discussions about using exactly one whitespace

gavinc: the grammar should be somewhat loose
... you can have multiple empty lines, multiple whitespaces

<sandro> Maybe "Useful Subsets of Turtle" *sigh*

gavinc: there should be some canonicalisation rules that enable one triple to be expressed in exactly the same way

ericP: canonicalisation of order as well?

<cygri> gavinc++

gavinc: it could include that as well, but triple-specific at first

ericP: is there a value to writing those rules as SHOULD, as parser-write will have to handle all cases anyway

<Zakim> sandro, you wanted to ask about rdf canonicalization (including bnodes)

<swh> I see the value of having a recommendation for serilising triples

<swh> but \r\n for e.g. isn't grep friendly

sandro: it would be interesting to have the whole document, including bnodes, to be canonicalised

<gavinc> mmm... graph isomorphism for fun and ... no, not profit

sandro: it would be nice to be able to compare whether two graphs are equal by just comparing their documents

<swh> canonicalising bNodes is hard

<ericP> i'd rather produce the profile when we have a whay to do whole document canonicalization

ericP: if we waited for the canonicalisation, we would have a big chunk to give to the world

<gavinc> canonicalising bNodes is not only hard but GI-Hard

sandro: canonical triples making it easier to write parsers

<Zakim> manu1, you wanted to say this applies to JSON-LD Normalization.

manu1: we have been working on this canonicalisation problem since a year
... right now we serialize it to nquads (in json-ld)

<gavinc> http://en.wikipedia.org/wiki/Graph_isomorphism_problem

manu1: the tricky part is figuring out how many spaces you put between things

<manu1> http://json-ld.org/spec/latest/rdf-graph-normalization/

manu1: the very tricky part is figuring out the canonicalisation algorithm
... it can get very complicated
... in the case of http://json-ld.org/spec/latest/rdf-graph-normalization/ the output is some very specific n-quad document
... the graph normalisation algorithm is very hard

swh: some times you can't afford to do canonicalisation

<Guus> acl swh

swh: especially on large graphs

<gavinc> sandro++

<cygri> sandro++

sandro: if the graph happens to be canonical, then the bytes in the documents will be the same for the two same graphs

<ericP> we speak of `grep`, but i think the only tool that's enabled by canonicalized whitespace is some peculiar use cases of `cut`

sandro: that's one benefit of doing so
... assuming canonicalisation handles b-nodes and triple ordering

manu1: as soon as you add b-nodes to the equation, it starts to be very hard to process large graphs
... we have not found a polynomial-time algorithm to do that

<sandro> isnt graph isomorphism np-complete?

manu1: the canonicalisation itself is easy to define though

<sandro> +1 :-)

<gavinc> sandro, GI-Hard

<ericP> Guus: how much does this matter to the Turtle document

<gavinc> got it's very own complexity class

Guus: let's move on to the second issue

<manu1> gavinc: This doesn't have anything to do with TURTLE, so we can move on.

<sandro> Ah, I see.

<ericP> gavinc: because we've separated N-Triples, absolutely none

sandro: strict vs. loose parsing - http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0408.html
... I tried implementing Turtle and realised I could make it much easier if I didn't bother to check in the lexer little bits of the URI syntax
... the grammar of Turtle enforces some rules about what can be in an IRI

<LeeF> Is there a test case that distinguishes between it being enforced in the lexer versus being enforced higher up in the chain?

<LeeF> Right, that's what I was expecting (what Sandro just said)

sandro: I could write a legitimate parser by taking it out
... We should at least state it

<swh> I don't see how it has any baring on the grammar

cygri: two issues - is it ok to have a definition of what an IRI is in Turtle?

<sandro> I've backed off the "fix them up" idea.

<gavinc> +q to talk about the nature of the grammar

cygri: the other issue - editorial issue: how exactly valid IRIs in Turtle are described in the document
... an option is to not define what's inside the angle bracket, and point to the IRI RFC

sandro: added to that there is a conformance issue
... can i have a conformant Turtle parser that accepts IRIs that are not in the Turtle grammar
... the tradition in our community has been that it was OK

<Zakim> gavinc, you wanted to talk about the nature of the grammar

sandro: as long as I can call it a Turtle parser without that, it's OK

gavinc: the grammar specifies a grammar, not *the* grammar
... if you write a different grammar, for example one that uses different production rules for IRIs, it still meets the same rules

<sandro> sandro: As long as I can implement a turtle parser that doesn't reject bad syntax-IRIs, I'm okay.

gavinc: what matters is if i put something that is not an IRI inside a <..>
... you can't have an RDF graph where one of the node isn't a literal or an IRI

sandro: checking whether something is in an IRI is incredibly hard
... it's programmatically intractable
... what you can do is to have some heuristics checking whether it might be ok

cygri: we should tightened up the conformance clause in Turtle
... if there was another grammar that ends matching the same strings, then that's conformant

<swh> +1 to cygri

<gavinc> +1

<ericP> +1

cygri: the Turtle language is not its grammar

<pchampin> +1

<sandro> +0 cyrgi. I can live with conformance defines Turtle Document, and says a Turtle Parser handles Turtle Documents, and is silent on how to handle non-Turtle documents.

cygri: there are different needs for conformance for different situations
... it naturally gives rise to a Turtle validator - it's obvious that we need it
... it should dig into the IRIs and check their validity

<Zakim> sandro, you wanted to ask about negative syntax tests

sandro: that's reasonable to me
... we should include negative syntax test
... it would be OK to fail the negative syntax test

cygri: according to what I said earlier, I would say no

<ericP> for the implementation report, can we go to PR witout any implementations passing the negative syntax tests?

sandro: we should mention this class of things that are Turtle validators
... and that those negative tests apply to those

<sandro> sandro: Maybe the negative syntax texts are only for Turtle Validators.

cygri: the html5 spec spells out all that, a good example to look at
... validators, user agents, etc.

<ericP> i think talking about implementations, conformance levels etc, will make the spec much much bigger and more opaque

Guus: I'd like to handle that while we're at the CR stage

<cygri> ericP, read the html5 conformance section before saying that

<sandro> cygri, you're talking about http://www.w3.org/TR/html5/infrastructure.html#conformance-requirements ?

ericP: i think it's a 'do nothing' resolution

<cygri> sandro, yes

Guus: my take is that it requires a small rephrasing of the conformance note

<gavinc> It requires WRITING a conformence clause

sandro: something that says that the grammar can be drammatically simplified

cygri: it is a bad idea to say that - chances are that if you do not check the IRIs, you might break your system - because other components might
... I think it's not a good idea to tell to people they can cut corners

<gavinc> ... ....

cygri: it's OK to phrase conformance slightly differently, but we shouldn't encourage to not check that

<gavinc> There are no RDF graphs that cannot be represented in Turtle

<swh> we're talking about extreme corner cases here

sandro: most systems are opaque with respect to IRIs

cygri: the most used parser at the moment does check them

<sandro> manu, any IRI with | in it, for instance.

cygri: we shouldn't specify error-handling - it is unlikely that there is one behavior that works for all situations
... we should leave the corner-cases unspecified
... the cost/benefit decision is for implementers to make

Guus: some of these things we can still handle at CR time

sandro: we don't have to handle it now

Guus: each meeting seems to float towards a Last Call graph, but we're still not there this week - i hope we can do it next week

manu1: I feel pretty strongly that we need named quads in turtle

<swh> we have discussed it a lot

<cygri> manu1, there were a few emails about this

<swh> Garlik/Experian WILL formally object to including quads in turtle

<cygri> 2000 or so

<gavinc> This issue has been raised a number of times. Strong objections were raised as to making text/turtle produce quads rather than Triples

manu1: if we don't put it in there, people are going to abandon Turtle in the long run

sandro: there's nothing wrong with that - people will move over to a better language

manu1: if we solve that problem now, the cost to society is lower

sandro: perhaps we could specify it as an extension to this language

manu1: such migrations are not painless

<gavinc> Please refer to perma thread on @graph, TriG, etc

manu1: is there anyone in the group who thinks that we don't need named graphs?

<LeeF> Just roundtrip with trig instead, no?

<sandro> manu, the problem is that GRAPHs turns out to be very hard for this group to sort out.

manu1: it would be good to be able to go from JSON-LD to Turtle and back to JSON-LD

<Zakim> manu1, you wanted to raise issue about NQuads in TURTLE...

<cygri> ericP, twoples were a mistake already. uniples!

sandro: I think Turtle is well-understood as not including named graphs
... if we include them, we need to come up with a different name

<ericP> +1 to sandro, we'll need a name like "Turtle" for a "turtle-like" language

<LeeF> I agree with Sandro.

<LeeF> SteveH strongly agrees.

<gavinc> Many people stronly agree

manu1: I am worried it's language proliferation all over again

ivan: I disagree - I think the question about whether named graphs is important is rethorical

<sandro> I am totally sympathetic to manu's position .... but I don't think we can do it that way.

ivan: it has been the main topic of discussion in the group for months
... there should be a separate TriG - Turtle + Named Graphs
... a number of existing deployment need to know in advance what's in the data
... whether it is just Turtle or whether it includes Named Graphs as well

<sandro> -1 on Steve's requirement that graph-syntax and and turtle be disjoint.

ivan: any Turtle documents should be a valid TriG document - it's not a different language

<pchampin> +∞

<sandro> +1 any turtle documement is a graph-syntax language.

<manu1> I would be fine with TURTLE 2.0 including graph syntax.

ivan: it is separating the concepts very clearly

<swh> objects is too strong

<manu1> (but this is something we need for Web Payments, PaySwarm and JSON-LD)

<swh> exactly :)

ivan: when we get to the point where TriG is defined, JSON-LD has a round-trip with TriG

manu1: I am deferring to the group, but I think it is a mistake

Guus: we're going to leave at that for the moment
... is next week possible for the Last Call?

gavinc: in the todo list, we need to find the balance between sandro and cygri's points

ericP: validation, conformance, implementation may make the document more complicated

<gavinc> +1 to cygri writing some text! :D

cygri: i could draft five sentences that I'd like to see in the conformance section

<sandro> +1 richard proposing text for Conformance

<scribe> ACTION: cygri to draft five sentences for the conformance section in Turtle [recorded in http://www.w3.org/2012/05/23-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-173 - Draft five sentences for the conformance section in Turtle [on Richard Cyganiak - due 2012-05-30].

<manu1> For the record - I'm fine with N-Triples renamed as (Turtle Lite/Micro/etc.), Turtle as Turtle, TRiG as Turtle 1.1

<sandro> sandro: And of course my non-validating Turtle Parser is going to allow @prefix/prefix to mix with period and non-period.

Guus: let's move on to JSON-LD
... let's not have a long discussion on this

JSON-LD Syntax

<manu1> http://json-ld.org/spec/ED/json-ld-syntax/20120522/

Guus: does the WG want to take part of this work?

<gavinc> -1 to publishing JSON-LD so long as it does not contain a mapping to and from RDF

Guus: having looked at the thread of discussion, the formal link to RDF is the key issue

manu1: JSON-LD does have a mapping to RDF, although not in that document
... it is in the JSON-LD API

ivan: for now it is a community group document - we need a normative reference

<cygri> +1 to publishing a JSON-LD spec if the link to RDF can be added explicitly to the spec

<gavinc> 'cause it's the RDF WG

manu1: you're asking to put an algorithm in the JSON-LD syntax

<cygri> gavinc++

ivan: if the JSON-LD APIs are mature enough for standardisation, we could publish the two documents
... if not, the RDF-related part have to be part of the JSON-LD document

Guus: would it be possible?

manu1: it wouldn't make any sense from an editorial perspective
... the conversion from one language to another is an algorithmic thing

<gavinc> HTML5 defines both, Turtle defines both, XML defines both

sandro: JSON-LD is a syntax without semantics atm - we're suggesting it should have semantics, that mapped to RDF

manu1: if the issue is that it's not clear what the RDF mapping is, then it is in the JSON-LD API
... it would be weird for the group to publish one document without the other
... that API document needs to be published through the W3C in some form either way
... we shouldn't make a big editorial decision to tackle an issue around how the document will be published

<Zakim> ericP, you wanted to discuss mechanics of a community WD review and tracking down how to interpret the JSON-LD document

ericP: we could have a first public working draft that would point to one fairly stable document that has the API, stating that it will be standardised
... are the semantics the way that the developers are going to use JSON-LD?
... there is a community that consumes JSON as a wire format, and who won't commit to the JSON API
... what makes editorial sense for one community doesn't alienate another community

<manu1> My current concerns about JSON-LD in RDF WG:

<manu1> * The primary contributors of JSON-LD are not Invited Experts in RDF WG and

<manu1> thus can't take part in the conversation on the mailing list / in the group.

<manu1> * Bringing the RDF WG up-to-speed with JSON-LD - what is the most efficient way?

<manu1> * Do a FPWD as soon as possible after everyone knows what is going on.

<manu1> * How are issues handled? JSON-LD issue tracker, or RDF WG issue tracker?

<manu1> * Time-box JSON-LD stages to ensure rapid progress?

<Zakim> manu1, you wanted to say that we could do a FPWD for JSON-LD API

ivan: if this group publishes both the syntax and the API, then there has to be some clearer references, and then there is no problem
... there is no major issue in the split in two documents
... however only one document was submitted to this WG
... why was the other document omitted?
... let's try to see if we can publish both documents within this WG

Guus: please come back to the WG with how you want to go forward

<cygri> personally, i'm not much interested in the JSON API, but I'm very interested in the RDF mapping

<sandro> but that doesn't mean we're interested in both.

Guus: the group is only interested if there's a clear link to RDF, which currently is in the API
... please send your message with also a link to the API

manu1: ok

<Arnaud> I won't take more time on the call but I'm unclear as to the status of the JSON-LD spec

<manu1> Arnaud: JSON-LD Syntax spec is ready for a FPWD... this group is attempting to decide if they're going to publish it as a FPWD.

RDF Concepts WD

<Arnaud> and what it will take from a legal point of view for the WG to pick it up

<ivan> Arnaud: at the moment it is a document produced by a community group

Guus: should we do a republication of the RDF Concepts Working Draft

<gavinc> Would like to publish with N-Triples FPWD, Turtle LC

cygri: there are still a number of issues open, but only in two categories

<Arnaud> there is a defined process to move a community spec to a wg, regarding copyrights and licensing commitments

cygri: 1) editorial stuff, 2) graphs
... the second category might take a bit more time

<Arnaud> and I think this is the first instance of practicing this process

cygri: all the rest have been sorted out - so it's a good time to publish a revised WD

ivan: do we really have a formal decision on the HTML datatype?

Guus: yes

<cygri> http://www.w3.org/2011/rdf-wg/track/issues/63

<cygri> RESOLVED: to accept the resolution to ISSUE 63 as proposed in http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0222.html but without the definition of the canonical mapping

ivan: then I am perfectly happy publishing a revised draft

PROPOSED: Publishing a revised version of RDF Concepts

<gavinc> +1 perfer timing with Turtle LC, N-Triples FPWD but won't stand in the way

<cygri> +1

<ivan> +1

<pchampin> +1

<tbaker> +0

<AZ> +1

<swh> +1

<LeeF> +1

<cygri> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#

<Arnaud> +1

<sandro> +0

RESOLUTION: Publishing a revised version of RDF Concepts

<gavinc> Link with version encoded http://dvcs.w3.org/hg/rdf/file/bb711b18e3fc/rdf-concepts/index.html

Guus: we're now out of time

<gavinc> +1 to 15 more minutes to resolve the Graph issues

<sandro> +1

<cygri> +1

<pchampin> +1

Named Graphs

<cygri> ISSUE-5 Graph literals http://www.w3.org/2011/rdf-wg/track/issues/5

cygri: the first issue is ISSUE-5 on graph literals
... is it necessary to define some literal datatype for graphs?

<Arnaud> sorry, I have to drop off

cygri: the proposal is to close this issue - we don't need such a datatype

<cygri> PROPOSED: Close ISSUE-5 ("Should we define Graph Literal datatypes?"), saying No, we should not.

<gavinc> Peter F. Patel-Schneider votes +1 to no graph literals

<swh> +1

<ivan> +0.5

<Guus> Andy: +1

<AZ> +0

<sandro> +0

<gavinc> +1

<tbaker> +0

<cygri> there was +1 from pat too

<Guus> +1

<LeeF> +1

<gavinc> Pat Hayes votes +1

RESOLUTION: Close ISSUE-5 ("Should we define Graph Literal datatypes?"), saying No, we should not.

<cygri> ISSUE-28 Syntactic nesting of g-texts http://www.w3.org/2011/rdf-wg/track/issues/28

Guus: moving to ISSUE-28

cygri: do we need to support nesting in graphs? especially as N3 supports it

<cygri> PROPOSED: Close ISSUE-28 ("Do we need syntactic nesting of graphs (g-texts) as in N3?"), saying No, we do not -- the use cases presented to the WG can be addressed without, and making syntactic nesting pay off would require additional logic machinery that's beyond this WG's scope.

cygri: is it OK to do without that?

<gavinc> Peter F. Patel-Schneider votes +1

<AZ> +1

<gavinc> AndyS votes +1

<sandro> +0 okay with proposal; don't agree it's beyond our scope. still, compatibility with sparql requires no nesting of datasets

+0.5

<swh> +1

ivan: a different statement is that it is beyond what the WG can reasonably do in a limited time

<ivan> +1

+0.5

<AZ> +1

<LeeF> +1

<pchampin> +1

<Guus> +1

<sandro> +0.5

<swh> +0.5

<gavinc> +1

RESOLUTION: Close ISSUE-28 ("Do we need syntactic nesting of graphs (g-texts) as in N3?"), saying No, we do not -- the use cases presented to the WG can be addressed without, and making syntactic nesting pay off would require additional logic machinery that's beyond this WG's timeframe

<tbaker> +0

<cygri> ISSUE-29 Do we support SPARQL's notion of "default graph"? http://www.w3.org/2011/rdf-wg/track/issues/29

<swh> [for the record I think it would be huge mistake]

swh: trying to standardise nested graphs without implementation experience would be a mistake

<sandro> swh: "it" being "standardizing nested graphs"

<LeeF> Stop causing trouble, steve :)

<swh> +1 to LeeF

<cygri> PROPOSED: Close ISSUE-29 (Do we support SPARQL's notion of "default graph"?'), Yes, we do.

<gavinc> Peter F. Patel-Schneider votes +1 to RDF datasets, even without semantics, provide the necessary machinery

cygri: should we include a default graph

<gavinc> AndyS votes +1

<sandro> +1

cygri: there's an obvious case for it

<swh> +1

<ivan> +1

<AZ> +1

<Guus> +1

<gavinc> PatH votes +1

<LeeF> +1

<gavinc> +1

<tbaker> +1

RESOLUTION: Close ISSUE-29 (Do we support SPARQL's notion of "default graph"?'), Yes, we do.

<cygri> ISSUE-30 Relation RDF Datasets with multiple graphs http://www.w3.org/2011/rdf-wg/track/issues/30

<cygri> PROPOSED: Close ISSUE-30 ("How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?"), saying we will use SPARQL's notion of RDF dataset as much of the foundation of our handling of multiple graphs.

cygri: this issue is almost not worth spending any time on it

<sandro> +1

<swh> +1

<ivan> +1

<gavinc> +1

cygri: in terms of the abstract syntax we accept the SPARQL thing: pairs of IRIs and graphs and a default graph

<AZ> +1

<gavinc> Peter F. Patel-Schneider: +1 to RDF datasets, even without semantics, provide this facility

<Guus> +1

<gavinc> AndyS: +1

<tbaker> +1

<gavinc> PathH: +1

<gavinc> +1

RESOLUTION: Close ISSUE-30 ("How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?"), saying we will use SPARQL's notion of RDF dataset as much of the foundation of our handling of multiple graphs.

<cygri> ISSUE-33 Mechanism to refer to sub-graphs and/or individual triples http://www.w3.org/2011/rdf-wg/track/issues/33

<cygri> PROPOSED: Close ISSUE-33 ("Do we provide a way to refer sub-graphs and/or individual triples?"), with the understanding that datasets can be used to refer to sub-graphs and individual triples.

<cygri> [edit]

cygri: there was a proposal that we should not have graph identifiers, but triple identifiers

<gavinc> Peter F. Patel-Schneider: +1 to RDF datasets, even without semantics, provide enough here.

cygri: counter-argument was that we don't really need that - graphs with one triple are OK

<gavinc> PatH: +1

<gavinc> AndyS: +1

<sandro> +1 triples and subgraphs are special cases of graphs

cygri: and then we don't need to do anything special about it

<ivan> +1

<FabGandon> +1

<Guus> +1

<gavinc> +1

<tbaker> +1

does it address the sub-graph case

<sandro> (understanding that this does NOT rule out sharing blank nodes between named graphs)

<pchampin> +1

yvesr: does it tackle the sub-graph issue as well?

cygri: you can create a new graph for the sub-graph, it is an implementation issue to deal with that without bloating the storage

<sandro> +1

<Guus> +1

cygri: happy to find some phrasing that makes that clearer though

<gavinc> AndyS: +1

<gavinc> PatH: +1

<tbaker> +0.5

<ivan> +1

<cygri> ACTION: cygri to work with yves on informative text regarding avoiding duplication for subgraphs [recorded in http://www.w3.org/2012/05/23-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-174 - Work with yves on informative text regarding avoiding duplication for subgraphs [on Richard Cyganiak - due 2012-05-30].

<swh> +1

<LeeF> +1

RESOLUTION: Close ISSUE-33 ("Do we provide a way to refer sub-graphs and/or individual triples?"), with the understanding that datasets can be used to refer to sub-graphs and individual triples. This does NOT rule out sharing blank nodes between named graphs.

<Guus> trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

23 May 2012

Attendees

Contents

JSON-LD Syntax

RDF Concepts WD

Named Graphs

Summary of Action Items

Scribe.perl diagnostic output