W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2003

Re: minutes 2003-09-05 (draft for approval)

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 11 Sep 2003 13:29:25 +0100
Message-ID: <3F606AA5.4080408@hplb.hpl.hp.com>
To: Dan Brickley <danbri@w3.org>
Cc: w3c-rdfcore-wg@w3.org

Fixed up version for scraping.


2003-09-05 RDFCore WG meeting (60 mins)



date: 2003-08-29

Roll call:

   Dave Beckett
   Dan Brickley(scribe)
   Jan Grant
   Graham Klyne
   Brian McBride (chair)
   Eric Miller
   Patrick Stickler
   Jos De Roo
   Jeremy Carroll
   Dan Connolly
   Pat Hayes
   Frank Manola


   Mike Dean

Review agenda:
      - status of mimetypes
      - status of jang's test case (re intentional datatypes)
     (we covered former not latter)

Next telecon: 12 Sep 2003 1000 Boston Time for 60 minutes
   - danbri to chair
   - dave to scribe

5. Minutes of last telecon:



6. Confirm status of completed actions:

all Done.

7: Confirm Status of Withdrawn Actions

Noting that Dave Beckett _did_ review Primer, these
are marked withdrawn/done.

8: Doc Publishing status

Specs are on their way to /TR/ labelled Sept 05.

ericm: am hoping to see http://www.w3.org/TR/ reflect these
     ... all editors did  a great job getting pubrules ready

continuation of
2003-08-29#6  jang remove xmlsch-02 test cases.

jang: 'they reflect our current position'
   ...ws test cases back at pt where ws counts and isn't processed... a
   ' 1 ' isn't a valid integer
   ...i'd rather hang onto these tests.

brian: we discussed this before ...and decided to remove
    so jang you've held off as wg decision not clear...so let's leave
    as continued.

    ..also, i created 2 test cases, intentional test case... 2 are in the
    test case but marked as pending


note completed actions,
  2003-08-01#2    daveb sync with aaron on macintosh file type
  2003-08-29#2    jang check for/create if nec the xsd:string-entails

9: Doc Publishing - script for cross references

discussion of AOB re Mimetypes spec.

gk: current doc has just expired

brian: we had mail back ffrom Larry Masinter

DanC: did we call for review in ietf-types

gk: usually the call comes after the ID

DanC: but we've done one before. did we do a call before?

Brian: yes, we did.

DaveB: yes, its in their archives

DanC: so it isn't finished but we've started the process

DaveB: ietf-types posting by aaron 2003-july-24

gk: some changes needed following the existing review

ACTION: gk to check with aaron on status of the rdf mimetypes draft

gk: I offered to take it over last time... he seemed ok continuing the
task then.

brian: anything else on doc publishing?

aside... ...i did hear a view expressed of dissapointment in progress
we'd made. ...to me that's saying the glass is 10% empty not 90% full.
we've come a long way getting through the LC work this year. significant
progress, even if not quite where we hoped to be.

jjc: with hindsight we should have published editors drafts during LC period

brian: also re doc publishing...
...idea i had in mind was that all docs in shadow could be crosslinked,
linkchecked, and then write a script to do the substitutions.

...also would save Peter and others time

danbri: it would've made link checking easier this time

em: scripting would've made sense

DanC: don't do anything to encourage ppl to read editors drafts
...whatever is convenient for the wg is great.

danbri: it'll indirectly benefit them as /TR/ publishing won't be such
an ordeal.

jjc: we have at least 3 more pubs ahead of us

frank: folks like webont have close interest

DanC: pls don't make that mistake... they're outside, they should learn
	our work via /TR/

brian: script seems like a good idea

ACTION: danbri to investigation production of script for fixing up 
internal references

danbri: "I'll see what I can do in a week, might give the ball back if
not as easy as hope"

note: editors to freeze their shadow-TR work until danbri has framework
in place this week...

10: heads up re TAG rdfURIMeaning-39 and public-sw-meaning

DanC: history...
meeting in Cambridge tech plenary
...decided to take out social meaning, which we're just now
publishing...SW CG was supposed to do something
...we asked tag to make an issue
...he made a request time passed
...tag adopted issue but busy, said 'well get to it evnetually'
...meanwhile a mailing list came out of budapest bof
...i'm supposed to set up some kind of a meeting
...patH has already done that
...others i assume want to be there: timbl, danbri...

