See also: IRC log
<sandro> note-to-scribe --- we'll have to manually separate the IRC log of this meeting from that of the OWL telecon later today.
<baojie> is the call-in number 1.617.761.6200 (as in usual telcon)?
<sandro> yes
<baojie> thanks
<bmotik> Just to let everybody know: I'll need to shoot off in 45 minutes.
<bmotik> Something came up unexpectedly at 5pm CET
<AndyS> What's the call length? I have a cut off of +1hr
<sandro> 1hr
<scribe> scribenick: ericP
<sandro> 1. set of language tags
<alanr> PROPOSED: We understand that when RDF Concepts referred to RFC
<alanr> 3066 it really meanted "RFC 3066 or its successor" (which is
<alanr> currently BCP-47). We'll add a note to this effect to this spec.
<alanr> +1
<baojie> +1
<sandro> +1
+1
<pfps> +1
<bmotik> +1
<alanr> RESOLVED: We understand that when RDF Concepts referred to RFC
<alanr> 3066 it really meanted "RFC 3066 or its successor" (which is
<alanr> currently BCP-47). We'll add a note to this effect to this spec.
<alanr> PROPOSED: The datatype previously known as rdf:text should be
<alanr> called rdf:PlainLiteral
<alanr> +1
<AndyS> +1
<pfps> +0
<bmotik> +1
<sandro> +1
<baojie> +1
ericP: there is a related comment to DAWG
+1
<alanr> RESOLVED: The datatype previously known as rdf:text should be called rdf:PlainLiteral
<pfps> +0, as I don't care about the name
<alanr> PROPOSED: The title will no longer mention i18n. It will be something more like: A Datatype for RDF Plain Literals
<sandro> i18n == internationalization
<bmotik> +1
<alanr> +1
+1
<AndyS> no opinion
<sandro> +1
<pfps> +1, "current" name is good
<baojie> +0.75
<alanr> RESOLVED: The title will no longer mention i18n. It will be something more like: A Datatype for RDF Plain Literals
<alanr> PROPOSED: Pending approval from Michael Sperberg-McQueen, we'll remove the 3rd intro paragraph (from LC version). It talks about xml:lang, etc
sandro proposes that the 3rd para in the LC be removed
sandro: i removed MSM's suggested bidi text from the wiki, but have not heard from MSM
alanr: this is 'cause we're talking about plain literals, which are defined in another document
<alanr> PROPOSED: Pending approval from Michael Sperberg-McQueen, we'll remove the 3rd intro paragraph (from LC version). It talks about xml:lang, etc. If he does't approve we're fine with leaving something in the document about this.
<sandro> PROPOSED: Pending approval from Michael Sperberg-McQueen, we'll remove the 3rd intro paragraph (from LC version). It talks about xml:lang, etc. If he does't approve we'll keep it, with some reluctance.
<sandro> +1
<alanr> +1
<baojie> +1
ericP: i am reluctant to have i18n text quasi-defining plain literals as it is confusing to have definitions in multile places
<pfps> +1, as this implies that the paragraph is in (for now)
+1
<sandro> RESOLVED: Pending approval from Michael Sperberg-McQueen, we'll remove the 3rd intro paragraph (from LC version). It talks about xml:lang, etc. If he does't approve we'll keep it, with some reluctance.
sandro: the current abstract out of date
<pfps> the current abstract mentions "the dreaded i18n"
sandro: we need a new one which reflects what we settle on
<alanr> PROPOSED: rdf:PlainLiterals will map 1-1 to RDF Plain Literals, so Plain Literals with and without language are both handled by rdf:PlainLiteral.
<sandro> alan: we're NOT narrowing this to only handle language-tagged literals.
<bmotik> But this is already so, so I'm confused.
<pfps> Huh?
AndyS: not sure how you maintain 1:1 between rdf:PlainLiterals and xsd:strings
sandro: i'm not proposing a change to pfpf and bmotik's plan
alanr: the 1:1 mapping is in the value space
<bmotik> The value of each rdf:PlainLiteral literal will match one-to-one to the value of each plain RDF literal
AndyS: understand now. proposal didn't say that to me
sandro: the value space overlaps with xsd:string
<alanr> PROPOSED: rdf:PlainLiterals will map 1-1 to RDF Plain Literals, so Plain Literals with and without language are both handled by rdf:PlainLiteral.
<bmotik> +1
+0
<baojie> 0
<AndyS> +0
<sandro> sandro: see my e-mail of an hour ago --- the idea is you can map to/from rdf:PlainLiteral without getting confused about what's an xs:string
<sandro> +1
<pfps> +1, as this is what has been true from the beginning
<alanr> +1
<bmotik> Will this affect the document in any way? THat is, do I need to change anything in response? (Particularly given that this is how things work at present).
<alanr> RESOLVED: rdf:PlainLiterals will map 1-1 to RDF Plain Literals, so Plain Literals with and without language are both handled by rdf:PlainLiteral.
<bmotik> Great -- thanks!
sandro: i don't think so, barring editorial suggestions
<sandro> 7. backward-compatibility goal
sandro: i'm trying to get the
first piece of the interop goal
... specifically, do users have to change anything?
... i believe we are not suggesting that RDF applications
change
pfps: agreed
... until the LC, there was nothing in the doc that would
indicate that apps should change
... i believe that the wiki version changes all RDF apps
... "rdf:text datatyped literals MUST not appear in RDF
applications"
... adds policing requirement
<sandro> (sorry, pressed the wrong button on my phone.)
sandro: the current state is not your understanding of our goal?
pfps: it appears that folks are arguing this constraint in order to NOT change RDF apps
sandro: i think the only folks who should change are those who could get some benefit from it
<sandro> PROPOSED: We don't want any code out there to have to change because of this specification. Only new systems specifically intending to use it (eg RIF and OWL2) are pushed to implement it.
alanr: i understand pfps and PatH argue that the current text is too broad
pfps: i'm just interpreting the current doc. not ready to say what i want
PatH sent a draft yesterday
+1
i take that back
<bmotik> +1
AndyS: screw case: system 1 pubs data with ^^rdf:text, and old system 2 reads it and can't make use of it 'cause it's not a plain literal
sandro: i'd call that a push to change
<pfps> +0, we are not requiring code to change, but we *should* be encouraging code to change
<sandro> sandro: in my mind, if useful data is published using rdf:PlainLiteral, then consumers would be pushed.
ericP: i argue for striking the second sentence
<sandro> PROPOSED: We don't want any code out there to have to change because of this specification.
<alanr> PROPOSED: We don't want any code out there to have to change because of this specification.
AndyS: would do for me. 2nd sentence gets into how systems expose the information
pfps: i disagree.
... even harsh wording in the wiki does not have this
impact
... it allows ^^rdf:text to occur
<sandro> pfps: if people use it as a range, then there's some motivation out there....
pfps: this proposal prohibits rdf:text anywhere in a graph, e.g. <p> rdfs:range rdf:text .
PatH: apart from its effect on plain literals, it's an ordinary datatype name
<pfps> no - ... it allows rdf:text to appear *not* in the ^^ form
pfps: i agree, but i think the proposal violates it
sandro: ahh, even uttering the datatype encourages folks to implement it
<sandro> (skipping point 8, going on to point 9, brainstorming...)
PatH: propose a new flavor of
RDF, Plain-Typed RDF
... +restrictions:
... .. ^^rdf:text can't be uttered
... .. rdf:text can be uttered as a datatype name
... by naminng this slightly modified RDF, folks can say "i
conform to Plain-Typed RDF"
... allows impls and specs to refer to it
... e.g. OWL2 and RIF
<Zakim> alan, you wanted to ask what relation of rdfs is to new language?
PatH: proposed spec defines the datatype and the inference
AndyS: what's the status of deployed data?
PatH: existing RDF which doesn't (accidentally) use this datatype remains the same
alanr: how does this affect
RDFS?
... noting that RDFS is based on RDF, and OWL extends RDFS
PatH: in RDFS you have a new
built-in datatype
... class, range, reasoning applies to it
<Zakim> AndyS, you wanted to ask about MIME type
PatH: one could say "using RDFS(Plain-Typed"
AndyS: what about
mime-types?
... i fear this may be too clever
<Zakim> ericP, you wanted to argue that branching has consequences
<AndyS> ericP: Caution against branching because of matrix of interactions
<AndyS> ... suggest langauge for doc for don't write ^^rdf:text"
<AndyS> ... may or may not want to prevent ^^rdf:text in RDF (no OWL, RIF systems around)
<AndyS> ... but then have to operate on the as-is form (no lang tag implications)
alanr: you (pfps) listed an order of preferences
<alanr> http://www.w3.org/mid/20090527.092010.00457379.pfps@research.bell-labs.com
sandro: the six that pfps listed,
which i characterized as steps in increasing
restrictiveness
... starts with anyone can do anything
... 4 is a SHOULDn't
... 5 is a MUSTn't
alanr: consequences of 1 seem to lose opportunities to interpret ^^rdf:text as a plain literals
pfps: sparql is already broken in this way. we're not breaking it further
PatH: heard this argument many
times
... A i think that's poor practice
... B the ways it broken are edge cases. this will turn out to
be a central case
pfps: xsd:string has wide useage
on the web
... it exhibits the same behavoir as rdf:text
... so we're not breaking it any further
AndyS: filter functions were
designed with xsd:string and plain literals being treated the
same
... so implementations handle that case, while they would not
for rdf:text
pfps: i agree that some of the cruft in SPARQL is to paper over the problem in BGP matching
alanr: when discussing backward-compatibility goal, was this examplar the main case?
AndyS: my issue is new systems creating data which old systems don't understand
alanr: that was my intended characterization
<alanr> My second preference would be to just change the OWL 2 mapping to RDF
<alanr> graphs document to map rdf:text datatyped literal into plain RDF
<alanr> literals.
<alanr> My= Peter
<pfps> Change OWL 2 mapping to RDF to map rdf:text datatyped literals into plain RDF literals.
<bmotik> I'm afraid I need to leave now. Bye!
alanr: this is perhaps implicit in the current rdf:text doc
PatH: seems sensible, if we can't
do anything else
... but feels like putting a plug in a larger hole; we have
more to worry about than RIF and OWL2
<pfps> That is the next two options.
alanr: textual suggestion to make this apply to all analogous docs?
PatH: i think so
<alanr> My third and fourth preferences would be to say that applications (and
<alanr> recommendations) that incorporate rdf:text may/should be nice to older
<alanr> applications (and recommendatations) and therefore may/should not emit
<alanr> rdf:text datatyped literals in RDF syntaxes by changing them to plain
<alanr> literals.
alanr: what are the (dis)advantages of MAY, SHOULD, MUST?
pfps: i prefer MAY, can live with SHOULD, but MUST has a timelessness aspect to it
sandro: looks like MUST is split across 5 and 6
PatH: MUST it two strong
AndyS: i think SHOULD lasts as long as MUST
alanr: can we say "until an group chartered to modify RDF changes its mind"
AndyS: would expect that to be part of RDF
<alanr> My fifth preference would be to say that in *syntaxes* for RDF graphs,
<alanr> e.g., RDF/XML and Turtle, (and related syntaxes, such as any syntaxes
<alanr> for SPARQL basic graph patterns, I guess) the syntax for rdf:text
<alanr> datatyped literals *is* the syntax for plain RDF literals.
ericP: i would expect that to be in the "latest version" link to rdf:text
AndyS: i feel there is advantage in talking about syntax as that is what exchanged
PatH: [general approval, if ED understood it]
pfps: this doesn't change RDF
graphs is any way
... the underlying dicotomy remains, but you'd never notice
unless RDF gets updated to reveal it
<sandro> pfps: this is kind of a cheat, a bandaid -- the graphs aren't fixed, but you can't see it.
PatH: agreed
... does this propose that existing systems police
^^rdf:text?
pfps: umm, no
... PatH's proposal changes RDF in a fundamental way
<Zakim> ericP, you wanted to say that i strongly support "syntax for rdf:text literals *is* plain literals'
<alanr> 1. nothing 2. change mapping 3. should emit 4. syntax
<alanr> 1. nothing 2. change mapping 3&4. should emit 5. syntax
<sandro> <alanr> 1. nothing 2. change mapping 3 may emit. 4. should not emit 5. syntax
<pfps> 1,2
<sandro> 4,5
5
<baojie> 4,5
<sandro> pat: 5,1
<AndyS> 5,4 s/should/must/
<alanr> 5,4
<sandro> strawpoll: we'll do option 5
<sandro> +1
<pfps> +0
+1
<alanr> +1
<AndyS> +1
<baojie> +1
<sandro> pat: +1
<sandro> strawpoll: we'll do option 4
<sandro> +1
+.5
<pfps> +0
<AndyS> +0.75
<alanr> +.5
<sandro> pat: +0.8
<sandro> strawpoll: we'll do option 3
<sandro> pat: 0
-1
<pfps> +0.5
<AndyS> - 0.5
<sandro> -=
<alanr> -.
<sandro> -0
<alanr> -0.5
<baojie> 0
alanr: sentiment seems strongest for 5
<sandro> alan: the sentiment seems to be on the fifth proposal....
alanr: i don't believe PatH's has sufficient support given raised issues
<alanr> ok
<scribe> ACTION: pfps to suggest edits to the wiki page for options 5 [recorded in http://www.w3.org/2009/05/27-owl-minutes.html#action01]
<trackbot> Created ACTION-337 - Suggest edits to the wiki page for options 5 [on Peter Patel-Schneider - due 2009-06-03].
<AndyS> Thx
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: ericP Inferring Scribes: ericP WARNING: No "Present: ... " found! Possibly Present: AndyS IanH P3 P37 PROPOSED PatH Peter_Patel-Schneider Sandro aaaa alan alanr baojie bmotik ericP pat pfps rdf scribenick strawpoll trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 27 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/27-owl-minutes.html People with action items: pfps[End of scribe.perl diagnostic output]