RDF Working Group Teleconference -- 04 Jan 2012

<trackbot> Date: 04 January 2012

<Guus> we may need a scribe volunteer if Thomas doesn't join

I can scribe

<scribe> scribe: pchampin

<scribe> scribenick: pchampin

admin

<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)

RDFa LC

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...

status comments received

<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

RDF-ISSUE-82 (TriG repeated graph iris)

<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)

named graphs

<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.

IRI names for both graph containers and graphs?

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

- DRAFT -

RDF Working Group Teleconference

04 Jan 2012

Attendees

Contents