RDF Working Group Teleconference -- 04 May 2011

<trackbot> Date: 04 May 2011

<davidwood> Scribe: Thomas Steiner

<sandro> mischat, yes, the MIT facility does that, but might not fit all the people who want to be local at MIT.

<mischat> sure

<mischat> well at least it is an option, i wonder how many people would be at the east coast event if there was a european place to sit as well ...

<sandro> Yeah, mischat, Guus was going to make a poll to find the answer to that question.

<davidwood> ScribeNick: tomayac

Proposal to accept the minutes

<ericP> +1

Minutes accepted.

AI 34 overdue

<davidwood> http://www.w3.org/2011/rdf-wg/track/actions/34

<scribe> Done, whole heap of issues raised, see action

going thru issues today

some easy, some hard

proposed to close ACTION-34

closing ACTION-34

next topic: ACTION-22

but cygri sent regrets

ACTION-21 done?

<mischat> http://www.w3.org/2011/rdf-wg/track/actions/22

<cmatheus> zakim. ??P32 is cmatheus

will be clearified

sandro: ACTION-39 closed

unrecorded ACTION: look at respec text vs. wiki text

gavin: action was unrecorded

gavin, wlliam, pierre-antoine on the unrecorded action

next topic: ACTION-41

<sandro> ACTION: gavin to compare/contrast respec vs mediawiki for spec authoring [recorded in http://www.w3.org/2011/05/04-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-43 - Compare/contrast respec vs mediawiki for spec authoring [on Gavin Carothers - due 2011-05-11].

poll for face2face, on antoine

<sandro> ACTION: william to compare/contrast respec vs mediawiki for spec authoring [recorded in http://www.w3.org/2011/05/04-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-44 - Compare/contrast respec vs mediawiki for spec authoring [on William Waites - due 2011-05-11].

<AZ> can you hear me?

<mischat> i found out about the video conferencing facilities at southampton uni fwiw

<sandro> action piere-antoine: to compare/contrast respec vs mediawiki for spec authoring

<trackbot> Sorry, couldn't find user - piere-antoine

<AZ> it seems I have a problem with my mic

<sandro> action Pierre-Antoine: to compare/contrast respec vs mediawiki for spec authoring

<trackbot> Created ACTION-45 - Compare/contrast respec vs mediawiki for spec authoring [on Pierre-Antoine Champin - due 2011-05-11].

<mischat> http://www.w3.org/2011/rdf-wg/track/actions/42

<AZ> I have a text to propose

ACTION-42: done?

<trackbot> ACTION-42 Propose text for resolution on archaic xsd:strings notes added

text in email. link anyone?

<AZ> "PROPOSED: Recommend that data publishers use plain literals instead of xs:string typed literals and tell systems to silently convert xs:string literals to plain literals without language tag."

<gavinc> "PROPOSED: Recommend that data publishers use plain literals instead of xs:string typed literals and tell systems to silently convert xs:string literals to plain literals without language tag."

<AZ> it's the same as in my email

same as in email

<davidwood> http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0057.html

ACTION-42 herewith closed

next topic: sparql-turtle alignemnt

issues, agreements, disagreements

andy discussion lead

<mischat> http://www.w3.org/2011/rdf-wg/wiki/Diff_SPARQL_Turtle

andy: agreement: on all issues

except for one

<ivan> Andy's email

eric wishes to add a feature into turtle to allow prefixing of names

<mischat> http://www.w3.org/2011/rdf-wg/wiki/Diff_SPARQL_Turtle#Possible_extension_to_Turtle

<AndyS>

eric: getting past encoding limitations in pnames

<mischat> go on ...

<ericP> _:Eve foaf:name "Eve\u0022 .

<ericP> _:Eve :says "Éric says \u0022Hi\u0022" .

<sandro> AndyS

eric: escaping not part of the grammar

<gavinc> +q

eric: productions of local names to include escape productions

ivan: why this difference?

andy: at the moment as turtle is defined, commas disallowed in prefix names

eric: disagrees

andy: that would be a change to sparql
... current form does not allow \u escapings

gavin: thinks that ntriples has local names

andy: label for a bnode has to be decided on a per-output basis
... asks eric: are you happy w/ the outher proosals

eric: ACK

andy: any other issues?

-- silence --

no other issues

andy: on what basis do we take the decision?

eric: on the prefix nodes issues: sorry it cant be done

<LeeF> I think it's a "nice feature to have", but I'm (of course) wary of changing SPARQL right now because of the impact on implementors

<SteveH> +1 to LeeF

<PatH> There is a dragon on the call breathing fire.

eric: no new prefix for each row in the db
... just use the same prefix

<PatH> sounds like LeeF is right, this is neat feature but not really essential. I suggest not worth changing sparql for.

andy: need a decision mechanism

ivan: question is: what is the most, what is the least destructive answer?

ivan seems gone

<gavinc> -q

lee: understands the use case
... probably not a good thing to include during SPARQL last call

<MacTed> (AZ muted, and ivan went quiet ... ivan isn't in the names list ... I'm guessing AZ took ivan's line)

ivan is back

<LeeF> Also mildly disruptive with existing turtle and sparql implementations

ivan: not only last call, but also deployed sparql versions

<LeeF> Both things -- disruptive to SPARQL schedule, and somewhat disruptive to implementations

<PatH> Maybe should ask, if we DONT do this, how bad would that be?

eric: not convinced that it's true

<MacTed> 1.1 (or later) have been known to break (or at least, go beyond) 1.0 ...

<PatH> Everyone sees to agree this would be kind of neat, but... So what is the but... for NOT doing it.

<MacTed> BASIC 2.0 commands broke in BASIC 1.0 interpreters... :-)

andy: argument for not doing it: its not currently in turtle and in sparql. how much need is out there?

<PatH> OK, thanks.

andy: whats the cost. would it cause a new last call?

davidwood: we have a choice:
... if we were to include it in turtle, we'd break the sparql turtle alignment
... do we want to break sparql-turtle alignment?

<PatH> OK, seems to me that sparql/turtle alignment is worth quite a lot of loss of neat-o features.

eric: no

ivan: having a problem w/ sparql turtle alignment would be a mistake
... sandro very diplomatic proposal:
... if sparql goes to last call => sparql can make it a pending feature

<AndyS> if programmatic constructed, then the system writer gets it right anyway

ivan: if feedback on last call very negative => can be taken out

<PatH> Ivan, you should be in the State Department.

<PatH> +1 Ivan

ivan: make it clear that its an issue in pimplementations, and see what the feedback is

davidwood: happy with it

lee: implementers are here. opinions?
... happy, with the sparql hat on

<PatH> sparqly pimplementors unite!

<ericP> <PN_CHARS_BASE> |= UCHAR

<LeeF> LeeF: I'm ok with it, because I'm ok with not being 100% conformant, but I wouldn't run off to make this change in my code

ivan: to be fair, other changes for turtle would require turtle parsers to go thru an update circle

<SteveH> I think this is less invasive than the \u escape ordering thing

<SteveH> but I'm not a parser guy

andy: required update is for strings and iris
... believed not to affect many people

<ericP> _:Eve foaf:name "Eve\u0022 .

eric: in the sense of doesnt happen often enough?

andy: yep, in this sense

david: you think we make any progress on this, andy? or should we move on?

andy: think we should move on

<gavinc> as turtle implentor, I'm with Eric. Easy change to make.

ivan: can we agree on other issues to be solved?

andy: yes, i can draft a resolution

eric: one of the points in erics mail was: escaping should not be in the grammar, eric says: it should be in the grammar

andy: i took whatever was in the current doc

<AndyS> PROPOSED: http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0011.html Point 2-7 are agreed leaving \u processing (point 8)

<ivan> +1

<zwu2> +1

<pchampin> +1

<davidwood> +1

<PatH> +1

<sandro> +1

<gavinc> +1

objections to andy's proposal?

<webr3> +1

<cmatheus> +1

no objections. propsal accepted

<mbrunati> +1

<SteveH> abstain

<ericP> +1

<ivan> RESOLVED: http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0011.html Point 2-7 are agreed leaving \u processing

thanks for the productive discussion

next topic:

revisiting of post-poned issues

let's try to resolve whatever is possible via phone

let's skip others

clean up easy ones

<davidwood> ISSUE-42: Revisit "Something should be done about aboutEachPrefix construct"

<trackbot> ISSUE-42 Revisit "Something should be done about aboutEachPrefix construct" notes added

<davidwood> http://www.w3.org/2011/rdf-wg/track/issues/42

looking at issue 42

<ivan> ISSUE-42?

<trackbot> ISSUE-42 -- Revisit "Something should be done about aboutEachPrefix construct" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/42

davidwood: please check the issue and edit it if need be

<ivan> +1

<webr3> +1

<sandro> +1

<AndyS> +1

<pchampin> +1

<SteveH> +1

<zwu2> +1

davidwood: objections to closing ISSUE-42?

<gavinc> +0 (no idea what the issue was)

davidwood: it's in the charter to clean left-overs

<mbrunati> +1

<AZ> +1

davidwood: closing ISSUE-42

<PatH> q

<ivan> ISSUE-43?

<trackbot> ISSUE-43 -- Revisit "Suggestion that Qnames should be allowed as values for attributes such as rdf:about" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/43

next: ISSUE-43

<webr3> +1 to resolve/close

<LeeF> +1

<ivan> +1

<AZ> +1

<mbrunati> +1

<SteveH> +1

<AndyS> +1

<gavinc> +1 to close

<zwu2> +0

theere was agreement on email to close this ISSUE-43

<PatH> +0

<ericP> +0

<pchampin> +0

<Souri> -0

davidwood: closing ISSUE-43

<ivan> ISSUE-44?

<trackbot> ISSUE-44 -- Revisit "The RDF XML syntax cannot represent all possible Property URI's" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/44

next: ISSUE-44

<webr3> +1 to close, can't see any reason to continue soemthing that won't change

<ivan> +1

<LeeF> +1

<SteveH> +1 to close

<AZ> +1 to close

<mbrunati> +1

<AlexHall> +1

<zwu2> +0

davidwood: seems agreement to close it, as rdf/xml wont never ever change

<AndyS> +1 to close with no change

<PatH> +1

<ericP> +0

<Souri> +1

<gavinc> +1 close

<cmatheus> +1

davidwood: correction: minor changes to rdf/xml might happen. sorry

<ivan> ISSUE-45?

<trackbot> ISSUE-45 -- Revisit "The syntax needs a more convenient way to express the reification of a statement" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/45

<webr3> +1 close as a duplicate (on issue-25)

davidwood: ISSUE-44 closed

davidwod: next ISSUE-45

<PatH> +1

<SteveH> +1, close a dup

<gavinc> +1 close as duplicate

<cmatheus> +1

<mbrunati> +1

<zwu2> +1

davidwood: ISSUE-45 is duplicate of ISSUE-25 => close it

<OlivierCorby> +1

<AZ> +1 close as duplicate

<Souri> +1

davidwood: ISSUE-45 closed

<ivan> ISSUE-46?

<trackbot> ISSUE-46 -- Revisit "Should RDF have a mechanism for declaring two uri's to be equivalent?" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/46

<webr3> -1 leave open for discussion later

davidwood: ISSUE-46

<PatH> Sugfgest we keep this one open for now.

<gavinc> -0 leave open

davidwood: leave it open for next workshop

<SteveH> close, we have owl:sameAs

<AZ> +0

<zwu2> close, we have owl:sameAs

<cmatheus> +1 leave open

<ericP> abstain

davidwood: enough DISagreement to leave this open

<ivan> -0

<mbrunati> 0 leave open

<ivan> ISSUE-47?

<trackbot> ISSUE-47 -- Revisit "RDF embedded in XHTML and other XML documents is hard to validate" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/47

davidwood: ISSUE-47

<webr3> +1/0 don't care

<SteveH> don't care

<ivan> +1 to close

<FabGandon> out of scope

<zwu2> +1 close

<AZ> +1 to close

<sandro> close, but with a better comment.

davidwood: no objections to close it

<Souri> +1

<mbrunati> +1 close

<pchampin> out of scope

<PatH> does i tmean the RDF is hard to validate or the XML is?

davidwood: ISSUE-47 clsoed

<cmatheus> +1 close

<PatH> +1 close out of scope

davidwood: validation is out of scope of this wg

<gavinc> +1 close with validation out of scope

<sandro> +1 "Close -- validation is out of scope for this WG"

<mischat> +1 to close

<PatH> listen to the worms...

<ivan> ISSUE-48?

<trackbot> ISSUE-48 -- Revisit "The design of the RDF Model collection classes exhibit various awkward features. Might these be augmented with a 'better' design?" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/48

davidwood: ISSUE-48

<webr3> +0

davidwood: danbri marked this one as a duplicate
... proposal to close it as duplicate to ISSUE-24

<gavinc> +0 close as duplicate of Issue-24?

<SteveH> not a dup of 24

<PatH> +q

andy: not a duplicate of ISSUE-24
... its about containers

ISSUE-48 is about collections

patH: couldnt follow, sorry

<SteveH> "The use of special property names (_1, _2, etc.) can really be quite awkward for expressing ordering. It means that it can be very difficult to add new members to a collection after the event"

path: seems to be a suggestion to put linked lists into rdf. done by the prev. wg
... seems an archaic left-over

<mischat> SteveH: is speaking now

steveh: not true

davidwood: want to continue this discussion on the list?

steveharris: lists of things done the wrong way twice

<gavinc> Anyone have ideas on making better lists?

path: close it and throw it away

<webr3> +1 to path

<ericP> +1 to PatH's dicideratum

<ivan> +1

<zwu2> +1

<FabGandon> +1

<webr3> +1

davidwood: proposal to close ISSUE-48 as overcome by events. objections?

<pchampin> +1

<mbrunati> +1

<Souri> +1

<gavinc> +1

<AZ> +1

<mischat> +!

<mischat> +1

<cmatheus> +1

<AndyS> Add them as a first class data object, not encode in triples. Its the encoding (and possible mis-encoding) that cause some of the pain.

<ivan> ISSUE-49?

<trackbot> ISSUE-49 -- Revisit "Should the subjects of RDF statements be allowed to be literals" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/49

davidwood: ISSUE-48 closed

<SteveH> +1 to AndyS

<zwu2> would be nice to have it :)

ISSUE-49: literals as subjects cant be closed

<trackbot> ISSUE-49 Revisit "Should the subjects of RDF statements be allowed to be literals" notes added

<webr3> q: could I create an RDF serialization with literal subjects and defer to the rdf semantics?

<PatH> Andy: I agree, buit that goes way beyond issue-48.

davidwood: cant be considered closed

<PatH> Yes, the semantics is fine iwth lieteral subjects.

<PatH> with literal

andy: happy to postpone

<webr3> so it's in "rdf" but not in the official serializations

andy: rdf api allows literals as subjects

ivan: status of rdf api? first public working draft hopefully next week

<PatH> There was a chorus of disapproval for literal subjects at the initial workshop, mostly from developers who didnt want to alter lagacy code.

davidwood: for the moment we cant do anything about it

<webr3> it's now "rdf-interfaces" which contains it - rdf-api is a diff spec

<PatH> legacy

<webr3> +1 to continue

<AndyS> +1 to PatH - legacy is now a real issue (and that's good)

tomayac: rdf api is now rdf interfaces

<mischat> literal as subjects doesn't seem very webbie to me, but anyways ...

<ivan> ISSUE-50?

<trackbot> ISSUE-50 -- Revisit "Request to allow b-nodes as property labels" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/50

davidwood: ISSUE-50
... out of charter

<PatH> Sorry to go back, but I just noticed something about issue-42 that might be slightly important. The POWDER mechanism uses rdf:bag, which me therefor have to be careful not to deprecate.

<webr3> rdf-interfaces again allows bnode predicates

davidwood: should we leave it open? or postpone?

<PatH> FWIW< again the semantics is OK with bnode property labels, but some of the entailments might raise eyebrows.

<webr3> are we goign to discuss further? if nto postpone

davidwood: ISSUE-50 postponed

<FabGandon> +1 postpone

<mischat> postpone please ....

<pchampin> +1 postpone

<SteveH> +1 to postpone

<Souri> +1 to postpone

<ericP> +1

<PatH> COWARDS!!

<zwu2> +1 to postpone

<gavinc> +1 postpone

<webr3> PatH, ty for confirmation, I don't mind raised eyebrows :)

<mbrunati> +1 to postpone

<PatH> +1

<cmatheus> +1

<webr3> +1

<ericP> +1 to cowering in fear

<gavinc> RDF Interfaces :\

<mischat> as in rdf-interfaces has bnode properties and literal subjects

ivan: this issue is different than the previous one

<webr3> RDF interface implementations will support it.. rdf semantics do to, serializations don't - doesn't matter, this is behind the "public interface"

ivan: you might have bnodes as predicates

<webr3> +1 to what ivan is saying

<PatH> +1 to Ivan

<zwu2> +1 to Ivan

ivan: there was a huge discussion in the rdf applications wg

<PatH> This is a general issue, BTW, it also bears on literal subjects.

ivan: bnodes as predicates is good in APIs, because if not, implementations might have problems

<webr3> the needs for serializing RDF are different to the needs for workign with RDF - we need to accept that generally

<AndyS> Is there a serialization API?

ivan: if it's for me, we can close this issue

<PatH> It will damage the DL/Full boundary in OWL, for sure.

ivan: dont want to go down that route

<webr3> AndyS, roughly the RDF API (end user focussed) will be more restricted to the convensional (matching serializations)

david: if we postpone it goes to a later wg

<AndyS> webr3, pointer?

<webr3> AndyS, http://www.w3.org/2010/02/rdfa/sources/rdf-api/Overview.html

<PatH> LOL

davidwood: we're postponing already, leaving leftovers, just like the previous wg did

<webr3> can we address it properly, to say semantics allows X serializations are advised to allow Y (Reasons) then CLOSE ?

davidwood: if we close, we need to say why

<AndyS> webr3, pointer to serilization? I only see about parser using serialize

davidwood: saying it is out of scope is way different than closing

ivan: every wg may reopen closed issues

<webr3> AndyS, you've confused me - you're looking for?

<PatH> Ivan, you read my mind...

<PatH> Separate the issues!

zwu: how many people would truly object to have literals as subjects and bnodes as predicates

<SteveH> Garlik would object to both / either

<AndyS> A pointer to "roughly the RDF API (end user focussed) will be more restricted to the convensional (matching serializations)"

<sandro> STRAWPOLL: Who would object to Liuteral Subjects

<LeeF> Quite possibly.

<PatH> Im happy with literal subjects.

<ivan> +0.5

zwu: straw poll, please

<webr3> v happy with +1

<davidwood> I would possibly object to literal subjects - I have before

<sandro> STRAWPOLL: Allow Literal Subjects

<webr3> +1

<sandro> +1

<SteveH> -1

<cmatheus> +1

<PatH> +1

<Souri> -1

<pchampin> +1

<LeeF> -0.8

<AZ> +1

<mischat> -1

<mbrunati> +1

<zwu2> +1

<davidwood> -0.5

<ivan> -0.2

<OlivierCorby> -1

<gavinc> -0

<AlexHall> +0

<LeeF> ivan + me == 1 full objection! :-)

<ericP> -1

<AndyS> Need to think more but quite possibility -1 (because the deployed system impact)

<FabGandon> -1

zwu asked also for a straw poll on bnodes as predicates

<sandro> STRAWPOLL; Allow bnodes as predicates

<sandro> +1

<gavinc> +0

<webr3> +1

<ivan> -1

<PatH> +1

<zwu2> +1

<ericP> -1

<SteveH> -1

<Souri> -1

<LeeF> -1

<AZ> +1

<mischat> -1

<mbrunati> 0

<cmatheus> +0

<OlivierCorby> -1

<pchampin> +1

<FabGandon> -1

<davidwood> +0

<AndyS> -0.5

<PatH> This is assuming that we have bnodes at all, of course.

zwu: one for the reasons are: if we are implementing an inference engine, it's way easier to allow, than disallow them

<gavinc> +1 to PatH

<MacTed> bnodes are useful in-process. they are nothing but trouble once you leave process.

<davidwood> We have bnodes, Pat :)

