W3C RDF Core Working Group IRC Chat Logs for 2002-08-09

13:00:04 Users on #rdfcore: @logger_1

13:04:15 * DanC tries to do some timezone calculations...

13:30:49 * DanC -> ExML sessions...

13:38:36 <emil> emil has changed the topic to: rdf core teleconference - 2002-08-09

13:58:48 <bwm> G'day

13:59:04 <jang> zakim, who's here?

13:59:05 <Zakim> sorry, jang, I don't know what conference this is

13:59:07 <Zakim> On IRC I see Zakim, bwm, jang, JosD, emil, logger_1

13:59:27 <jang> zakim, list conferences

13:59:28 <Zakim> I see SW_RDFCore()10:00AM, Team_Ralph's(test), WAI_EOWG()8:30AM

13:59:37 <jang> zakim, this is sw_rdfcore

13:59:38 <Zakim> ok, jang

13:59:44 <jang> zakim, who's here?

13:59:44 <Zakim> +??P15

13:59:45 <Zakim> On the phone I see ??P13, FrankM, ??P15

13:59:46 <Zakim> On IRC I see Zakim, bwm, jang, JosD, emil, logger_1

13:59:57 <jang> zakim, ??P13 is ilrt

13:59:58 <Zakim> +Ilrt; got it

14:00:14 <jang> zakim, ilrt has bwm, daveb, jang

14:00:15 <Zakim> +Bwm, Daveb, Jang; got it

14:00:22 <jang> zakim, who's here?

14:00:23 <Zakim> On the phone I see Ilrt, FrankM, ??P15

14:00:24 <Zakim> Ilrt has Bwm, Daveb, Jang

14:00:25 <Zakim> On IRC I see Zakim, bwm, jang, JosD, emil, logger_1

14:00:39 <JosD> Zakim, ??P15 is JosD

14:00:40 <Zakim> +JosD; got it

14:00:57 <Zakim> +Mike_Dean

14:01:50 <Zakim> +Pat_Hayes

14:02:02 * RRSAgent is logging

14:02:11 <emil> zakim, this is RDFCore.

14:02:12 <Zakim> sorry, emil, I do not see a conference named 'RDFCore.'

14:02:19 <emil> zakim, list conferences

14:02:20 <Zakim> I see SW_RDFCore()10:00AM, Team_Ralph's(test), WAI_EOWG()8:30AM

14:02:29 <Zakim> +EricM

14:02:34 <emil> zakim, this is SW

14:02:35 <Zakim> this was already SW_RDFCore()10:00AM

14:02:36 <Zakim> ok, emil

14:03:16 <emil> zakim, who is here?

14:03:17 <Zakim> On the phone I see Ilrt, FrankM, JosD, Mike_Dean (muted), Pat_Hayes, EricM

14:03:18 <Zakim> Ilrt has Bwm, Daveb, Jang

14:03:19 <Zakim> On IRC I see RRSAgent, Zakim, bwm, jang, JosD, emil, logger_1

14:04:26 <Zakim> +??P18

14:05:01 <jang>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0090.html

14:05:24 <jang> jang is now known as jang_scri

14:05:26 <emil> zakim, who is here?

14:05:27 <Zakim> On the phone I see Ilrt, FrankM, JosD, Mike_Dean (muted), Pat_Hayes, EricM, ??P18

14:05:28 <Zakim> Ilrt has Bwm, Daveb, Jang

14:05:29 <Zakim> On IRC I see RRSAgent, Zakim, bwm, jang_scri, JosD, emil, logger_1

14:05:31 <jang_scri> roll call

14:05:39 <emil> zakim, ??P18 is RonD.

14:05:40 <Zakim> +RonD.; got it

14:05:55 <jang_scri> reg danc, gk, jjc

14:06:14 <jang_scri> nextr telecon: next week, 16 august

14:06:36 <jang_scri> minutes from previous telecon: (url in agenda)

14:06:44 <jang_scri> jos sends regrets for next two weeks

14:07:17 <jang_scri>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0030.html

14:07:18 <jang_scri> last minutes

14:07:28 <jang_scri> accepted

14:07:42 <jang_scri> 6. proposed closed actions.

14:08:02 <jang_scri> all ok.

14:08:06 <jang_scri> few open actions.

14:08:08 <Zakim> +??P19

14:08:21 <jang_scri> sergei turns up

14:08:23 <emil> zakim, ??P19 is Sergey.

14:08:24 <Zakim> +Sergey.; got it

14:08:26 <jang_scri> zakim, ??p19 is sergei

14:08:28 <Zakim> sorry, jang_scri, I do not recognize a party named '??p19'

14:08:37 <jang_scri> [thanks emil]

14:09:19 <jang_scri> action bwm have a good holiday, CLOSED

14:09:36 <jang_scri> gk's actions 2002-08-02#1 also CLOSED

14:09:54 <jang_scri> item 7, datatypes

14:10:10 <jang_scri> [missing some important people from discussion, beginning with sergei though]