brian: basically there is now a mailing list for discussion of social
meaning issue

DanC: it would be in order for this wg to delegate someone

danbri: is there any expectation this'll impact on rdfcore's rec track
ambitions? ...or just a disucssion list

DanC: both/either seem possible

brian: a delegate... any volunteers?

danbri, pat: interested in participating, but not sure re representing
the group.

pat: does 'delegate' mean representing group's view
pat: i'm willing to volunteer so long as group gives me reasonably clear
brian: pat, your initial brief is to keep the wg informed
DanC: also tell the social meaning anything they need to know factually
about what's in the docs

RESOLVED: to appoint PatH as RDF Core representative to \
	public-sw-meaning, to provide factual information about RDF Core drafts\
	and to keep the RDF Core WG informed of progress in that forum.

11: xmlsch-02

jjc: talking to dave reynolds about this... (and re poss of withdrawing
the comment)... (so we owe him a reply to indicate we're not acting on
it). his actual comment was buried in an implementation report.
...we should draft something to explain to him what we're now doing, and

daver's report:

Regarding Danc's point re keeping social meaning group updated to
previous M&S and current RDFCore work in this area -

JosD: we also had same comments...
...3/4 of tests are not succeeding
...i u/stood that last week it was decided to obsolete test cases
...these things are not ideal several impl reports re test cases...
...either impls are wrong or test cases are wrong

brian: summary of current situation?

jang: we've remove the 'fudge' compromise wording...
...to remove the test cases themselves is to avoid the issue
...there either is, or isn't, an intereop problem.

jjc: daver says this could be fixed in jena...[...]

jjc: in conversaion, dave now seems to prefer current behaviour as most
useful approach. ...not convinced we should fix the impls

jang: thing w/ dealing w/ just the test case
...it's a legit LC question to say 'what is answer to this tc

brian: orig when we went to LC1 we said 'spaces not allowed'
...but we got feedback saying 'tats not what we do'
...so we went for laxer compromise
...but then feedback from pfps and others said 'dont be so lax'
...so we're back where we were

brian: two ways to be precise...one way is 'whats in graph must be in
lex space of datatype'. ..'whats in the graph is a string, which when
processed (...) is in lex space of datatype'.

DanC: latter would require impls to pick up knowledge they normally get
as a matter of course.

patrick: i'm v v uncomfortable... where we incl ws processing in lex to
value. ...several reasons. ...an app may choose to support xml schema
datatypes. ...but not be an xml processor nor have those libraries handy
.we're telling them they need to do something more than what datatypes
are. a pandora's box. ...not just ws processing.
..current tools happy saying 1.0 int is a perfectly ok typed literal
<- scribe missed detail of point.

...any lex form that an rdf processor can coerce into suitable form is
ok...this seems sloppy, heuristic.
..shouldn't use tools in context not meant for.

DanC: folks would read the xml schema specs, find the datatypes and
that'd be enough...

..but if our specs ref xml schema and xmls says do ws processing

[missed detail]

patrick: ws processing is only defined in xml schema

gk: meaning of spaces e.g. in " 3 "^^xsd:integer should be clearly

jang: we are chartered to ... (re special ref to xml schema)

gk: as i said in recent email, approach i'd suggest... follow approach
that says meaning of a typed literal only when the lex form is in lex
space of the datatype but not get into q of what happens when that isn't
so, would allow processors to do w/s processing to make inferences that
went beyond what core expects.

jjc: i find patrick's args fairly compelling
one extra point, .would introduce a new nromative ref on xml schema pt1.
currently our only normative refs are on pt2

DanC:  xml schema part 2 normatively cites part 1 anyway

DanC: request a straw poll

My latest position described at:

jjc: other thing came up when discussing datatyping...
...we wanted our datatyping mechanism general, not just w.r.t. xml
schema datatypes.

danbri: 2nded

jang: we wouldn't have to have extra text if xsd folk said the rdf
mapping is ...