ivan: -1 because it would invalidate many things in owl

<PatH> It depends what kind of inference engine uyou are tryuing to implement.

<PatH> OWL-DL would prohibit it rigorously, so it would add a layer of checking to thier engines.

<FabGandon> +1 to AndyS

<mischat> +1 AndyS

<PatH> +1 to andy

davidwood: back to ISSUE-50

<gavinc> +0.5 to AndyS ... sometimes it leaks

davidwood: open => discuss, close => out of scope, postponed: let others deal with it

<webr3> if it's not an RDF WG level problem, who would it be a problem for?

<AndyS> gavinc, where??? and I'll stop that!!!!!!

<mischat> it is not webby to serialise statements suchs as ` "42" _:bnode1 _bnode2 . `

<webr3> +1 leave raised

<SteveH> close

davidwood: significant disagreement

<zwu2> +1 postpone it

ivan: either close or postpone

<LeeF> suggest close

<cmatheus> +1 leave raised

<PatH> Its not in our charter, its a huge can of worms, it owuld screw up OWL (and probably RIF) relatkionships. Lets walk away from it.

<pchampin> +1 postpone

<FabGandon> out of scope

<Souri> +1 to postpone it

<mbrunati> sorry guys i have to leave

<PatH> SO, leave it open and ignore it.