14:10:27 <Zakim> +PatrickS

14:11:17 <jang_scri> emil: summarises how we got here thus far

14:11:22 <jang_scri> ericM, rather

14:11:39 <jang_scri>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0030.html

14:11:47 <jang_scri> why xsi:type?

14:11:53 <jang_scri> no response from xml coord people

14:12:10 <jang_scri> for the sake of this discussion... em will like to assume xsi:type is open to all sorts of datatypes

14:12:24 <jang_scri> em invites sergei to outline proposal

14:12:50 <jang_scri> this amounts to extending abs syntax of rdf to accommodate additional constants

14:13:05 <jang_scri> patricks raised whether this extension is neutral to rdf framework or not

14:13:09 <jang_scri> my belief is that it is

14:13:19 <jang_scri> since in principle anyone can define constants in the abs syntax

14:13:31 <jang_scri> the problem is to make constants interoperable

14:13:38 <jang_scri> this is where concrete syntax kicks in

14:13:49 <jang_scri> the feeling that I got from path, guha is that this isn't a problem

14:13:53 <jang_scri> so it _is_ neutral

14:14:03 <jang_scri> sergei: also let me first get rid of the xsi:type issues.

14:14:18 <jang_scri> first issue is is it conformant to what xml schema says

14:14:27 <jang_scri> two views: one is mine, one is pats'

14:14:39 <jang_scri> we have to wait for response from xml group to resolve this

14:14:48 <jang_scri> zakim, ilrt also has danbri

14:14:50 <Zakim> +Danbri; got it

14:15:00 <jang_scri> rdf:type is part of rdf vocab

14:15:04 <jang_scri> also appears in xml syntax

14:15:10 <jang_scri> but properties will be generated for that

14:15:13 <jang_scri> in contrast,

14:15:24 <jang_scri> xsi:type xml syntax is a parser-interpreted

14:15:29 <jang_scri> and doesn't appear in the graph

14:15:50 <jang_scri> it is the job of the parser to detect those constructs and to map constants onto abs syntax

14:15:58 <jang_scri> so in the graph xsi:type arcs don't appear

14:16:07 <emil> q+

14:16:08 * Zakim sees Emil on the speaker queue

14:16:21 <jang_scri> so in other syntaxes, there might be other syntaxes

14:16:36 <jang_scri> eg, ntriples syntax would have some shorter form for typed values than rdf/xml

14:16:43 <jang_scri> is that ok? (to pats)

14:16:47 <jang_scri> pats: no, but go on

14:16:53 <jang_scri> sergei:

14:17:11 <jang_scri> the third problem is the SITG proposal referenced by pats so many times in response

14:17:20 <jang_scri> yes, sitg is good and everyone understands that it is appealing

14:17:24 <jang_scri> the problem appears to be...

14:17:34 <jang_scri> that sitg also implies two extra things

14:17:38 <jang_scri> global typing idiom

14:17:42 <jang_scri> tidyness problem

14:17:46 <jang_scri> both proving hard to agree on

14:17:54 <jang_scri> this is how we came to this much simpler idiom

14:18:04 <jang_scri> pats: this doesn't resolve those issues, it punts on them

14:18:16 <jang_scri> it says we don't address global, etc. problems

14:18:29 <jang_scri> sergei: we don't have the claim that we can provide an extensible scheme...

14:19:04 <jang_scri> pats: I didn't recognise those issues being addresses in the summaries

14:19:13 <jang_scri> sergei: I'm repeating gk's summary effectively

14:19:32 <jang_scri> it's much harder to agree on global and tidy than to go ahead with the more simple solution

14:19:35 <jang_scri> that can then be extended

14:19:42 <jang_scri> it seems an easier path given the time constraints

14:19:44 <emil> q?

14:19:45 * Zakim sees Emil on the speaker queue

14:19:47 <jang_scri> pats:

14:19:57 <jang_scri> firstly, this latest proposal is only addressing local dting

14:20:01 <jang_scri> and cuts out global

14:20:05 <jang_scri> and ignores tidyness

14:20:14 <jang_scri> do we still need to address these?

14:20:20 <jang_scri> second: you say it's extensible...

14:20:32 <jang_scri> but you seemed to say you'd add native primitive DTs

14:20:37 <jang_scri> that all apps would have to support

14:20:39 <jang_scri> that's not extensible

14:20:57 <jang_scri> sergei: that's one question: should there be a set that apps need to support to procvide basic interop?

14:21:09 <jang_scri> pats: should there exist a standard set of dts?

14:21:16 <jang_scri> secondly, should they be native to rdf?

14:21:26 <jang_scri> you presume that the answer to 2 is yes

14:21:34 <jang_scri> I'm saying that they don't need to be any native ones

14:21:45 <jang_scri> we should have no standard ones

14:21:51 <jang_scri> then we can choose them ad hoc.

14:22:00 <jang_scri> sergei: we have to agree on something

14:22:07 <jang_scri> pats: why do WE have to agree on them?

14:22:15 <jang_scri> pathaye: what do you mean by native?

