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

set of language tags

<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

renaming of datatype

+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

changing title of document

<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

discussion of i18n

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.

discuss new abstract

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.

narrowing datatype to language-tagged literals

<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

backward compatibility

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

how to meet interrop requirements

<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