davidwood: reads what people say on irc

<webr3> (I'm saying to leave open/raised until there's good text to close it with or to clarify around the issue)

<LeeF> I don't think postponing is good. What's the point? If people find this useful and implement it, then we can standardize it in the future. But what's the point in continuing to say "meh"?

<SteveH> just close it, a future group can open a new issue if it becomes desirable

davidwood: enough agreement to postpone

<LeeF> +1 SteveH

davidwood: correction: not enough agreement

<ivan> +1 SteveH

<LeeF> I'm ok with opening it and then closing it, as well.

<LeeF> -1 to postponing it

<webr3> -1

<cmatheus> -1

<sandro> STRAWPOLL: postpone issue 50

<PatH> is an open issue like an open sore?

<LeeF> PatH, very very much so

davidwood: makes a chair decision to leave it raised. talk about it later

<mischat> http://www.w3.org/2011/rdf-wg/track/issues/42

davidwood: pat raised a question on issue 42

path: rdf bag not much use
... proposed to deprecate rdf bag

davidwood: thinks we still could deprecate

<pchampin> I thought we already excluded the deprecation of rdf:Bag as it was widely used in RSS

<pchampin> (vague memory of the F2F)

davidwood: out of time for this call

<mischat> i recall that pchampin too

<SteveH> pchampin, yes

<PatH> pcahmpin, good point. thnx.

davidwood: remaining issues => later call
... AOB?
... call adjourned

<zwu2> bye

<mischat> would be nice to have the next f2f sorted

<PatH> ivan, to handle that issue we discussed.

<mischat> doh

<mischat> bye all

<AndyS> webr3 - I see nothing about serialization

- DRAFT -

RDF Working Group Teleconference

04 May 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output