14:22:23 <jang_scri> (to pats)

14:22:41 <jang_scri> pats: native in the sense that in the graph syntax there are local names such as int, string etc

14:22:43 <jang_scri> defined by rdf spec

14:22:50 <jang_scri> that you map things to

14:22:59 <jang_scri> so moving things from other (eg, java) platform

14:23:04 <jang_scri> you need to coerce into those

14:23:12 <jang_scri> path: suppose we use specifically xml dts?

14:23:23 <jang_scri> pats: no, that's just defining native dts

14:23:32 <jang_scri> what about my BLARG datatypes?

14:23:43 <jang_scri> I can't define it in the graph, I'm [stumoed]

14:23:53 <jang_scri> sergei: not in the level of the graph syntax

14:24:16 <jang_scri> pats: the whole point is interchange of data

14:24:20 <jang_scri> if you can't do that then WHY?

14:24:35 <jang_scri> interop is being killed by the notion of native types

14:24:44 <jang_scri> i don't mind adding typed literals

14:24:58 <jang_scri> but the expression should be as generic and neutral as poss

14:25:16 <jang_scri> ie, don't mandate "xsd string" as THE string

14:25:23 <jang_scri> allow omg dts, etc. as desired

14:25:37 <jang_scri> sergei: what I hear is that you want to have a way of introducing arbitrary dts in rdf

14:25:44 <jang_scri> at this point in time we canb't do that at all

14:25:53 <jang_scri> there's no way to relate those to lexical forms, etc.

14:26:00 <jang_scri> this is the only way to provide extensible datatyping

14:26:05 <jang_scri> pats:

14:26:13 <jang_scri> you're expecting rdf engines to grok the DTs

14:26:20 <jang_scri> rdf doesn't have to grok the DTs

14:26:39 <jang_scri> particular apps will recognise particular DTs and know how to compare them

14:26:44 <emil> q?

14:26:45 <jang_scri> rdf itself should be agnostic

14:26:45 * Zakim sees Emil on the speaker queue

14:27:20 <jang_scri> eric: asks for any other comments

14:27:26 <jang_scri> JosD: i'm in favour

14:27:38 <jang_scri> i understand pat's concerns, has never been in our charter, I'm sorry for that

14:28:54 <JosD> JanG: likes it too...

14:29:01 <jang_scri> jang_scri: i hear sergei and pats in violent agreement

14:29:09 <jang_scri> eric: anyone else? brian?

14:29:15 <jang_scri> (as implementor)

14:29:26 <jang_scri> anything in jena match this?

14:29:32 <jang_scri> bwm: I've not thought that hard about implementation

14:29:40 <emil> zakim, who is here?

14:29:41 <Zakim> On the phone I see Ilrt, FrankM, JosD, Mike_Dean, Pat_Hayes, EricM, RonD., Sergey., PatrickS

14:29:42 <Zakim> Ilrt has Bwm, Daveb, Jang, Danbri

14:29:44 <Zakim> On IRC I see sergey, RRSAgent, Zakim, bwm, jang_scri, JosD, emil, logger_1

14:29:47 <jang_scri> my instincts are that this is actually a good way to go from an implementation point of view

14:29:57 <jang_scri> this is what you'd want in a DB implementation

14:30:14 <jang_scri> whilst part of me likes the bnode idiom

14:30:25 <jang_scri> you end up having to infer the structure proposed from the bnode idiom

14:30:35 <jang_scri> so from an implementation pov this sounds reasonably sensible

14:30:47 <jang_scri> eric: this is pretty much how th e4th group have done this

14:30:58 <jang_scri> their concern is large-scale rdf triplestore stuff

14:31:06 <jang_scri> what bwm describes is in line with how they've done that

14:31:09 <jang_scri> mike:

14:31:19 <jang_scri> several comments made on the draft that didn't get folded in in time

14:31:30 <jang_scri> the proposal for the most part is a good one for local dting

14:31:39 <jang_scri> I'm still nervous about providing just local dting

14:31:46 <jang_scri> one of my questions is...

14:32:01 <jang_scri> introducing xsd dts and using rdf range is the machinery for global dting

14:32:07 <jang_scri> (seems to me)

14:32:12 <jang_scri> I'm nervous about only local dting

14:32:22 <jang_scri> sergei: to mike - you have to distinguish between

14:32:27 <jang_scri> implicit and explicit global typing

14:32:37 <jang_scri> mike: global implicit is what I care about

14:32:50 <jang_scri> the other thing is that xml dts are the thing we need to address

14:32:59 <jang_scri> I'm worried about diluting the focus in terms of extensibility

14:33:10 <jang_scri> it's the w3c standard, it makes sense to build on it

14:33:26 <jang_scri> q?

14:33:28 * Zakim sees Emil on the speaker queue

14:33:46 <jang_scri> daveb: I keep hearing xsi:type in the xml syntax

14:33:52 <jang_scri> I wouldn't propose that we use that term

14:34:02 <jang_scri> (worried about finishing, etc)

