See also: IRC log
<trackbot> Date: 08 June 2011
<cygri_> ah well, that was unnecessary
<cygri> i hear that "trackbot, start meeting" magically invites zakim and rrsagent
<mischat> hello all
<cygri> zakim aabb is me
<scribe> scribenick: SteveH
<scribe> scribe: SteveH
... any objections....
... resolved, accept minutes of last meeting
... no actions pending review, open action items:
... options for issue 15
cygri: it's related to graphs
stuff, we should refactor it
... start progress over again
Guus: it's on an agenda
... lets close this action, and see
... 3rd action is on Sandro "start conversation on reservings"/
[it might be .well-known]
cygri, it's whether we approach the IEFT now, or wait
Guus: can someone add a note saying what it means
davidwood: I'll add something
cygri: ...about literals ^
<davidwood> SteveH: Thanks. My recent status change seems to have left me unable to edit the wiki.
Guus: nearing time when europeans
will go on holiday
... several ways - we can tke a break, or meet every week with a small group, or do telecons every 2 weeks over summertime
... happy to accept other points
<cygri> trackbot, close ACTION-25
<trackbot> ACTION-25 Write up the different options re ISSUE-15 closed
davidwood: we have one week where we know lots of people will be absent
Guus: does 2 weeks sound fine?
<ww> +1 every two weeks
<cygri> SteveH: sparql keeps running through the summer, lots of americans on the group
<davidwood> +1 to 2 weeks
Guus: suggest we do every 2
weeks, back to normal on 3rd week of aug
... I will propose a schedule
<scribe> ACTION: Guus to propose schedule [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action01]
<trackbot> Created ACTION-55 - Propose schedule [on Guus Schreiber - due 2011-06-15].
ACTION-55: schedule for meetings over the summer that is
<trackbot> ACTION-55 Propose schedule notes added
<PHayes> Um..sorry Im late...why are we changing the schedule?
Guus: SPARQL last call WD
<AlexHall> PatH, because Europeans are about to go on holiday.
Guus: decided that we will have
personal reviews from members + review on behalf of RDF
... actions were not recorded
pchampin: haven't had time to look into it
Guus: it's proper behaviour for us to respond quickly
<scribe> ACTION: pchampin to review SPARQL LC WD document [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action02]
<trackbot> Created ACTION-56 - Review SPARQL LC WD document [on Pierre-Antoine Champin - due 2011-06-15].
<scribe> ACTION: Guus to contact Yves R. re. SPARQL reviews [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action03]
<trackbot> Created ACTION-57 - Contact Yves R. re. SPARQL reviews [on Guus Schreiber - due 2011-06-15].
Guus: Lee F. suggested we organise a short telecon to discuss graph terminology
davidwood: could be in the contxet of coord group
Guus: message of 16th May
... 15th May in US
<scribe> ACTION: Guus to organise telecon with SPARQL WG on graph terminology [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action04]
<trackbot> Created ACTION-58 - Organise telecon with SPARQL WG on graph terminology [on Guus Schreiber - due 2011-06-15].
<pchampin> of course
Guus: pchampin, would be nice if you could take into account discussion of string literals
Status of documentation
Guus: concepts document, it's in
... I assume that most of the respec problems have been fixed
<cygri> RDF Concepts, editors draft: http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html
Guus: I suggest to reuse old templates
cygri: one way to start would be
take a copy of HTML files, especially header
... you have to make some obvious changes
... then insert the current content as published
Guus: I did that already for the
... would be best is we started adding docs to repo
<ww> aside: i tried writing a spec with respec.js attempting to put the vocabulary in rdfa inside it. didn't work very well...
<PHayes> I have to say, this whole process is utterly alien to me and I really have not even begun hjow to install the necessary software. As I have no idea what it is doing, I dont know how to know if I ge it right.
PHayes: I'll learn how to do it, but it will take me a while
Guus: Richard sent a doc with
shortnames for docuemnts, seems obvious
... but why is it turtle, not rdf-turtle
cygri: either would be ok
Guus: we have rdf- infront of all of them
davidwood: I propose to make that change
<AZ> \me +1 to rdf- for all documents
cygri: we should have a page (on
the wiki) about the documents
... I could create
<scribe> ACTION: cygri to create page on wiki about documents and editing [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action05]
<trackbot> Created ACTION-59 - Create page on wiki about documents and editing [on Richard Cyganiak - due 2011-06-15].
Guus: will try for early Turtle draft, relatively little work, but work needs to be done
ACTION Guus to discuss Turtle doc schedule with ericP
<trackbot> Created ACTION-60 - Discuss Turtle doc schedule with ericP [on Guus Schreiber - due 2011-06-15].
Guus: will attempt to report back next week
<PHayes> +1 to david
davidwood: can we leave the telecon slot open
Guus: content issues
... as far as I can see the main changes to concepts are graphs TF issues, have to reach consensus, but lots of open issues
... wondering if its useful to do review next week
... is someone willing to prepare that discussion
<davidwood> +1 to refocus discussion on graphs
Guus: about 10 issues open,
propose we start discussing next week
... re. concepts doc
<PHayes> Unfortunately this particular week is impossible for me, or I would volunteer. Good idea.
Guus: issues are well documented, so should review issues, and assign actions
<cygri> +1 to reviewing the issues + deciding on actions
Guus: one issue is being tacked
... we were close to consensus in last discussion
... next week 30 mins minimum for review of status of graphs issues
... last 5 postponed issues
... david proposes we should close it as it's archaic
+1, close it
<PHayes> agreee close
<AZ> +1 close
<cygri> +1 close
RESOLUTION: close ISSUE-58
Guus: "RDF XML syntax can't represent arbitrary graphs"
<pfps> +10 to not upgrade RDF/XML to do this
+1 to close
<pfps> +1 to *close*
<AZ> +1 to close
<AlexHall> It's already noted in the specs
<AlexHall> +1 to close
<PHayes> propose we leave this open for now, until we consider rdf/xml. No need to close it.
<davidwood> +1 to close
<trackbot> ISSUE-59 -- Revisit "The RDF/XML syntax can't represent an an arbritary graph structure" -- raised
<pfps> I don't see a possible future in which RDF/XML changes to represent all graphs.
<PHayes> OK, 0 from me.
<MacTed> silly phone system....
<PHayes> richard has a good point. THis may be a non-issue due to an old clerical error.
<cygri> issue description here: http://www.w3.org/2000/03/rdf-tracking/#rdfms-syntax-incomplete
<scribe> ACTION: pfps to check whether ISSUES-59 is still pertinient (may be obsolete) [recorded in http://www.w3.org/2011/06/08-rdf-wg-minutes.html#action06]
<trackbot> Created ACTION-61 - Check whether ISSUES-59 is still pertinient (may be obsolete) [on Peter Patel-Schneider - due 2011-06-15].
<ww> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jul/0163.html <-- actions to add nodeID recorded
<trackbot> ISSUE-60 -- Revisit "Defining the interpretation of fragment identifiers in RDF embedded in other document formats" -- raised
Guus: propose to continue
<trackbot> ISSUE-37 -- Handling of fragment identifiers in RDF embedded in other document formats -- raised
cygri: things like RDFa make this question more important, so this should be considered
Guus: we have an issue already,
so we can close 60, redir to 37
... can someone add a link to 37, and close 60?
<pfps> I'll do it, instead of my other action.
<cygri> +1 to close and redirect to ISSUE-37
<PHayes> FWIW, re. issue 59, the 26 july 2000 wg minutes say that this issue is "removed from the WG's issue list", not "postponed".
RESOLVED by consensus to close ISSUE-60 and redirect to ISSUE-37
<pfps> go it
<pfps> got it
Guus: looks like ISSUE-59 was an admin error
<trackbot> ISSUE-61 -- Revisit "An XML literal without markup, e.g. "foo" should denote the same thing as the plain literal "foo"" -- raised
<pfps> I don't think that Issue-12 talks about XML literals now.
I don't believe that "foo" is a legal XMLLiteral, is it?
"<foo />" is legal, I think
<PHayes> +1 Steve.
Guus: prefer not to close it with the current text, quite sure that we will close it with the statement that it's misguided
<PHayes> I dont understand this issue? Was it to make "foo"^^^rdf:XMLLIteral be identical with something else? If so, what?
<AZ> Close it but do not mention Issue-12
Guus: propose to close the issue stating that the statement is not true
<AZ> "foo"^^^rdf:XMLLIteral owl:differentFrom "foo"
Guus: more discussion?
propose to close issue-61 stating that the answer should be no
<AZ> +1 use pfps proposal
RESOLUTION: close ISSUE-61 stating that the answer is "no"
<PHayes> Why do I keep thinking 'augean'?
<trackbot> ISSUE-62 -- Revisit "The test cases manifest format has a semantic error" -- raised
Guus: propose to continue this
issue, and look again when we're working on testcases
... leave it open
<PHayes> +1 to doing nothing.
<trackbot> ISSUE-12 -- Reconcile various forms of string literals (time permitting) -- open
Guus: there's a thread about
this, it appears we're close to consensus
... would like discussion about things we don't have consensus about
... plan for resolution next week
<PHayes> I think we need a better name for rdf:LanguageTaggedLIteral
PHayes: I think we're close to
consensus, what about alt. proposal about using datatypes
... about only remaining thing we're still debating is what we're calling this datatype, and how best to explain it so it doesn't sound complicated
Guus: it's important to spend time on naming
PHayes: there's on more issue, there's 2 ways to present it, the new datatype
<ww> so "chat"@fr -> "\"chat\"@fr"^^rdf:LTR ??
PHayes: one is to retain the
current model sctrictly, but we have to use PlainLiteral device
in abstract syntax, to include both parts in one string, easy,
... or would could bite the bullet and treat it like its a datatype, but it takes a pair, the extension is trivial, some people things it's complex, but I don't agree
cygri: there are several ways to
handle connection between abs. syntax and semantics, one was is
to leave PLs as they are, and say that rdf:LTS is not actually
a DT, but a class
... of all <string, langtag> pairs
... worht considering, or do people object
PHayes: that's a viable option
... if you look how they get used, it's only used as a classname
... or a token
... we can just say that (something) without saying it's a DT
cygri: it seems that it's the
least painful way
... it might be a bit cleaner to do it with a DT, but we still have three things
... seems to cause oposition from implementors
scribe: maybe it would be a good option
<Guus> +1 for Richard's option
<PHayes> As long as it can be treated as a 'type' in SPARQL :-)
scribe: two more things, may still be disagreement, there's ....
ww: this proposal seems like a
half measure, intriduces an extra 3rd thing, and cant use rdf
machiney to model langs, which we might want to do
... we should leave open the possibility
<PHayes> Which proposal is Ww referring to?
ww: having a tuple-space with datatype means we cant do that
cygri: i'm confused
ww: dt with string,lang pairs
means the lang is disconnected
... there should be a DT for LTS, with subtypes, for every language
... leave the door open for modelling that
... abolish langtags
cygri: can't follow that
... what is the proposal
ww: langtags abolished, strings are strngs, subsets of the sets of all strings that are strings in particular languages, subtypes of the string datatype
<PHayes> I dont htink that our users will tolerate our bainishing lang tags on literals.
<pchampin> that does not work; language are orthogonal to strings
PHayes: there is a sizeable user
population that demanded them with passion, can't get rid of
... inc. the 23c i18n group
ww: not saying remove the function, just make it a kind of DT
[sounds like ww is describing langtags as datatypes option]
<ww> SteveH: yes
ww: get rid of langtags yes, but
map them to dts(?)
... want to make languages a tree of datatypes
PHayes: any proposal that removes langtags from syntax of RDF wont''t fly
ww: will write proposal to list
cygri: some discussion is needed
re. preference of different contrcete syntax forms
... e.g. in NTriples would now have two options, "foo", "foo"^^xsd:string
... there are different tradeoffs in different formats
... in NTriples is good that there's not much syntax variation
... would make things harder if I find both in the wild
... should we say that one SHOULD, MUST or SHOULD NOT use one of these forms
... or allow each spec to do it's own thing
... I think I disagree with AndyS about some format issues
[what]s AndyS's position?}
<PHayes> +1 to getting all this VERY CLEAR, for sure.
Guus: shortest form is usally preferable
+1 to VERY CLEAR
cygri: AndyS says that authors SHOULD use the shortest form, in SPARQL results I would really like to be able to know whether the strings are going to have the DT or not
+1 to cygri
<PHayes> Richard, you are shooting Andy in the foot here.
cygri: so a SHOULD isn't strong
enough to me
... in turtle I don't see the need
... would like to see a stronger statement
<PHayes> Everyone wants the query language to be both semantically transparent and also sensitive to the smallest lexical detail. Cant have it both ways, guys.
pchampin: I agree for need for
regularity, but maybe there are differences
... NTriples I see 3 alternatives
... allow both, bad idea
... keep shortest one, best of three, but some iregulariy, string literals must be treated in special way
<PHayes> How much legacy RDF is there out there that uses one and not the other? Do we ahve a choic eot not allow both?
<pfps> I'm feeling very weirded-out by all this SPARQL stuff. RDF is supposed to be about *meaning*, not syntax, not even abstract syntax!
pchampin: enforce xsd:string, but
breaks a lot of existing NTriples
... for the sake of back-compat we have to keep shortest form
<PHayes> Yes, pfps, but querying is all about syntactic matching. You betcha.
Guus: users typically use the shortest form, but sparql query uses the DT form
<pfps> Well, not as far as I am concerned. Querying is about retrieving meaning. (As opposed to straight entailment, which is simpler.)
I would be -1 to SPARQL using the long form, that's a lot of bytes
pchampin: I would be in favour of
MUST for NTriples and SPARQL res, but not others, but not sure
which form is best
... both would break some existing data, most reg. form is with the datatype
<PHayes> pfps, so listen to Richard. He wants to make queries which distinguish a from b when a = b is *necessary*. Any why not? Hos code has to handle the suyntax, not the meaning.
pchampin: explicit is better than
... there are a lot of plain literals out there
<ww> less typing, more clarity and consistency - make developers lives easy as possible.
cygri: for back compat we have to keep both forms valid
<ww> +1 cygri
cygri: we cant say that any forms would now be invalid in NTriples
<Guus> +1 for not using MUST
scribe: when parsing both forms are valid, but when serialising, only use one form,
<pchampin> +1, enforced regularity would break backward compatibility
<pchampin> +1 about distinguishing old stuff/new stuff
PHayes: I agree with Richard,
there's so much stuff out there, can't make it illigal
... one meaning can be expressed two different ways, the tool should treat them as equivalent
<Guus> 2 min left
PHayes: is results sensitive to the way the query is stated
<ww> +1 for tools treating them equivalently (and probably normalising them to w/ datatype internally)
<ww> +1 for fewer bytes on the wire
<PHayes> +1 to SteveH.
SteveH: the long form is less
... even though it's easier to canonicalise to
<pchampin> well, you are trading bandwith for (slight) code complexity
<pchampin> you're just moving the inefficiency somewhere else :)
Guus: is someone willing to look at cygri's proposal
<ww> pchampin: not only bandwidth - developers who look at it don't want to see extraneous cruft
Guus: next week re restart graphs
... hopefully can set a dte for graphs naming discussions
<cygri> ww, pchampin: by same argument, N-Triples should write 6 for "6"^^xsd:decimal
<pchampin> +1 cygri :)
<pchampin> bye all
<ww> cygri: that wouldn't be the end of the world, but agree there is a slippery slope
trackbot, end meeting
<davidwood> 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/would/could/ Succeeded: s/string enough/strong enough/ Found ScribeNick: SteveH Found Scribe: SteveH Inferring ScribeNick: SteveH WARNING: No "Topic:" lines found. WARNING: Replacing list of attendees. Old list: +1.540.898.aaaa Guus_Schreiber +3539149aabb SteveH mischat davidwood Peter_Patel-Schneider cygri ww AZ +1.443.212.aacc AlexHall [Sophia] pchampin PatH MacTed New list: +1.540.898.aaaa Guus_Schreiber +3539149aabb SteveH mischat davidwood Peter_Patel-Schneider cygri ww AZ +1.443.212.aacc AlexHall Default Present: +1.540.898.aaaa, Guus_Schreiber, +3539149aabb, SteveH, mischat, davidwood, Peter_Patel-Schneider, cygri, ww, AZ, +1.443.212.aacc, AlexHall Present: +1.540.898.aaaa Guus_Schreiber +3539149aabb SteveH mischat davidwood Peter_Patel-Schneider cygri ww AZ +1.443.212.aacc AlexHall WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/08-rdf-wg-minutes.html People with action items: cygri guus pchampin pfps WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]