See also: IRC log
<trackbot> Date: 04 January 2012
hi
<Guus> we may need a scribe volunteer if Thomas doesn't join
I can scribe
<scribe> scribe: pchampin
<scribe> scribenick: pchampin
<danbri> Guus, your audio is fine
PROPOSED to accept the minutes of the 21 Dec telecon: http://www.w3.org/2011/rdf-wg/meeting/2011-12-21
RESOLVED to accept the minutes of the 21 Dec telecon
PROPOSED: to accept the minutes of the 21 Dec telecon
RESOLUTION: to accept the minutes of the 21 Dec telecon
<gavinc> ACTION-124?
<trackbot> ACTION-124 -- Gavin Carothers to raise issue around formated text literals -- due 2011-12-07 -- CLOSED
<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/124
<danbri> i lost audio
<danbri> via high-pitched screech
<zwu2> Happy New Year!
<danbri> regrets from me for next week (project meeting)
http://lists.w3.org/Archives/Public/public-rdf-wg/2011Dec/0181.html
<cgreer> I'll volunteer for one
guus: RDFa is going to LC, so we will have to review the 4 documents
<LeeF> what are the 4 documents?
david: it would be good to have volunteers
guus: I'd be happy to volunteer for the primer
<ivan> to LeeF: rdfa core, rdfa+xhtml, rdfa lite, rdfa primer
david: would be good to have someone from the "named graph" discussion have a look at RDFa
<AndyS> I think it uses it as the base, not the name
<gavinc> AndyS, yeah, it doesn't talk about name
david: RDFa uses URIs to identify (name?) documents; similar to the discussions that occured in this group recently about graphs
<davidwood> AndyS, really?
<AZ> what's the deadline for this ?
<danbri> (I'd like to understand this RDFa issue better...)
<cgreer> I'll do lite, with the caveat that I may flood email list with questions
<davidwood> Manu's message says, "submit your comments before January 15th 2012"
<AndyS> davidwood, IIRC (so do check that!)
<AndyS> ... I thought it was triples in a doc c.f. triples in Turtle doc. Could be wrong, has been a while
ivan: (RDFa WG hat on) documents 'RDFa Lite' and 'XHTML+RDFa' are not of big interest for this group
<gavinc> Yeah, but RDFa Lite is an INTERESTING publishing profile
<davidwood> RDFa Core refers to RDF Concepts in relation to graph definition.
<davidwood> (sec. 3.7)
ivan: (they may be interesting
for individuals, of course)
... the most technically interesting is 'RDFa core'
<AZ> I'd like to read RDFa Core but 115th January is way too early for me
gavin: I think RDF lite is intersting to see which minimal set was deemed useful by the RDFa WG
ivan: regarding the use of URIs
in RDFa, I don't think it is related to named graphs
... the URI of the RDFa document can appear as the subject of a
triple, but that's all
<Zakim> danbri, you wanted to say the only Core thing I see in RDFa, is stuff like "can #me in an html+rdfa doc be a URI for a human..."
david: I'm concerned there may be a subtle relation that we might have to take into account
danbri: what about # URIs in RDFa: can they identify any resource?
<cgreer> I volunteer
ivan: from the RDF point of view, RDFa is "only" a serialization syntax (though a very special one)
danbri: in theory yes
guus: david and cgreer volunteer to review the 'RDFa core' document on behalf of the WG
<davidwood> From RDFa Core, section 7.2: "The base. This will usually be the IRI of the document being processed, but it could be some other IRI, set by some other mechanism, such as the (X)HTML base element. The important thing is that it establishes an IRI against which relative paths can be resolved."
guus: you send comments to the rdf-wg mailing list, and the group approves the comments
<davidwood> That means, to me, that the base IRI is often going to be the *same as* the document URI, thus resulting in conflation of denotation of the graph and the document.
<davidwood> AndyS ^^
<davidwood> I don't think that needs to change in the RDFa Core document, but it does mean that our named graphs discussion should take note.
<AndyS> davidwood - yes, good point. But the doc URI is not the graph name in every case -- it is in the web cache pattern.
<davidwood> AndyS, right
ACTION guus to review the 'RDFa primer'
<trackbot> Created ACTION-127 - Review the 'RDFa primer' [on Guus Schreiber - due 2012-01-11].
<AndyS> davidwood, does RDFa talk about the graph in any particular way? (c.f. N3 <> and <#> isms)
ACTION davidwood and cgreer to review the 'RDFa core' document
<trackbot> Created ACTION-128 - And cgreer to review the 'RDFa core' document [on David Wood - due 2012-01-11].
<ivan> AndyS: unless a mistake has been made, no...
<AndyS> ... which is why we review :-)
<davidwood> AndyS, I don''t think so. The current draft seems to refer all further definition of the graph to RDF Concepts (unless I'm missing something).
guus: 3 comments on the Turtle document
<davidwood> I agree with Ivan that we should think of RDFa 1.1 as "just" another standard RDF serialization syntax.
gavin: first is about the Turtle grammar not being LL(1), need to discuss it with eric
<AndyS> They are case-insensitive in SPARQL :-|
gavin: second is about making literals case-insensitive, which I don't think we will
andy: in SPARQL they are (all keywords are)
<ericP> gavinc, i can grammar geek with you after this call
<AndyS> all keywords except "a" for rdf:type. With hindsight, a bit insistentent between bools and "a" but that's where we are and it's mostly harmless, Zaphod.
gavin: I think all the issues have been answered on the mailing list
<sandro> something like, "Please respond and let us know whether this response addresses your concern."
<AndyS> gavinc, ericP -- please make LL(1) unless strong reason not to. It helps people to cover as wide a spectrum of tools.
guss: it would be good to open an issue for the comments, in order to formally acknowledge them and keep track of the resolution
<ericP> AndyS, i'm not yet convinced that it's not LL(1)
<sandro> sandro: we need each comment to end in one of three buckets -- satisfied, objecting, or other (typically not answering our pings).
guus: raised by gavin
gavin: in the last meeting, we
agreed that a dataset could not repeat the same graph IRI
several times
... trying to explore the consequence on the Trig syntax
<swh> "merge"?!
gavin: consensus seems to emerge
on option 2:
... if the same graph IRI appears several times in Trig, then
merge their content in a single graph with that IRI
<AndyS> The discussion explains why not. (As is, needs 2 tokens lookahead - can rewrite current form to LL(1) but it will look strange -- easier to use the form that is more natural and LL(1) -- from SPARQL which also does the trailing dot for TriG ... long time)
<ericP> AndyS, the trick in mapping EBNF to LL(1) is that +s and *s get mapped to e.g. { foo_plus: foo | foo_plus foo } while LALR(1) reverses that to { foo_plus: foo | foo foo_plus }
<AndyS> merge ==> more triples = union
<ericP> AndyS, sorry reverse those EBNF to L*(1) mappings
sandro: it is not clear yet whether Trig solves our use cases (I think it does not)
<AndyS> ericP -- er ... different issue -- it's mid rule. Later?
sandro: so should we care about Trig at all?
<davidwood> Sandro, yes, but it would seem that Trig is extensible to handle that use case.
<zwu2> not me :)
<LeeF> Sandro, when you say "our use cases" -- who is "our" referring to? and is there an applies "any" or "all" ?
<sandro> I'll believe it when I see it, davidwood.
steeve: did Gavin mean litteraly
an RDF merge?
... should it be a merge or a union ?
<LeeF> "munion"
<sandro> LeeF, "our" is RDF-WGs. I realize we haven't yet decided which use cases to accept, so I really just meant "potential use cases"
steeve: different management of bnode identifiers appearing in multiple pairs of curly braces
gavin: we have not decided that
yet
... my preferringence for option 1 (not allow it at all) is
that it solves that problem
<LeeF> Sandro, it's pretty clear to me that trig solves many of those use cases, if not all, so i'm not sure why to suggest that we shouldn't care about it
<Zakim> JeremyCarroll, you wanted to respond to sandro
jeremy: to answer sandro's comment: I believe Trig answers some use cases
<swh> +1 to JeremyCarroll
<LeeF> Agree with gavin
<LeeF> I read consensus in that email thread
sandro: we are not chartered to
standardize Trig; we are chartered to propose a syntax
supporting multiple graphs
... if Trig does it, then ok. But if it doesn't, then we need
to standardize something else.
<JeremyCarroll> Jeremy: Sandro raised questions about URIs identifying graphs vs graph containers - these were not to do with Trig
sandro: In general I don't like
starting from use cases, but as we don't seem to reach
consensus, I think that's how we should proceed
... and see if Trig address them or not
ACTION jeremy to review sandro's use cases
<trackbot> Created ACTION-129 - Review sandro's use cases [on Jeremy Carroll - due 2012-01-11].
<sandro> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC in general, and in specific: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Trust_Web_Opinions
<sandro> (that's for jjc)
<sandro> -1 to ever calling it "named graphs" :-)
subtopic: Issue: should/must the 4th slot be an IRI?
guus: last week resolution seems to imply that it should
<LeeF> I would object to letting it be a bnode, probably
guus: can we reach consensus on that?
<swh> I might
<sandro> sandro: sometimes it might be a bnode.
<swh> …even though Iv'e done it in the past :)
<gavinc> I would object to letting it be a bnode
sandro: I think it should be allowed to be a bnode
david: what would be the use case?
<swh> sandro, what about .well-known/genid
<swh> ?
sandro: in the trust use case, I
want to talk about a set of 4 triples, and there is no point in
giving a URI to this set
... if you want to repeat it, a graph literal is not
convenient
andy: there are two kinds of use for bnodes: things for which I don't want to mint a URI, and existential variables
<danbri> busted! sorry
andy: you seem to be using the first one
<sandro> sandro: Yes, just the filler case, where I don't really want to mint a URI.
<swh> the "filler" case would require some syntactic gymnastics to make it work
<swh> e.g. [] { … triples … } … then what?
guus: why not go the the genid solution, then?
sandro: makes sense if you get rid of bnodes everywhere, but if you keep bnodes, why not allow them there?
<ivan> +1 to steve!
steeve: this could be handled by syntactic sugar in Trig
<gavinc> +1 to steve
steeve: to generate the genid URI
<sandro> sandro: if you can use bnodes as pronouns for strings and lists, etc, then it'll be odd not to have them as pronouns for referring to RDF Graphs.
<AndyS> So when it comes out again it is a URI?
<swh> AndyS, yes
steeve: because bnodes would raise very bizarre questions regarding scoping
pchampin: +1 about the scoping problem
<swh> I have some experience
<AndyS> This sounds like as a shorthand for URIs issue, not bnodes.
<LeeF> Peter won't be here next week, I believe
sandro: I would like to hear Pat's opinion about the scoping issue
steeve: 3store explicitly
supported graph identified by bnodes
... but we banned it in 4store and 5store, as it was too
complicated to manage
<AndyS> F2F discussion: UC graphs: http://www.w3.org/2011/rdf-wg/meeting/2011-10-12#4__2e_9___28_A_PRIORITY__29__Trust_Web_Opinions
<AndyS> and also http://www.w3.org/2011/rdf-wg/meeting/2011-10-12#1__2e_5___28_A_PRIORITY__29__Exchanging_the_contents_of_RDF_stores
<sandro> sandro: I might be convinced to support this restriction, like the no-subjects-as-literals, in the name of ease of implementaiton.
<zwu2> sorry I have to go to another meeting, bye.
guus: as neither Pat nor Richard
are here, may be we can leave this discussion for next
week,
... unless someone wants to add something
sandro: I think we should clean
the UC list into something smaller, easier to grasp at
once
... are we going to publish our use cases?
guus: I would be in favor of publishing them
david: I concur
<AndyS> Does anyone have an example where signing the doc is not sufficient?
<gavinc> AndyS: PaySwarm does
<ericP> AndyS, very large triple stores?
guus: propose a UC about signing a graph (in order to state "I stated this graph")
<AndyS> gavinc ... interesting ... ptr?
sandro: to endorse or to agree with a graph?
<AndyS> ericP ... maybe but how does sign again to check?
<danbri> who?
<danbri> fb?
<danbri> swh, manu?
<ericP> AndyS, i think the discriminating use cases are when you don't need to sign
<ericP> ... just need to make assertions about it
<swh> danbri, yes, manu, thanks
<AndyS> The case I can see is sign-graph keeps sig across reencoding (e.g. into a store c.f. Eric - but any size)
guus: regarding the restaurant? UC, how would you write it down in Trig?
<AndyS> UC is : http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28A_PRIORITY.29_Trust_Web_Opinions
<sandro> { sandro endorses g1 }
<AndyS> full version -- http://lists.w3.org/Archives/Public/public-rdf-prov/2011Sep/0003.html
<sandro> g1 { ... some triples }
<sandro> g1 owl:sameAs { ... some triples }
<sandro> <addressyoufetchedfrom> { ... some triples }
<gavinc> ... owl:sameAs only works with Resources/IRIs doesn't it?
<sandro> <addressyoufetchedfrom> graphStante { ... some triples }
<sandro> <addressyoufetchedfrom> graphState { ... some triples }
<sandro> <graph> ?RELATION? { ... triples ... }
sandro: the example above is not compatible with Trig, as there is a predicate between the graph URI and the curly braces,
<AndyS> Breaks n-quads as well.
sandro: stating the relation between the graph IRI and the graph
<sandro> OPTION 1: <graph> ?RELATION? { ... triples ... }
<sandro> OPTION 2: relation is always graphState, but there are immutable graph containers used as proxies
<AndyS> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Dec/0189.html
sandro: option 2 adds a semantics to Trig, so risks to break existing Trig
ivan: then how do you express the sameAs relation with option 2?
<sandro> { sandro endorsesContentOf <g1>. <g1> a StaticGraphContainer } <g1> { some triples }
<sandro> (a sketch of option 2)
guus: it would be good if someone could write this down
<sandro> write down both uses cases, and how they are addressed by both options.
sandro: it would be good to write down both use cases, both option, and how each option solves each UC
<sandro> sandro: yes, we can use Trig, or a variant, just be clear about what semantics you mean for TriG.
ACTION guus to write down both uses cases, and how they are addressed by both options
<trackbot> Created ACTION-130 - Write down both uses cases, and how they are addressed by both options [on Guus Schreiber - due 2012-01-11].
<Guus> trackbot, end meeting
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/importance/interest/ Succeeded: s/with gavin/with eric/ Succeeded: s/in/it/ Succeeded: s/refer/referring/ Succeeded: s/supports/supported/ Found Scribe: pchampin Inferring ScribeNick: pchampin Found ScribeNick: pchampin Default Present: +1.707.861.aaaa, gavinc, +1.781.899.aabb, sandro, +31.20.598.aacc, Guus, pchampin, +1.707.318.aadd, cgreer, Ivan, AndyS, +1.781.273.aaee Present: +1.707.861.aaaa gavinc +1.781.899.aabb sandro +31.20.598.aacc Guus pchampin +1.707.318.aadd cgreer Ivan AndyS +1.781.273.aaee WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/04-rdf-wg-minutes.html People with action items:[End of scribe.perl diagnostic output]