14:34:11 <jang_scri> I'd like to support xml schema dts but not exclusively

14:34:17 <jang_scri> let people put whatever uri they like

14:34:20 <jang_scri> that's the rdf way

14:34:25 <jang_scri> amens from sergei, pats

14:34:41 <jang_scri> eric to danbri: your ruby stuff?

14:34:50 <jang_scri> you see optimisation here that might be reflected in your code?

14:34:57 <jang_scri> I think it's looking good

14:35:03 <jang_scri> I also agree with dave - what he said

14:35:15 <jang_scri> eric: can you repeat that again?

14:35:40 <jang_scri> [jang reads last few paras]

14:35:56 <jang_scri> eric: it sounds like sergei, pats aren't terribly in disagreement

14:36:03 <jang_scri> can you just assign URIs to these thingss

14:36:13 <jang_scri> ... what I'm basically saying is

14:36:22 <jang_scri> you guy's aren't disagreeing on the focus on extensibility here

14:36:35 <jang_scri> but trying to graft in a low-level set for what makes sense now for implementaiton

14:36:55 <jang_scri> sergei: what all of us want is that in the rdf/xml syntax we can assign arbitrary type uris

14:37:02 <jang_scri> or use arb. uris for type designation.

14:37:08 <jang_scri> is that what dave said? (yes)

14:37:12 <jang_scri> i can only agree with that

14:37:20 <jang_scri> eric: so patrick's blarg type...?

14:37:39 <jang_scri> sergei: he's just define a uri for it

14:37:57 <jang_scri> path: so you'd have

14:38:06 <jang_scri> jenny age [blarg-uri]"10" .

14:38:22 <jang_scri> daveb: I'm assuming we'd revisit the "lits are 3-part structures" decision

14:38:34 <jang_scri> eric ok, let's put that on the table and see where else we can go?

14:38:41 <jang_scri> frankm: question in clarification:

14:39:05 <jang_scri> i hear general agreement that in the new proposal there's this sort of parameter which is a dt name

14:39:24 <jang_scri> we want to be able to put -eventually- arbitrary refs to things that are types

14:39:33 <jang_scri> we want xsd:integer, blarg-types, etc.

14:39:49 <jang_scri> the apparent disagreement is whether we start off in the spec with refs to some of the xml schema dts

14:40:06 <jang_scri> and basically say if you want to build an rdf processor you have to know about these

14:40:32 <jang_scri> eric: that's what I understand, and I appreciate the clarification

14:40:37 <jang_scri> sergei, miked agree

14:40:47 <jang_scri> frankm: so the argument is do we seed this mechanism with anything?

14:40:52 <jang_scri> eric: pats, comments?

14:41:13 <jang_scri> pats: firstly, for the record I'd like to point out that these are val: URIs, as I brought to the table in day one

14:41:39 <jang_scri> I'm quite happy with the idea with a single node in the graph singly globally consistently denotes a dt value

14:41:42 <jang_scri> two things:

14:41:53 <jang_scri> one of them might have been editorial due to time constraints

14:42:13 <jang_scri> I got the impression that the abs graph syntax woulod include standard abs names for DTs

14:42:22 <jang_scri> second: what is the burden on RDF applications?

14:42:41 <jang_scri> so I think that that raises the bar on what is an rdf application

14:42:45 <jang_scri> it's sufficient to say

14:42:55 <jang_scri> you don't have to know anything about rdf dts apart from how you express them

14:43:03 <jang_scri> we strongly reccommend that you use these

14:43:16 <jang_scri> eric: last point i support fully

14:43:36 <jang_scri> i think a lot of poelpe will bootstrap based on xsd, period

14:43:42 <jang_scri> [daveb wants to go on the queue]

14:43:46 <bwm> q+

14:43:47 * Zakim sees Emil, Bwm on the speaker queue

14:43:54 <emil> q-

14:43:55 * Zakim sees Bwm on the speaker queue

14:43:56 <jang_scri> path: I don't think it's unreasonable to give those special consideration

14:44:12 <jang_scri> daveb: i agree with what pats is saying

14:44:21 <jang_scri> parsing of theese typed literals return a uri plus a blob

14:44:25 <jang_scri> and let the app sort it out

14:44:31 <emil> q+ pat

14:44:32 * Zakim sees Bwm, Pat on the speaker queue

14:44:35 <emil> q-

14:44:36 * Zakim sees Bwm, Pat on the speaker queue

14:44:36 <jang_scri> q- bwm

14:44:38 * Zakim sees Pat on the speaker queue

14:44:55 <jang_scri> pat: specifically wrt ownership of these proposals:

14:45:08 <jang_scri> these are rdfcore proposals, I can't stress that strongly enough

14:45:12 <jang_scri> this is from everyone, period

14:45:23 <jang_scri> path:

14:45:39 <emil> q- pat

14:45:40 * Zakim sees no one on the speaker queue

14:45:49 <jang_scri> let me see if I can get this right...