pat: we should be careful about doing xsd's job for them
...similar to the issue re xml literature normalisation
...could say the graph syntax requires spare ws to be rejected
...but impls could store in non-normal form

danbri: sounds like softwre engineering in a w3c speca

pat: we already do that re normalisation

patrick: reason for ws processing is cleaning up variations
....clear from xmls spec that [mssed pt]

brian: i don't beleive alternative is any less precise
...i started this re 'does anyoen wish to propose a change to current

...anyone need a straw poll?


...is anyone willing to propose a change?

gk: yes. to be explicit re saying meaning of a typed literal is when lex
form is in lex space of the datatype

(various): already do so

gk: in which case i'm happy

jjc: gk is correct, we are precise

path: semantics require that an illformed literal isn't in val space

brian: does it say it doesn't denote a literal

gk: ' 3 ' isn't in lex space


DanC: ah, you're saying ' 3 ' wouldn't be explicitly treated

PatH: that would remove datatype clashes

JosD: looking at xsd:string... it'd be valid as a string

DanC: " oops! there goes all the value of these things!"
ie. as PatH points out that this would remove datatype clashes so you
couldn't observe inconsistencies ...this would undercut many benefits to

(discussion of whether it is in lex space)

JosD: ws facet on primitive datatypes -> remove wss

brian: i think i hear an action that we need to verify our
interpretation of the xsd spec

...patrick, would you want to do this?

DanC: we have a status quo

brian: gk was going to propose a change

...would be good to know if ' 3 ' *is* in the lex space

gk: If ' 3 ' *is* in the lex space of xsd:int, then the value would be
clear:  same as '3'^^xsd:integer... that is, I propose my changte

jjc: we have an approved test case that says it isn't; if jos has new
evidence pls submit to the list

josd: fair, i'll take an action

ACTION: josd to send msg re accuracy of the ' 3 ' test case

12: Datatype subclasses

brian; some discussion on list
DanC: The meeting noted that the WG owes Reynolds a response
...resolution 'datatype A is subclass of B "only if you/we say it is"'
(ie. same as normal subclassing; taking out the extentional subclassing
that we had left in in error)

path: i'm happpy

jang: we have test cases for this already

path: specs published today will have that in them

jjc: I propose the semantics of rdfs:subClassOf on datatypes as in the
5th Sept Working Draft

danbri: 2nded

connolly: abstain

[no other abstentions.]


13: RDF and I18N (skipping 13 for now)

14: Outstanding comments

( DanC: jos, http://www.w3.org/TR/xmlschema-2/#integer Lexical
representation clearly specifies the lexical space, and there are no
spaces in there.  (scribe note: re prev item?))

jjc: i have a draft of a response i could circulate

DaveB: from email he sent, he asked that we don't require nfc for xml
literals ...but we changed things since january
...new draft no longer says that.

jjc:  says lex forms must be
(this re Concepts)

jjc: concepts requires lex forms to be nfc, incl. xml literal

DaveB: ok in that case he is correct this is not in syntax doc

jjc: we don't say it explicitly. lots of things we don't.

path: 2 things he raised. internal consistency issue. also he makes a

DaveB: yup was just doing pt 1

jjc: we could do it the way he says
...that is, to produce warnings on plain literals tat are not in nfc
...we would need to talk w/ i18n guys about what they thought

brian: do we need to think about what answer  to this is?

DaveB: i18n's best practice rec'n is ifc

jjc: charmod encourages rejection of non-nfc data

ACTION: jjc to prepare a response to peter on charmod re \

[discussion of status of pfps comment on sectin 6.4 of concepts:]

gk: Concerning % in URI's, my last comment:

jjc: no response yet.
...i prefer 'no bytes to change'
...seen suggestion we add a note about this issue
...at one point i thought hard about this text... the closer this text
is to what others have written, happier i am.

gk: a note would be in order

ACTION: jjc to respond to peter on %'s in URIs re \
http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0282.html \
including a test case.

brian: hmm shouldn't uri guys do the test case
...though we have the foo and bar test cases
(test case in mailing list thread)

DanC: best response, "In case not clear in Concepts, here is test case"

The meeting closed.
Received on Thursday, 11 September 2003 08:55:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:25 UTC