14:45:55 <jang_scri> ... let me play devil's advocate

14:46:07 <jang_scri> does this proposal have any real advantages over bnode dt idiom

14:46:13 <jang_scri> [pats: bing!]

14:46:19 <jang_scri> so what's the big advantage?

14:46:41 <jang_scri> it takes a bnode, the DT and a literal and makes one literal out of it

14:46:47 <jang_scri> what's the conceptual advantage?

14:46:54 <jang_scri> it still doesn't allow for range datatyping

14:47:00 <jang_scri> miked: yes it does, it tells you how to do it

14:47:26 <jang_scri> path: you can't say jenny age "10" then have a range on age that makes "10" morph into the right kind of literal

14:47:56 <jang_scri> mike: the bonde approach is problematic in terms of size of triple store

14:48:04 <jang_scri> q+

14:48:05 * Zakim sees Jang on the speaker queue

14:48:14 <jang_scri> how about if we offer this as an abbreviation?

14:48:19 <jang_scri> (that's path again)

14:48:26 <jang_scri> has the same meaning as the local dt idiom

14:48:43 <jang_scri> I can see advantages to the bnode idiom myself

14:48:51 <jang_scri> specifically, it fits into rdf without changing the syntax

14:49:09 <jang_scri> we're looking at a major change to the syntax driven by a factor of two

14:49:13 <jang_scri> that seems inappropriate

14:49:35 <jang_scri> what about containers?

14:49:50 <jang_scri> pats: not many of your triples will be dt literals

14:49:58 * emil see's jang on the queue

14:50:09 <jang_scri> miked: most people want to type all of their literals

14:50:16 <jang_scri> rond: I don't think you CAN make that assumption

14:50:23 <jang_scri> miked: all the apps I'm aware of satisfy that

14:50:39 <jang_scri> pats: I support that - that most people wish to use global implicit datatyping

14:50:42 <emil> q-

14:50:43 * Zakim sees Jang on the speaker queue

14:50:45 <sergey> q+

14:50:47 * Zakim sees Jang, Sergey on the speaker queue

14:50:52 <emil> q- jang

14:50:53 * Zakim sees Sergey on the speaker queue

14:52:42 <jang_scri> q+ pats

14:52:43 * Zakim sees Sergey, Pats on the speaker queue

14:52:46 <emil> q+ Patrick

14:52:47 * Zakim sees Sergey, Pats, Patrick on the speaker queue

14:52:48 <jang_scri> q- sergey

14:52:49 * Zakim sees Pats, Patrick on the speaker queue

14:52:56 <emil> q- Pats

14:52:57 * Zakim sees Patrick on the speaker queue

14:53:02 <jang_scri> sergei: first I'd like to challenge that this makes a major change to rdf

14:53:09 <jang_scri> in my opinion, it doesn't

14:53:18 <jang_scri> in the abs syntax, there's no concrete rep for literals

14:53:22 <jang_scri> these are just nodes in a graph

14:53:32 <jang_scri> so the abs syntax is agnostic to the type that you'r'e using

14:53:48 <jang_scri> path: that's correct syntactially, my concerns are semantic

14:54:04 <jang_scri> sergei: we define fixed meaning for a small set of those literals

14:54:09 <jang_scri> the major challenge, instead...

14:54:29 <jang_scri> ... is that rdf/xml and ntriples should provide forward-compatible mechanism for future types

14:54:41 <jang_scri> i don't see this introduction of new constants as a new change to the rdf graph syntax

14:54:58 <jang_scri> path: ok, if these were just opaque constants, but they're not

14:55:03 <jang_scri> sergei: i also oppose that view

14:55:12 <jang_scri> they have NO internal structure in the level of MT

14:55:19 <emil> <e rdf:parseType="ns:myBlagType">43r843759843758</e>

14:55:21 <jang_scri> path: but they NUST!

14:55:22 <emil> opps.. sorry

14:55:42 <jang_scri> sergei: we don't have to do that. as soon as we provide a uri for the type

14:55:55 <jang_scri> we can say the class extension of that type amounts to the enumeration of the members of that type

14:56:00 <jang_scri> point 2....

14:56:07 <jang_scri> this need for global implicit idiom...

14:56:15 <jang_scri> if you look at current programming languages

14:56:17 <bwm> bwm requests chair summarize what has been agreed

14:56:20 <jang_scri> there is no global implicit idiom

14:56:29 <jang_scri> you have to explicitly write "5" to make a string

14:56:37 <jang_scri> or 5L to make it a long

14:56:44 <jang_scri> (depending on language)

14:57:14 <jang_scri> in general, explicit encoding of constants expresses types

14:57:23 <jang_scri> path: rdf isn't a programming language

14:57:29 <emil> q?

14:57:30 * Zakim sees Patrick on the speaker queue

14:57:32 <jang_scri> pats: I pointed out yesterday...

14:57:36 <emil> q- Patrick

14:57:37 * Zakim sees no one on the speaker queue

14:57:41 <jang_scri> xml schema has global typing with untidy literals

14:58:01 <jang_scri> (pats illustrates xml schema dting mechanism)

14:58:33 <jang_scri> xml schema does global explicit untidy datatyping

14:58:53 <jang_scri> sergei: manual encoding. nobody cares about machine effort; we care about how much work it is to write this manually

14:59:14 <jang_scri> nobody comkplains about this in programming languages... I don't accept it as a valid argument, therefore

14:59:17 <emil> q+

14:59:18 * Zakim sees Emil on the speaker queue

14:59:40 <jang_scri> pats: people ARE using implicit literals

14:59:55 <jang_scri> the reality is that out there, people ARE using implicit global tpying with untidy semantics

15:00:07 <jang_scri> path: I'd also point out that if danc were here...

15:00:25 <jang_scri> ... that he'd point out you can test identity of literals by doing string matching

15:00:31 <jang_scri> so "10" with no type

15:00:42 <jang_scri> is not a number, a string, ertc. it's not anything??!

15:01:00 <bwm> its something else instead

15:01:30 <jang_scri> frankm again:

15:01:35 <jang_scri> it seemed to me ...

15:01:57 <jang_scri> that when sergei and mike were talking about the need of explicit type in literal to say what its type was...

15:02:05 <jang_scri> ... in what context are you considering the literal?

15:02:16 <jang_scri> in programming languages, you're always talking about the value of a typed variable...

15:02:40 <jang_scri> and so the analogy doesn't seem to hold....

15:02:47 <jang_scri> what we're talking about these literals...

15:03:00 <jang_scri> are they in a context where we magically know the type associated with them, or not?

15:03:34 <jang_scri> you're taking the range on the property name... you're using instance data and you need the property to get the range

15:03:41 <jang_scri> eric: at the top of the hour: extension?

15:03:55 <jang_scri> 1. in general, people seem pleased with this proposal

15:04:14 <jang_scri> this isn't radically new, earlier proposals seem to have said something like this

15:04:20 <jang_scri> so maybe this is the right approach.

15:04:23 <jang_scri> can people stick around?

15:04:29 <jang_scri> [yesses]

15:04:35 <jang_scri> 30 minutes extension

15:04:40 <jang_scri> ... ok with that?

15:04:48 <jang_scri> rond: I'm going to have to go, sorry.

15:04:53 <Zakim> -RonD.

15:05:25 <jang_scri> I'd like to try to get some way forward - some in principal agreement from the group here

15:05:47 <jang_scri> eric prefers not to do position speeches, but comments are ok

15:05:53 <jang_scri> path offers a comment: (in haiku?)

15:06:11 <jang_scri> I have no objections to this, but this DOESN't solve any of the difficult problems we've been stuck on

15:06:28 <jang_scri> it doesn't solve range issues, how to add DTing information incrementially (semantically)

15:06:41 <jang_scri> it just is another, more compact local idiom.

15:07:01 <jang_scri> if it's worth going to the trouble, fine. I'll raise my eyebrows but keep schtum.

15:07:15 <emil> q+

15:07:16 * Zakim sees Emil on the speaker queue

15:07:16 <jang_scri> sergei: we never pretended that this solved implicit global dting.

15:07:27 <jang_scri> comment from pats:

15:07:33 <jang_scri> ditto on what path said, plus:

15:07:44 <jang_scri> I'd like to refer to this as a subproposal regarding the syntax of the local idiom

15:07:52 <jang_scri> to that end, fine

15:08:01 <jang_scri> BUT

15:08:14 <jang_scri> we've got this huge decision of tidy versus untidy and long-range typing

15:08:22 <jang_scri> and I don't think it's ok to punt on those

15:08:45 <jang_scri> sergei: question: how significant are those two issues?

15:08:51 <jang_scri> if we drop them, what happens?

15:08:56 <jang_scri> (to path, the MT guru)

15:09:08 <jang_scri> path: obviously, it simplifies things to drop difficult issues (!)

15:09:21 <jang_scri> do we set in stone things that cause semantic difficulty in the future.

15:09:25 <jang_scri> in this proposal...

15:09:33 <jang_scri> what do we do about literals that don't have a type.

15:09:42 <jang_scri> are they fixed to denote character strings (yes from sergei?)

15:09:48 <jang_scri> we have to say something about that

15:09:54 <jang_scri> almost anything we say is either controversion

15:09:59 <jang_scri> s/sion/sial

15:10:17 <jang_scri> sergei: we don't put it into the abstract syntax

15:10:26 <jang_scri> pats: what's in the ntriples?

15:10:32 <jang_scri> sergei: in the graph they're constants

15:10:43 <jang_scri> in ntriple it'll be something that daveb invents

15:10:50 <emil> q+

15:10:51 * Zakim sees Emil on the speaker queue

15:10:56 <emil> " "

15:10:59 <jang_scri> pats: so every api will have to know the internalised form of every type... how silly

15:11:07 <jang_scri> eric: but isn't that what already happens?

15:11:22 <jang_scri> it's not that we don't know that stuff.. we're talking about reflecting that in terms of this idiom

15:11:24 <emil> "(literal)fnjdnjdfng"

15:11:43 <jang_scri> ... i don't see the big isue

15:11:59 <jang_scri> path: in some broad sense what we're trying to invent a language for expressing fats about things

15:12:05 <jang_scri> we've a simple syntax for doing that

15:12:10 <jang_scri> this proposal says

15:12:27 <jang_scri> some facts have all their propositional context compressed into one small block

15:12:33 <jang_scri> my gut reaction is "why"?

15:12:39 <bwm> q+

15:12:40 * Zakim sees Emil, Bwm on the speaker queue

15:12:43 <jang_scri> answers are to do with implementation efficiency

15:12:43 <emil> q-

15:12:44 * Zakim sees Bwm on the speaker queue

15:12:49 <jang_scri> let's be upfront about why we're doing it this way

15:12:54 <jang_scri> jod: I agree, pat, but...

15:13:07 <jang_scri> the most important thing is to have shorthand for common primitive tpyes

15:13:27 <jang_scri> I don't think extensibility as a first issue

15:13:34 <jang_scri> only be concerned with primitive XML dts

15:13:56 <jang_scri> path: any proposal (not just this one) to extend the syntax

15:14:01 <jang_scri> carries a potential burden

15:14:10 <emil> q+

15:14:11 * Zakim sees Bwm, Emil on the speaker queue

15:14:20 <jang_scri> let's say we allow a previous dting mechanism PLUS this local mechanism.

15:14:34 <jang_scri> what about _:a xsd:integer (xsd:string)"foo"

15:14:50 * emil see's bwm on the queue...

15:14:58 <jang_scri> sergei: that mechanism hasn't been standardised yetr

15:15:31 <emil> q+ to discuss representation of xml:lang and potential relationship

15:15:32 * Zakim sees Bwm, Emil on the speaker queue

15:16:16 <emil> q+

15:16:17 <jang_scri> the fact that these are tidy, this is a contradiciton

15:16:17 * Zakim sees Bwm, Emil on the speaker queue

15:16:19 <emil> q+ Pat

15:16:20 * Zakim sees Bwm, Emil, Pat on the speaker queue

15:16:26 <emil> q- Pat

15:16:27 <jang_scri> eric: bwm?

15:16:27 * Zakim sees Bwm, Emil on the speaker queue

15:16:29 <emil> q+ Patrick

15:16:30 * Zakim sees Bwm, Emil, Patrick on the speaker queue

15:16:43 <jang_scri> brian: I'm intrigued in the direction we're going with this conversation

15:17:09 <jang_scri> it seems to me that if we've got to arguing about sitg or compact tpyed literal

15:17:23 <jang_scri> then have we agreed that the global implicit idiom is not something we're going to support?

15:17:41 <jang_scri> miked: I couldn't say that

15:18:01 <jang_scri> bwm: we're out of time

15:18:06 <jang_scri> very soon we have to go with what we agree

15:18:14 <jang_scri> danbri back up brian as other chair

15:18:27 <jang_scri> bwm: so can we capture any agreement?

15:18:36 <jang_scri> path: this proposal...

15:18:43 <jang_scri> has received a great deal of assent

15:18:49 <jang_scri> I don't want to kill it

15:19:02 <jang_scri> but I don't want that approval to be based o the misapprehension

15:19:09 <jang_scri> that this solves things that it DOESN't solve

15:19:19 <jang_scri> bwm: people didn't seem to like the question we put to rdfig

15:19:39 <jang_scri> the other feedback was a strong hint that we should look at the type of a literal being explicit in the syntax

15:19:47 <jang_scri> that's what peter, drew were saying

15:19:55 <jang_scri> when I came back and saw this proposal, I thought, great

15:20:10 <jang_scri> people have picked up on that suggestion and are going with making type explicit in syntax

15:20:18 <jang_scri> iked: theoreticians, not implementors

15:20:41 <jang_scri> eric: request for making this explicit was coming from both camps

15:20:48 <jang_scri> I thought bloody hell, they're agreeing

15:20:52 <jang_scri> [last comment anglicised]

15:21:01 <emil> q?

15:21:02 * Zakim sees Bwm, Emil, Patrick on the speaker queue

15:21:05 <emil> q-

15:21:06 * Zakim sees Bwm, Patrick on the speaker queue

15:21:17 <emil> q-

15:21:18 * Zakim sees Bwm, Patrick on the speaker queue

15:21:23 <emil> q- Bwm

15:21:24 <jang_scri> we have only 10 more minutes... I'd like to have a discussion as to where we go from here

15:21:24 * Zakim sees Patrick on the speaker queue

15:21:27 <jang_scri> pats: occams razor:

15:21:31 <emil> q- Patrick

15:21:32 * Zakim sees no one on the speaker queue

15:21:40 <jang_scri> I support single node for unaboiguously and globally denotes value

15:21:42 <jang_scri> it's tidy

15:21:48 <jang_scri> that's a URI, ok?

15:21:56 <jang_scri> that's the job that URIs are supposed to do

15:22:06 <jang_scri> [argues for URV]

15:22:24 <jang_scri> extending the graph syntax at this stage when a URi will do...

15:22:36 <jang_scri> we should set aside aesthetics and just use URIs

15:22:49 <jang_scri> that's all i want to say now.

15:23:32 <jang_scri> JosD: the MT ...

15:23:38 <jang_scri> pats: hasn;'t been agreed on

15:23:55 <jang_scri> JosD: the current MT is more of a sitg that the DT doc

15:24:54 <jang_scri> bwm: pats has fair characterisation of the point at the f2f in bristol

15:25:02 <jang_scri> as well as the direct answer to the questoin we put...

15:25:13 <jang_scri> we got interesting feedback, "make it syntactic"

15:25:38 <jang_scri> correct me if I'm wrong, but pats wants an unambiguous node in the graph that denotes a singel tidy value

15:25:43 <jang_scri> second part: that should be a URI

15:25:53 <jang_scri> anyone who disagrees with the first part?

15:26:10 <jang_scri> path: I don't disagree, but if that's the only way that DTing can be indicated, that's a strong committment

15:26:19 <jang_scri> sergei: in proposal point 3 talks about extensions

15:26:37 <jang_scri> bwm: what I'm trying to see if people have agreement with what patrick says

15:26:53 <jang_scri> on part one, is that a step forward?

15:27:07 <jang_scri> path: I'm all for that provided there's a way to indicate the form without indicating value

15:28:34 <jang_scri> I want to allow for long-range DTing

15:28:41 <jang_scri> perhaps in some future version of rdf

15:29:20 <jang_scri> bwm: one of the things I heard from feedback was, no let's not do that

15:29:29 <jang_scri> I heard, let's do long-range dting as a syntax mechanism

15:29:41 <jang_scri> the abstract syntax doesn't do that; you bind to a particular dt

15:29:54 <jang_scri> path: if thet's the case I'm against it

15:29:59 <jang_scri> bwm: why then are you against that?

15:30:17 <jang_scri> path: because it seems to me there's an overwhelming use case for ranged datatyping

15:30:42 <jang_scri> you mean, it's in the XML but parsing gives tyou local typing?

15:30:45 <jang_scri> then no

15:30:54 <jang_scri> you might get RDF data when you don't know about the typing

15:30:57 <jang_scri> #and get the typing later

15:31:10 <jang_scri> pats: we've 39 schemas defining our ontology

15:31:32 <jang_scri> I have many schemas defining my ontology separate from my instance data

15:31:59 <jang_scri> path: I can't see a positive case for this taht's very strong

15:32:08 <jang_scri> I can see the case for compactifying the representation

15:32:29 <jang_scri> nevertheless, the interchange syntax would be more old-fashioned

15:32:36 <jang_scri> so I'm not persuaded by the efficiency argument

15:32:44 <jang_scri> bwm: this wasn't an efficiency argument

15:32:53 <jang_scri> we want this global implicit idiom is that people write

15:33:02 <jang_scri> <jenny><age>10</age></jenny>

15:33:14 <jang_scri> that seems to me (bwm) a SYNTACTIC issue!

15:33:28 <jang_scri> path: I'd like to hear why bwm thinks that.

15:33:46 <jang_scri> pats: there are two decisions to be made:

15:33:55 <jang_scri> 1. should we proceed with this as local idiom

15:34:12 <jang_scri> and carry on with decisions as global plus tidyness

15:34:21 <jang_scri> path: I'd be interested in feedback from gk

15:34:30 <jang_scri> also impact on dublin core

15:34:37 <bwm> I have to go - sorry folks

15:35:01 <jang_scri> pats: does this proposal say ALL literals have to be typed?

15:35:22 <jang_scri> [folks pack up to go here at ILRT]

15:35:53 <jang_scri> eric welcomes bar talk

15:36:00 <jang_scri> I'll suggest the following

15:36:15 <jang_scri> several of the implementors have said this proposal is useful from a local viewpoint

15:36:29 <jang_scri> I'd like to continue flushing that out after hours if you're willing sergei

15:36:37 <jang_scri> patrick has good point wrt the global aspect

15:36:50 <jang_scri> which needs to be addressed - suggest we move to the list on this

15:36:54 <jang_scri> meeting adjourned.

15:37:25 <jang_scri> pats: quickly: justify why a URL can't be used.

15:37:40 <jang_scri> eric: no, not at that meeting. send that via email.

15:37:48 <jang_scri> scribe leaves.

15:37:51 <Zakim> -Ilrt

15:38:15 <Zakim> -EricM

15:38:23 <Zakim> -Sergey.

15:40:38 <Zakim> -JosD

15:48:42 <Zakim> -Pat_Hayes

15:48:47 <Zakim> -FrankM

15:48:47 <Zakim> -PatrickS

15:48:48 <Zakim> SW_RDFCore()10:00AM has ended