Semantic Web Interest Group IRC Chat Logs for 2003-10-01

01:21:55 <DanC> goodness... this info: thing is on /.

01:22:27 <GabeW> why is this good?

01:22:37 <GabeW> oh wait, you are "being exasperated".. I get it

01:25:20 <DanC> whew... /. crowd seems to get it...

01:25:20 * sandro imagines trying to argue info:'s demerits in a style that would be effective on /. Oh boy.

01:25:29 <sandro> Really? Wow.

01:25:36 <GabeW> DanC: that wasn't my impression

01:25:47 <DanC> [[ Still need DNS equivalent... ]]

01:26:37 <GabeW> we've had a thread on the info URI scheme on the XRI TC list.. and I asked basically "why not just have separate URI schemes for each of those use cases" (ie isbn, etc)

01:26:51 <DanC> [[ How come... info:ddc/22/eng//004.678

01:26:52 <DanC> is better than

01:26:52 <DanC> http://www.ddc.com/22/eng/004.678 ]]

01:26:52 <dc_rdfig> A: http://www.ddc.com/22/eng/004.678 from DanC

01:27:00 <DanC> A:|never mind

01:27:00 <dc_rdfig> Titled item A.

01:27:04 <GabeW> hehe

01:28:06 <DanC> unless a URI scheme is used in a network protocol somehow (even implicitly, ala mid:) it's hard to see how it's valuable. i.e. how it's grounded.

01:28:13 <GabeW> interesting

01:28:27 <GabeW> so, isbn: wouldn't be useful?

01:28:36 <DanC> doubt it.

01:28:40 <GabeW> hmm

01:29:00 <DanC> let's put it this way: if it were useful, wouldn't it be in use by now?

01:29:28 <GabeW> well, i think a lot of people find the uri scheme process difficult or at least intimidating

01:29:33 <GabeW> uri registration process that is

01:29:48 <sandro> Nah, that's not it.

01:29:49 <DanC> it's not like it's a new idea. http://lists.w3.org/Archives/Public/www-talk/1991NovDec/0008.html

01:29:50 * MarkB thinks "thank goodness for that" 8-)

01:29:57 <GabeW> heh

01:30:21 <DanC> yes, well, almost nobody bothers to register their URI schemes. but that doesn't stop them from being used.

01:30:36 <GabeW> right

01:30:49 <sandro> So isbn: would be used if it were useful. yeah.

01:31:17 <GabeW> well, certainly isbn's are useful -- the question is whether its useful as a URI scheme

01:31:22 <sandro> Counter argument: phone: it's defined, it seems pretty useful, but it doesn't seem widely used.

01:32:12 <sandro> DanC, do you remember what I was going to run surnia on to see if it was useful?

01:32:16 <DanC> you mean tel: ... indeed, not widely used... there seems to be economic motivation for making phone reference go thru a specific provider, rather than just straight to the phone.

01:32:47 <DanC> umm... we considered my scenario of evaluating travel itineraries...

01:32:47 <sandro> Sorry -- how else do people do tel stuff?

01:32:47 <GabeW> just to suss out the thinking here - is the thinking that URIs should *always* be resolvable and any non-resolvable URI is basically useless?

01:33:12 <DanC> on my desktop, a tel: URI causes DTMF tones to come out of my speakers.

01:33:24 <DanC> then I hold up the phone to the speakers, et voila

01:33:50 <sandro> Yes, GabeW, AND unless the resovable scheme is way way better than http, just use http. (only options that come to mind are https and freenet)

01:33:51 * MarkB wonders if that's "safe" 8-)

01:34:07 <DanC> URIs don't always need to be resolvable in the "trade a symbol for a document interactively" sense.

01:34:20 <DanC> I figured that plaing DMTF tones is safe.

01:34:26 <GabeW> dan, just to clarify, you just said "unless a URI scheme is used in a network protocol somehow (even

01:34:29 <GabeW> implicitly, ala mid:) it's hard to see how it's valuable. i.e.

01:34:32 <GabeW> how it's grounded."

01:34:36 <DanC> it's the holding the phone up to the speaker that's the authorization to place a call.

01:35:07 <DanC> I had a modem dialer thingy... when that was set up, I redirected tel:XYZ to http://localhost/dialer-deely/about?XYZ

01:35:11 <JibberJim> That's a great authorisation system, but how to do you ensure that the path to the speakers is secure?

01:35:29 <DanC> er... the speakers are inside the trusted computing base

01:35:32 <GabeW> hehe

01:35:39 <GabeW> thats the funniest thing I've heard all day

01:35:40 <MarkB> yah, I remember you talking about that ... just trying to be funny. 8-O

01:36:15 <D[a]vey> grrr, theres NOTHING more annoying that one headphone going :(

01:38:38 <DanC> there are other uses of URIs in network protocos than "trade a symbol for a document". e.g. irc://irc.freenode.net/rdfig refers to this channel, but you don't GET a channel. you /join it or send to it

01:39:08 <DanC> (hmm... you could GET it... its state might be the list of folks in the channel and the last 10 messages accross it or something.)

01:39:47 <MarkB> if it's got a URI, there's always a possible response for a GET

01:40:10 <DanC> a 200 response? I'm not sure about that.

01:41:05 <DanC> not without making up the impedence mismatch with HTTP somehow, ala the "users in the channel and last 10 messages" convention

01:41:11 <GabeW> per my reading of 2616, the HTTP protocol works with any URI scheme...

01:41:52 <DanC> yes, the HTTP protocol syntax allows any URI to go there; that doesn't mean that the internet community agrees that it makes sense

01:41:59 <DanC> ... to GET an IRC channel.

01:42:12 <MarkB> It surprises me to hear you say that Dan. The "Identity, State, and GET" mantra was a big help to me early on in my Web-education.

01:42:33 <GabeW> well, the internet community agrees on very little, given my experience watching this and other fora ;-)

01:42:44 <DanC> er.. that "identity, state, and GET" essay was pretty much all about HTTP.

01:43:07 <MarkB> Right... but like Gabe just said, HTTP takes any URI

01:43:28 <DanC> HTTP syntax allows for any URI...

01:43:40 <Morbus> eh?

01:43:42 <Morbus> oh.

01:43:49 <GabeW> GET irc://irc.freenode.net/rdfig HTTP/1.1

01:43:58 <MarkB> yup

01:44:57 <DanC> I can set up my proxy so that when you ask it for http://www.ietf.org/ it returns the contents of /etc/motd from the local disk. That doesn't violate the syntactic constraints of the HTTP protocol, but it breaks the Web Architecture expectations about who's licensed to say what a representation of http://www.ietf.org/ is.

01:45:50 <MarkB> If I use your proxy, I'm trusting you. I'm asking you to give me a representation of that URI.

01:46:04 <GabeW> what about non-http URIs - whats the expectation? (thats not a rhetorical question, I'm genuinely interested)

01:47:17 <DanC> Any proxy for The Web (as opposed to: a disconnected web) should probably return "4xx hellifino" in reply to GET irc://irc.freenode.net/rdfig HTTP/1.1

01:49:06 <DanC> now if you hook up a web proxy server via IRC protocol to this channel, maybe you'd accept a 200 response as sensible. But I don't think you can compel anybody else to accept it as sensible, the way you can if you show me the trace of your HTTP interaction with port 80 of www.ietf.org

01:50:51 <GabeW> if i write a spec called "hirc" which says to use HTTP to interact with a server using HTTP (lets say the server is specified by a host name just like HTTP URIs), is this broken?

01:51:22 <GabeW> eg hirc://irc.example.com/channel

01:51:29 * DanC wonders if there's a typo near " to use HTTP to interact with a server using HTTP"

01:52:06 <GabeW> hehe

01:52:09 <GabeW> yah, typo

01:52:14 <GabeW> sorry

01:52:47 <GabeW> ...says to use HTTP to interact with a server speaking HTTP and knows of the hirc uri scheme ...

01:53:39 <DanC> I think if you start over and slow down, we'll see that this is indeed broken.

01:54:22 <GabeW> ok

01:54:33 <DanC> i.e. if I have hirc://irc.example.com/channel , do I connect to port 80 of irc.example.com? if so, then it's broken cuz it should be written http://irc.example.com/ . aliases are evil.

01:54:54 <GabeW> ok, just trying to figure out where you assert its broken

01:54:55 <DanC> if I'm supposed to connect using IRC protocol, then it should be written irc://irc.example.com/channel

01:55:24 <GabeW> lets say it doesn't do the straight DNS a record lookup and does SRV lookup

01:55:50 <DanC> I think it's fine to use SRV with http URIs.

01:56:13 <DanC> the specs don't cover that yet, but (a) they should and (b) they don't say you can't do that.

01:56:17 <GabeW> but the client wouldn't know to use SRV if it was just a plain HTTP URI.. hmm

01:56:52 <DanC> ok, there's a little chicken-and-egg problem with clients starting to use SRV lookups on http...

01:57:19 <DanC> ... that might merit a new URI scheme. But that feels lame. Kinda like https

01:57:39 <GabeW> heh, ok, now we are getting somewhere

01:58:32 * DanC tries to remember how MX records got deployed...

01:58:44 <GabeW> patches to sendmail?

02:00:00 <DanC> there are vestiges of pre-MX in MTAs today. i.e. they'll look for A records if MX records aren't there. I guess MTAs can afford to wait around for a DNS lookup failure... hmm... that's not a 2 minute TCP timeout... HTTP clients could do that too.

02:00:14 <GabeW> heh

02:00:53 <DanC> so it would take 5 to 10 years to deploy, but yeah, SRV with existing http URIs makes more sense than a new scheme.

02:01:09 * DanC wanders off for domestic obligations, hoping to return in 20min or so

02:01:12 <GabeW> ok

02:02:46 <GabeW> MarkB: does that line up with your thinking?

02:07:16 <MarkB> which part?

02:08:02 <GabeW> well, let me see.. would you agree that if something uses HTTP as the communication protocol, it should use HTTP as the URI scheme?

02:08:22 <GabeW> as an absolute rule, that is

02:09:11 <MarkB> hmm.. it seems a no-brainer, but I can't think of a reason why I'd want to make it an absolute rule

02:09:49 <MarkB> if HTTP were used just to Upgrade to another protocol, does that count as "uses HTTP"?

02:10:29 <GabeW> hmm. hadn't thought of that

02:10:41 <GabeW> i'd say it woudl count, yes

02:10:42 <GabeW> would

02:11:01 <mmealling> the internet printing protocol uses http but doesn't use the 'http:' scheme.... the scheme denotes a particular set of functions and semantics that 'http' by itself does not....

02:11:36 <MarkB> I wouldn't say IPP "uses HTTP". It tunnels over it.

02:11:47 <MarkB> i.e. treats it as if it were TCP

02:11:52 <mmealling> the URI scheme really doesn't have an extremely tightly bound relationship with the protocol used to access it.....

02:12:22 <MarkB> really? I can point to a lot of software that disagrees with you 8-)

02:13:04 <GabeW> i was just going to bring up DDDS

02:13:20 <mmealling> oh? so when something fetches an 'http:' from its local cache its using http via a local loobpack interface to access it? And when an http proxy is used to handle an 'ftp:' request what's that?

02:13:50 <MarkB> oh, sure, but I thought we were talking about the other direction.

02:14:16 <mmealling> so if we move to httpng one day, does that mean all of those old http URIs are broken?

02:15:08 <MarkB> no, because you'd use HTTP Upgrade

02:17:21 <DanC> not necessarily. smart clients could skip the whole port 80 dance and go straight to the HTTP-NG port once sufficiently many servers are deployed to make it a good bet.

02:17:21 <mmealling> ok, let's take this example. the CNRP protocol uses HTTP as one of its available transports. does that mean I have to encode my CNRP URI which is of hte form 'go:keyword' as an HTTP URI simply because it happens to use HTTP as a transport?

02:17:57 <DanC> no, but CNRP is broken for other reasons

02:18:15 <mmealling> your in a minority on that one Dan....

02:18:30 <DanC> minority among who?

02:19:04 <mmealling> among people who know what it is and the problem its trying to solve....

02:19:08 <DanC> we went over this and established that CNRP URIs don't have a web-wide meaning.

02:19:21 <mmealling> sure.... never intended too....

02:19:23 <MarkB> right DanC - Upgrade would be for transition

02:19:49 <DanC> yes, and URIs, by definition, have a web-wide meaning. ergo CNRP is broken, QED.

02:19:56 <mmealling> they have the exact same local context requirement that news: does....

02:20:33 <DanC> news: is a bit fractal, but there are lots of news URIs with web-wide meaning, e.g. news:news.groups

02:20:35 <mmealling> hmmmm... in that case so is 'file', 'news', 'dav', and a whole slew of others that people find useful....

02:21:21 <DanC> yes, file is broken. this is widely acknowledged.

02:22:15 <DanC> dav: is a wart, but since there's only one dav: URI, it's Mostly Harmless.

02:22:40 <mmealling> besides, you would never be the intended user of anything like CNRP... you like to point and click and fiddle with the guts of URIs to much.... you're _not_ a typical Internet user.....

02:23:15 <mmealling> this is for the people who like AOL's duplo-block Internet. The ones that thing that the Address bar and Yahoo's search field are the same thing.....

02:23:21 <DanC> I act like a typical internet user about 80% of the time, I think.

02:23:42 <mmealling> hehe.... sit down with my grandmother some time... ;-)

02:24:32 <DanC> give me the benefit of the doubt, OK? I deal with church admin staff daily. These folks are not protocol designers.

02:25:38 <DanC> if CNRP is for proprietary networks like AOL, what's it doing in the standards track?

02:25:44 * DanC feels deja vu coming over me

02:26:27 <DanC> I haven't tried looking at CNRP ala file. I guess I could mull that over.

02:26:49 <DanC> right now it seems like "what you do behind your firewall is your business; don't bother the open standards community, please"

02:28:39 <GabeW> ok, well, its been interesting watching this back and forth, I need to run ... but I feel like I only got halfway through this.. oh well.. another day

02:28:57 <GabeW> thanks for your time

03:10:00 * DanC hunts for that tidbit from sandro where he said my theory of naming was in

03:10:00 <DanC> the literature somewhere, under "causal naming" or some such...

03:10:06 <DanC> <sandroYeah, "Causal Theory of Naming", rooted in J.S.Mill and Kripke. Nice entry in Cambridge Dictionary of Philisophy

03:10:40 * DanC googles...

03:10:44 <DanC> ah... dead trees.

03:16:44 <DanC> BLURB: Causal Theory of Naming

03:16:44 <dc_rdfig> B: Causal Theory of Naming from DanC

03:18:04 <DanC> B:following up on a comment by sandro that my position was ala '*Causal Theory of Naming*, rooted in J.S.Mill and Kripke. Nice entry in Cambridge Dictionary of Philisophy'

03:18:04 <dc_rdfig> Added comment B1.

03:19:00 <DanC> B:many google searches lead to this [http://www.friesian.com/naming.htm|Meaning and Naming] essay/review in the fresian stuff

03:19:01 <dc_rdfig> Added comment B2.

03:20:33 <DanC> B:and to the book [http://www.amazon.com/exec/obidos/tg/detail/-/0674598466/danconnollyA/|Naming and Necessity] by Kripke

03:20:33 <dc_rdfig> Added comment B3.

03:23:00 <DanC> B:aha... [http://www.wikipedia.org/wiki/Saul_Kripke|Saul Kripke] wikipedia article helps me find [http://www.wikipedia.org/wiki/Causal_theory_of_names|Causal theory of names]

03:23:01 <dc_rdfig> Added comment B4.

03:36:18 <DanC> hmm... tasty-looking: Self-referentiality and Godel sentences http://www.cs.nyu.edu/pipermail/fom/2003-September/007252.html

03:39:57 <sandro> mmm.... tasty-looking: MIT AI Courseware (alas PDF, but so be it) server is slashdotted though; very slow.....

03:40:51 * DanC returns to "The Unknowable" http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable/ , WikiMarks it, wonders if sandro has read it

03:41:19 <sandro> still not, sadly. (I rely on your having read it. :-)

03:42:04 <DanC> I've always considered goedel numbering awkward; it's clear that (cons a b) is more straightforward than 2^a*3^b. This book takes that idea seriously and makes the incompleteness theorem easier to grok, I think.

03:43:01 <sandro> There was an old debate between Hofstader and Minsky about that, I think.

03:43:39 * sandro may be remembering wrong. the question was whether goedel should have invented LISP or did invent LISP.

03:44:26 <DanC> the "precise descriptoin of ACL2 Logic" paper talks about induction over s-expressions, which is sorta in the same direction, but doesn't to into reflection/self-reference

03:45:22 <DanC> btw, Alloy looks cool. if I weren't so invested (mentally) in larch, and if alloy were a little less intimidating (java foo) to install, I'd be playing with it now.

03:46:09 <sandro> Okay, the OCW servers are not overloaded, the files are just HUGE. 12Meg for 1 week's notes.

03:46:15 <DanC> Alloy finds counterexamples and draws pictures when you make mistakes.

03:47:04 <DanC> I found a paper about using XSLT to convert DAML to Alloy and check the results.

03:47:22 <DanC> made me think about using it to check the consistency of the food & wine ontologies from the OWL guide.

03:47:47 <DanC> of course, it's only complete up to bounded problem sizes.

03:50:41 <sandro> reference?

03:51:03 <DanC> alloy notes: http://rdfig.xmlhack.com/2003/09/29/2003-09-29.html#1064869282.269428

03:51:15 <DanC> "DanC: ooh... alloy case studies includes one where "We used Alloy to analyze DAML+OIL ontologies.""

03:55:10 <DanC> so I'm all jumbled up with sw-meaning and webarch and UML and artemov...

03:55:24 <DanC> let me try to unravel it...

03:55:47 <DanC> I've long been interested in the idea of formally modelling the stuff in the webarch document...

03:56:08 <DanC> timbl often expresses a frustration with the document that might be satisfied by an RDF/RDFS/OWL model of the terms...

03:56:30 <DanC> and Dave O. recently threw in a UML model of some of the terms...

03:56:54 <DanC> So I bit on this, having played with UML to OWL via XSLT...

03:56:55 <sandro> (I'm not quite remembering the name Artemov)

03:57:09 <DanC> (we'll get to Artemove presently...)

03:57:14 <sandro> (okay)

03:57:53 <DanC> so we take our handy webarch doc, and we draw the uri/resource/representation diagram in dia, and we're kinda happy.

03:58:32 <DanC> we're confident it'll go thru the XSLT gizmo and come out { :identifies a owl:FunctionalProperty; s:domain :URI; s:range :Resource} and such.

03:58:35 * sandro looks skeptical that an informative diagram would make all parties happy

03:58:58 <sandro> ... but okay

03:59:17 <DanC> now we skip to the term index of webarch, and the first one is URI ambiguity.

03:59:33 <DanC> that little {...} blurb denies the possibility of URI ambiguity.

03:59:52 <sandro> right

04:00:13 <DanC> what's URI ambiguity? HUSH! we don't speak of such things!

04:00:36 <DanC> so that's clearly a limited view of the world...

04:01:06 <DanC> e.g. it's not a view in which you can make an argument about the cost of ambiguity and such.

04:01:06 <sandro> yeah. it's just one ontology, and perhaps a fairly naive one at that.

04:02:19 <DanC> and we skim down the webarch term index and we run into things like "safe interaction", which is defined in terms of agents and obligations... and we remember from Extreme Markup that "deontic logic" is a modal logic for talking about permissions, obligations, and such...

04:02:59 * sandro nods, yep.

04:03:30 <DanC> ... which reminds us, well, me anyway, of a comment Pat Hayes made in a discussion of the excluded middle about a modal "proveable" operator that keeps things from going higher order or something...

04:03:40 <DanC> now at this point, everything goes fuzzy...

04:04:05 <DanC> i.e. the actual relevance of the next step to webarch is tenuous at best...

04:04:11 <sandro> I hadn't thought about "proveable" being modal, but that makes sense.

04:04:39 <sandro> yes indeed

04:04:46 <DanC> but I ask Pat H. about this proveable operator (http://lists.w3.org/Archives/Public/www-archive/2003Sep/0063.html)

04:05:09 <DanC> and he comes back (off list, but probably not secret on purpose) with some nifty pointers to Artemov's work

04:05:42 <sandro> (right, now I remember you mentioning him)

04:05:59 <sandro> (we decided he worked at the same school as Kripke)

04:06:17 <DanC> which brings us to 23Sep notes on Artemov's "Explicit Provability" stuff. http://rdfig.xmlhack.com/2003/09/23/2003-09-23.html#1064349895.329315

04:06:45 <DanC> "explicit provability shows the way of circumventing the restrictions imposed on formal systems by the Goedel incompleteness theorem. In particular, explicit provability provides a tool of increasing the efficiency of a formal system by verified rules without explosion of the metamathematical level of the system."

04:07:47 <DanC> which is a horkload of gobbledygook, but it reminds me of N3's wierd way of smushing implication rules and axiom schemas into one level.

04:08:18 * sandro starts to look *almost* like he gets it.

04:08:37 <DanC> lemme see if I can elaborate a bit...

04:09:25 <DanC> a semantic web proof theory might start with just a handful of axioms and inference rules...

04:09:51 <DanC> ... and we might observe, at a sort of meta-level, that larger inference steps are valid.

04:10:21 <DanC> i.e. they can always be spelled out in primitive terms.

04:10:36 <DanC> but that's boring and tedious, perhaps exponentially so.

04:10:36 <sandro> lemmas, sure.

04:11:16 * DanC wonders if these are lemmas

04:12:06 <sandro> If I handwave a little about logic vs meta-logic, they sure look like it.

04:12:09 <DanC> anyway, I hope it's clear now why the claim about "increasing the efficiency of a formal system by verified rules without explosion of the metamathematical level of the system." is very interesting.

04:12:51 <sandro> it's somewhere between obvious and wrong, maybe at the "very interesting" spot in the middle, but it's hard for me to tell. :-)

04:13:20 <DanC> and I start skimming the .pdf and .ps papers written by Artemov, and while the level of arrogance is pretty astounding, the technical stuff is written at a level that I can *just about* grok.

04:13:30 <sandro> uh huh

04:14:07 <DanC> so I break out my reading assistant, larch, and make it as far as v1.4 of http://www.w3.org/XML/9711theory/LogicOfProofs.lsl

04:14:49 <DanC> i.e. I made it as far as the statement of the deduction theorem on page something-or-other of one of the Artemov papers.

04:14:55 <DanC> and that's sorta where I am.

04:15:08 <DanC> choices of stuff to persue:

04:15:23 <DanC> (a) more UML diagrams of webarch with RDF/OWL translations

04:15:47 <DanC> (b) study N3 level-breaking in terms of explicit provability

04:16:04 <DanC> (c) economics, information theory, and naming

04:16:34 <sandro> oh boy. ask me the easy questions.

04:16:35 <DanC> (d) logics of knowledge for sw-meaning

04:17:28 <DanC> (e) porting my larch stuff to Alloy, perhaps using Alloy ala otter in WebOt

04:17:31 <DanC> WebOnt

04:17:47 <DanC> (f) going back and looking at otter axioms for OWL again

04:18:26 <sandro> Our horizons are dramatically reversed right now. I'm used to *you* being mostly interested in code that will work before the end of the day.....

04:19:25 <DanC> persuing the artemov stuff looks fun in a way: I was able to use my FormalSystem.lsl trait directly in the LogicOfProofs.lsl thingy, and the next bit of the Artemov paper pulls in primitive recursion, which I modelled in N3 a while ago.

04:19:42 <DanC> but ... yeah... horizons... it's not clear what the point of all this is.

04:21:08 <DanC> anyway, if the questions make any sense, then I've mostly met my goal for the last 10 or 20 minutes.

04:21:09 <sandro> Well, there is some good stuff over there.... and it's good to get some reseach/blue-sky time in once in a while.....

04:21:34 <sandro> Oh yeah, they make sense and I appreciate your dilemma.

04:22:11 <sandro> I don't see as much synergy between your options as I would have expected.....

04:22:43 <sandro> What would make it easiest for you to work on OWL Axioms?

04:23:36 <DanC> dunno... there are so many other people passing the OWL tests that I'm not very motivated to cover that ground.

04:24:00 <DanC> that ball feels like it's rolling downhill. hence boring ;-)

04:24:05 <sandro> As in, I think my current ones in Surnia are good but not great. They need more metadata (each rule having a name) and.... I'm not sure what else... to be better understood.

04:24:09 <sandro> Ah.

04:24:12 <sandro> Yeah.

04:24:30 <sandro> The version of that ball I see, which isn't rolling the same way looks like this:

04:25:33 <DanC> (each rule having a name... Alloy supports that.)

04:26:15 <sandro> surnia --reprefix http://www.w3.org/2002/07/owl ./owlAx http://example.org/input.rdf

04:26:22 * DanC wonders if Alloy could be applied to telcon-tiddlywinks

04:27:31 <sandro> and it starts to look for inconsistencies, pulling in stuff (axioms, facts) from the web, and doing FOL proving stuff at the same time, until you hit ctl-C or it finds a contradiction.

04:27:41 <DanC> hmm.

04:28:10 <sandro> ie W3C Semantic Validator

04:28:30 <DanC> ah.

04:29:21 <DanC> I was going to say that consistency checking is sorta uninteresting, but so is SGML validation in that way, but the HTML validation service helps spread understanding real fast.

04:29:45 <sandro> My biggest worry here is that my architecture isn't very good at the OWL test suite. I mean, it's good, but those problems are hard, ... and I don't really know how to patch in something more DLish. But maybe I could figure that out without bending too much.

04:30:21 <sandro> Right. "spread understanding real fast"

04:31:01 <DanC> now keep in mind that general purpose theorem provers for the web aren't expected to emerge. What we expect to have is special purpose provers that can emit proofs.

04:31:05 <DanC> checkable proofs.

04:31:08 <sandro> SemWalker aims to do that too, from the query side of inference -- letting you see the RDF data AND some entailments of the data, marked as such.

04:32:05 <DanC> e.g. a teclon-tiddlywinks gizmo will find you a telcon time and a proof that it's a suitable time (w.r.t. some policies)

04:32:19 <sandro> Yeah, but that difference doesn't matter at this "spread understanding" level, where people are just getting a feel for what inference means. Once they start to want to push it, then they'll go Ohhhh, it's not that simple.

04:33:05 <DanC> the semantic validator seems smack dab in the middle of sw-meaning

04:33:46 <sandro> You once tried to convince me (and succeeded) that people don't want to tell the machine all they know about scheduling.

04:34:03 <DanC> (and the "how many model theories/media types?" from earlier today here in #rdfig)

04:34:16 <sandro> From where I sit, everything looks like sw-meaning, so I think maybe I'm smack dab in the middle of it. :-)

04:34:35 <DanC> yeah, a real telcon-tiddliwinks gizmo will have to have license to look at all sorts of semi-private stuff.

04:35:10 <DanC> and it'll have to be really good in order to get people to formalize their knowledge at all.

04:35:52 <sandro> It's been my 1st and 2nd hand experience that people aren't willing to delegate much to the machine: people don't seem to tell e-bay their real maximum bid, even though in theory they should.

04:36:18 <DanC> it takes a long time...

04:37:11 <DanC> ... but when you can really rely on your palm-pilot to beep at you, it frees you up so you don't need to check the clock all the time, and motivates you to really put your appointments in there

04:37:34 <DanC> back to sw-meaning...

04:37:42 <sandro> and the right kind of reward structure. people don't always want to admit in writting what they are feeling. They wont SAY "I can't meet after 4pm because I'm too tired".... (Some people are more willing to share than others.)

04:37:44 <DanC> the Alloy papers talk about thinkers and tinkers...

04:38:10 <sandro> yeah, re palm.

04:38:30 <DanC> I wonder whether to play thinker, and model agent logics or economics or some such and justify closure=pt ...

04:38:47 <DanC> ... or just play tinker and say "see? it comes to intuitivly-correct conclusions"

04:39:55 <sandro> I think something that people can twiddle with their grubby little mouse pointers will do the most good. (thus my coding furiously)

04:40:48 <DanC> hmm... if we were talking about a large audience, I'd agree...

04:40:57 <sandro> But I don't fully understand what you're trying to do, of course.

04:41:04 <DanC> ... but no amount of emperical evidence is going to convince PatH nor PeterPS

04:41:07 <sandro> Yeah, maybe I'm just speaking for MYSELF when I say that.

04:41:52 <DanC> emperical stuff is real handy for stimulating the brain, meanwhile

04:41:53 <sandro> If I'm (virtually speaking) holding it in my hands, I think I can be more coherent to the logicians -- I can answer every question of theirs empirically.

04:42:19 <sandro> (jynx on "emperical")

04:43:06 * DanC wonders if the next sw-meaning is still off the horizon or if it has already snuck up on me

04:43:13 <DanC> next telcon

04:43:23 <DanC> 10Oct, right? more than a week away.

04:43:45 <sandro> Yeah, and I don't feel like anyone but Bijan has a lot of prep to do for it. Maybe I'm wrong.

04:43:54 <sandro> The one after that is like Oct 30.

04:44:09 <DanC> anyway, I have just one appointment tomorrow, and not too much to do by way of preparation for Thursday's WebOnt telcon.

04:44:45 <DanC> so if you have something to play with, I'm likely to have bandwidth.

04:45:46 * sandro contemplates demoing SemWalker to illustrate an sw-meaning issue. But then you remind him of surnia/axiom stuff. Hm. It's 63% overlap, but still different.

04:47:01 <DanC> generel purpose RDF browsing still seems infeasible to me, so I don't have much of a feel for what SemWalker is about.

04:47:24 <DanC> general purpose

04:48:21 <sandro> Circles and Arrows diagrams are general-purpose RDF browsing, right? A little stlying, perhaps....

04:49:10 <DanC> no, to get a useful circles-and-arrows diagram, you have to write a stylesheet for certain idioms.

04:49:42 <sandro> semwalker occured to me when I couldn't fit your [expletive] swad chart onto my screen, and realized all I really needed to see was one node and the arcs in and out of it.

04:49:44 <DanC> the pictures made by the RDF validator are OK for debugging.

04:49:59 <sandro> debugging is good. debugging is very good. :-)

04:50:11 <DanC> is semwalker a debugging style thing?

04:50:41 <sbp`> sbp` is now known as sbp

04:51:08 * DanC wonders if that's a sign of sean-the-person interacting with his IRC software

04:51:37 <sbp> yep. hey DanC, sandro

04:52:18 * DanC is reminded of RDF-in-XHTML issues, esp. the recent RDDL draft and JonB's XSLT/RDF questions related to it...

04:52:25 <sbp> (xchat, which I've just adding utf-8 munging for)

04:52:41 <sbp> hmm. I don't think I've seen that yet

04:52:55 * DanC laments lack of drag-n-drop from email folders to IRC channels...

04:53:07 <sandro> I'm not sure. I see 3-4 potential uses. (1) debugging style, see your data another way to make sure the machine got it; (2) generic web forms, fill in the blanks, gets annoying with disorganized blanks; (3) adding metadata & navigation framing to "web pages" which are often generated from still more data via a class-based style-transform.

04:53:10 <DanC> X-Archived-At: http://www.w3.org/mid/3F6899F9.8030906@openhealth.org

04:53:27 <sbp> heh, third result for RDDL: http://lists.w3.org/Archives/Public/www-archive/2003Aug/0011

04:53:29 <sandro> hey, Sean. :)

04:53:30 <sbp> thanks

04:54:07 <sandro> (4) just being able to click a lot. Clicking is good.

04:55:44 <DanC> have you played with other "clicking is good" stuff nearby? e.g. RDFAuthor, isaviz, etc.?

04:56:18 <DanC> the connection between forms and RDF is something that I hope to persue Someday

04:56:57 * DanC wishes JonB's example were a little less abstract

04:57:50 <sbp> he seems to be thinking about XSLT in a browser, rather than some specific app that can take a URI-ref and won't strip the # off of the end

04:58:18 <sandro> isaviz and RDFAuthor are closed world, as far as I can tell.

04:58:33 <sandro> which is like going for a hike in your living room. not the same thing.

05:00:04 * sbp wonders how to discern between different dialects of XHTML--namespace on the root element is always that of XHTML's... don't like reaching into the DTD from XSLT etc. (is it even possible?)

05:00:43 * sandro deletes a 21megabyte logfile from named, allowing his mail to flow again.

05:01:28 <DanC> I expect to use the profile attribute on the head element to discern dialects

05:01:55 <sandro> I think I'm done. 'night folks.

05:01:58 <sbp> and there was some talk about a profile facet for the application/xhtml+xml MIME type

05:01:59 <DanC> ciao.

05:02:01 <sbp> 'night sandro

05:02:30 <sbp> might be useful if RDDL has a head/@profile, then

05:03:19 <DanC> yes, for all the planets to line up, RDDL needs a head/@profile

05:03:32 <DanC> I'm trying not to ask for too much stuff at once though ;-)

05:04:27 <sbp> it's more than a syzygy: I think it'll be rather useful when you get down to nitty-gritty coding with your XSLT rel hack

05:04:44 <sbp> (data-view, no?)

05:04:47 <DanC> it took... hm... a year? to get the TAG to agree that the RDDL spec should include this RDF projection

05:05:19 <DanC> .google syzygy

05:05:20 <datum> syzygy: http://www.syzygy.net/

05:05:36 <DanC> help?

05:05:40 <sbp> I liked TimBL's three alternatives for RDDL-in-RDF. shows how to model things more naturally in RDF...

05:05:44 <sbp> .define syzygy

05:05:46 <datum> syzygy is defined as:-

05:05:47 <datum> 1. the straight line configuration of 3 celestial bodies (as the sun and earth and moon) in a gravitational system

05:06:41 * DanC awards sbp 25 points for use of esoteric vocab in conversation

05:06:49 <sbp> heh, heh. thanks!

05:07:38 <DanC> yes, data-views is one of the planets. issue 8 is another, and RDDL is the 3rd.

05:08:09 <DanC> issue namespaceDocument-8

05:08:28 * DanC begs forgiveness for referring to issue by number alone

05:08:55 <sbp> no matter. ".google tag issues" works wonders

05:09:27 <DanC> .google tag issues

05:09:28 <datum> tag issues: http://www.w3.org/2001/tag/ilist

05:09:33 <DanC> (for the benefit of log readers)

05:10:01 * DanC wonders what, if anything, brought sbp to these parts tonight

05:10:18 <sbp> these parts? as in #rdfig/Freenode?

05:10:22 <DanC> yes.

05:10:38 * sbp contemplates $(GET `google tag issues` | grep -8)

05:10:55 <sbp> I'm usually lurking here; Freenode up in the background just in case someone needs me, or I need someone

05:11:21 <sbp> er, grep \-8 or somesuch, actually...

05:12:04 * DanC wishes for help, e.g. from sbp, on spelling out a/the argument against new URI schemes such as info:

05:12:28 <sbp> hehe. yes, I've been following the info: draft and /.-ing etc.

05:13:34 <sbp> one well placed "Why isn't this a URN?" email to its authors and uri at w3.org might instill enough conversation... not sure how focussed that conversation would be, though. I'm surprised that MikeM etc. hasn't brought that up already

05:13:53 <sbp> I think I agree with you that using http: for these things is best

05:14:02 * DanC reviews http://infomesh.net/2001/09/urischemes/ , cited from "why shouldn't I create a new scheme for XYZ?" in http://esw.w3.org/topic/UriSchemes

05:14:35 <sbp> since they're big social-impact identifiers, whose maintainers should have enough clout to maintain persistent domains in the face of DNS fragility...

05:15:01 * sbp goes back and reviews it too--tends to distrust anything before around 2002-07, arbitrarily

05:15:17 <niq> But RDF *should not* use "http" the way it does!

05:15:21 <sbp> I don't think I made much of a structured argument there

05:15:45 <DanC> the argument I'm after is also an argument against URNs. it has something ala "the way to maintain ownership of a concept in today's world is to answer HTTP GETs about it"

05:15:53 <niq> http:// URLs exist to be dereferenced. Using them otherwise leads to confusion

05:15:56 <sbp> I was mainly arguing that if your scheme's going to rot, why are you making it?

05:16:17 <sbp> niq: permathread ahead!

05:16:40 <sbp> HTTP URIs work alright for me in XML namespaces

05:16:56 <DanC> using them *in conflict* with deferencing leads to confusion. But it's perfectly fine for me to refer you to the W3C homepage, http://www.w3.org/, and for you to know what I'm talking about without spending any IP packets.

05:17:46 * DanC considers it a cost-effective use of IRC to revisit permathreads. kinda like tribal dances.

05:17:58 <sbp> heh

05:18:02 <niq> DanC, until w3 sets up content-negotiation, so http://www.w3.org/ is multi-valued ... and then it gets used as single-valued in Annotea

05:18:29 <DanC> though in the last year or so, my aim has been to capture these permathreads in argument form in the wiki

05:19:06 <sbp> so I've noticed. actually, I've been wanting to congratulate you and all the ESW participants for some time; I was quite taken aback when I first went through it, and I'm rather ashamed to not have contributed more often

05:19:11 <DanC> multi-valued? content negotiation won't make it refer to multiple things. it'll only make that one thing have multiple representations.

05:19:33 <niq> Annotea is fundamentally broken; one reason for that is underlying misuse of "http" in RDF

05:19:48 <DanC> that's a strong claim, niq.

05:19:53 <sbp> Annotea just doesn't have a very good model

05:20:06 <md-bk0800CET> md-bk0800CET is now known as mdupont

05:20:17 <niq> Erm, when Annotea constructs an "XPointer", it only applies to *one* representation

05:20:17 <sbp> we ran up against these same things in EARL, don't forget, and spent a while trying to set something down that would work in RDF

05:20:28 <niq> Indeed

05:20:29 <sbp> which is why you can't serve up XML with HTML

05:20:47 <sbp> nor RDF/XML with HTML, etc.

05:21:03 * sbp hesitates to say anything with anything, but sometimes it feels that way...

05:21:36 * DanC notes ContentNegotiationWorryPile among http://esw.w3.org/topic/WantedPages

05:21:49 <sbp> fragments across MIME types are worrying. I was thinking about encoding the MIME type in the fragment itself for clarity—that'd be interesting

05:22:00 <sbp> hmm

05:22:17 <sbp> I noticed it on Norm's worry list, too, and I have a draft in my notes pile that is asking me to write about the same issue

05:22:26 <sbp> I discussed it with AaronSw about a week ago, too

05:22:43 <DanC> I'm not sure I actally want a ContentNegotiationWorryPile page, though I created that link. I'd prefer not to litter the wiki with "the sky is falling!" stuff.

05:23:10 <sbp> heh. perhaps you need an esw.w3.org/worries/ wiki

05:23:24 <DanC> I'd prefer to stay constructive, even if there are multiple conflicting patterns

05:23:48 <sbp> yeah, I understand. perhaps ContentNegotiationIdeaPile

05:24:18 <sbp> ConnegFixes, ConnegPatternDiscuss, ConnegItAllToHeckAndBack...

05:24:29 <niq> Why is content negotiation a worry? It only becomes a worry when "http" is misused ...

05:25:05 <DanC> ContentNegotationProblems is constructive. it's not constructive to ask a bunch of questions and worry a lot, but it *is* constructive to record actual problems.

05:25:25 <sbp> niq: it seems incompatible with fragment identifiers unless used very conservatively

05:25:39 * DanC awaits justification for niq's claim that http is being misused

05:26:03 <sbp> okay, agreed on CNP

05:26:12 * niq looks for stuff @ lists.w3.org

05:27:24 <sbp> heh, esw:DogWashing? now that I can't wait for...

05:28:15 * sbp decides to help out on wanted #93, SeanPalmer

05:33:11 * niq dredges up http://lists.w3.org/Archives/Public/www-tag/2002Jul/0232.html and puts it to DanC that if there wasn't an HTTP/RDF mismatch, much of what I'm trying to deal with in the references to that would be a non-issue

05:33:34 <niq> [[[

05:33:40 <niq> 2. Annotea makes no provision for content negotiation. So the subject

05:33:40 <niq> of an annotation is ill-specified.

05:33:41 <niq> ]]]

05:34:01 <niq> - what annotea is doing there is inherited straight from RDF

05:35:00 <DanC> I see a bunch of claims in 0232, none of which is justified

05:35:16 <sbp> RDF doesn't define much in the way of applicational semantics, though. the problems that you've outlined appear to be problems with Annotea, not RDF. you say that *Annotea* makes no provision for conneg—what does that have to do with RDF?

05:35:48 <sbp> it's like saying that <b> in XHTML is broken because XML is broken—it shouldn't allow people to make presentational markup

05:35:56 <sbp> you're blaming the meta-language instead of the application

05:36:16 <niq> Because Annotea's problem comes directly from confusing two different - INCOMPATIBLE - uses of "http"

05:36:57 <DanC> you're also not very careful with your quantifiers. Just because some annotea XPointers fail doesn't mean all of them are not well-defined

05:37:15 <sbp> nope. proof: Annotea has the problems, but EARL, hopefully, doesn't. in EARL, we tried to circumvent these problems by modelling HTTP with more granularity. we talk about representations, and XPaths/XPointers into representations, instead of tacked onto the end of URI#s

05:37:20 <DanC> niq, if you just keep repeating your claims without substantiating them, I'm likely to tune out.

05:37:53 <niq> Disagree with that. There's no info in an Annotea XPointer that would tell us whether it was constructed from well-formed XML or not

05:38:06 <DanC> and...?

05:38:19 <DanC> that doesn't mean it can't/won't work.

05:38:37 <DanC> in many cases, it has been constructed from well-formed XML, and it'll work just fine.

05:39:03 <niq> It means that two different Annotea Clients can legitimately resolve the "Xpointers" to different things

05:39:33 <DanC> there's no info in a URI that would tell us whether it'll 404 or not when you GET it. By your argument, URIs are broken. If that's what you mean by broken, I'll take broken any day.

05:39:35 <niq> "in many cases" ... but a tiny minority of all webpages

05:39:53 <DanC> did anybody claim Amaya is applicable to all the drek out there?

05:40:03 <DanC> s/Amaya/annotea/

05:40:12 <Cardinal> I'm a fan of what Annotea wants to accomplish, but I do have to wonder about the usefulness of xpointers in Annotea.

05:40:23 <Cardinal> Since they're both mime type specific and time specific..

05:40:54 <DanC> I wonder about the usefulness of xpointers in Annotea too. So do the folks that built it. That's *why* the built it. so we could evaluate the usefulness based on data, rather than on lack of data.

05:41:13 <sbp> someone did some experiments with canonicalization and hashing (wasn't it you, niq?), which I think is a more stable approach

05:41:16 <DanC> s/the built/they built/

05:41:42 <niq> When we dis this for EARL, we went through a similar loop with Jim's client (MSXML) and my server (OpenSP)

05:42:17 <niq> we needed a couple of iterations to get our pointers to work togehter

05:42:51 <niq> sbp, yes it was me

05:42:54 <sbp> well, they were hacked up proprietary pointer syntaxes...

05:42:59 <niq> and JibberJim

05:43:05 <sbp> ah

05:43:45 <niq> Yes, it was a proposal .. a provisional solution.

05:44:27 <sbp> if a group were chartered to come up with an HTMLPath syntax with maximum XPath compat, that'd be interesting

05:44:39 <niq> btw, sbp up early or late?

05:44:51 <sbp> heh. late. you?

05:44:58 <niq> early:-)

05:45:16 <sbp> at least we've got a bit of overlap

05:45:20 <niq> hehe

05:45:30 * niq gets free online time overnight ...

05:45:40 <sbp> (6:45AM for us, in case anyone's interested)

05:45:42 <sbp> ah, I see

05:46:04 <niq> re: group chartered to deal with HTML Path:

05:46:12 <niq> [[[

05:46:30 <niq> Background:

05:46:30 <niq> 1. In the WAI/ER working group, we needed a robust pointer for referencing

05:46:30 <niq> an element in a document. Using an experimental approach, Jim Ley and

05:46:30 <niq> I

05:46:30 <niq> devised such a pointer, which currently enables his Client S/W to use

05:46:31 <niq> pointers generated by Page Valet, even on tag-soup markup.

05:46:33 <niq> 2. The Annotea project uses what it describes as an XPointer, and which

05:46:35 <niq> is in fact an XPointer into a normalisation of non-XML markup.

05:46:37 <niq> In practice this is very similar to (1).

05:46:39 <niq> 3. The HTML WG has declined to consider defining a "canonical normalisation":

05:46:41 <niq> SP = Steven Pemberton

05:46:43 <niq> NK = Nick Kew

05:46:45 <niq> SP> Therefore the answer to the question "what should an XPointer into

05:46:47 <niq> SP> HTML look like?" is a very loud "it depends".

05:46:49 <niq> NK> Indeed. It depends on defining a canonical normalisation of HTML.

05:46:51 <niq> NK> If we can do that, we're fine.

05:46:53 <niq> SP> And what I said is: that is a minefield onto which we [the HTML

05:46:55 <niq> working

05:46:57 <niq> SP> group] do not want to step.

05:46:59 <niq> ]]]

05:47:03 <niq> (from http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Apr/0029.html)

05:47:43 <sbp> I think I remember that. the HTML WG really have quite enough on their plate already, though, without normalization issues for their legacy formats

05:47:57 <niq> so it would seem

05:52:02 <DanC> I assume HTML tidy is a nasty hairball of special cases inside... I'm such a happy customer that I've never looked.

05:52:15 <DanC> have you guys peeked under the covers?

05:52:35 <niq> yes, somewhat

05:52:46 <sbp> I have, once. it's... baffling, IIRC. John Cowan has something which is apparently more regular

05:53:00 <niq> but in the context of using it in Apache, and I rejected it for that 'cos it's not thread-safe

05:53:34 <sbp>http://mercury.ccil.org/~cowan/XML/tagsoup/

05:53:35 <dc_rdfig> C: http://mercury.ccil.org/~cowan/XML/tagsoup/ from sbp

05:53:49 <sbp> C:|TagSoup; an HTML parser by John Cowan

05:53:49 <dc_rdfig> Titled item C.

05:53:56 <niq> I've kind-of settled on HTMLparser from Daniel Veillard's libxml2 rather than Tidy

05:54:05 <DanC> baffling is what I'd expect. but it's really wonderful, in another way. Dave Raggett wandered the planet for some 10 years accumulating information about idiosyncracies of HTML. Then, unlike most great chess players, he managed to teach the computer most of what he knows about the subject!

05:54:14 <sbp> C:Cowan: "I have been working on a new parser written in Java that, instead of parsing well-formed or valid XML, parses HTML as it is found in the wild: nasty and brutish, though quite often far from short"

05:54:14 <dc_rdfig> Added comment C1.

05:54:16 <niq> hehe

05:54:23 <sbp> heh, yeah

05:54:58 <sbp> now if he could just generate some less-baffling documentation from the code...

05:55:02 <niq> JAVA: if using Java then NekoHTML would be my #1 candidat

05:55:02 <dc_rdfig> Label JAVA not found.

05:55:11 * DanC wonders if Cowan's work is causally connected to my python html3.2 thingy

05:55:16 <DanC> causally

05:55:54 * sbp is starting to wonder why he hasn't written an HTML normalizer--feels left out

05:56:09 <niq> :-)

05:56:12 <DanC> why would you expect anything less baffling than the existing code? You don't think there's much rhyme or reason to HTML-as-she-are-spoke, do you?

05:56:45 <niq> all the browsers grok it in some way ...

05:58:00 <sbp> as she are spoke: I think that with a bit of Tufteianism, perhaps it can be made at least apparent to the intelligent reader what tricks are being employed

05:58:26 <DanC> the browsers grok by way of a monstrous kludge tower

05:58:36 <niq> Definitive HTML normaliser has to be SX - as it runs on a rigorous SGML parser

05:58:39 <DanC> not even a tower

05:58:46 <sbp> yeah. and the browsers are the specifications...

05:59:03 <niq> but libxml2 or tidy are more "pragmatic"

05:59:08 * DanC finds my HTML 3.2 thingy... http://www.w3.org/XML/9705/xml.py <- http://www.w3.org/XML/9705/hacking

05:59:25 <sbp> which is why I limit myself to as small an HTML subset as I can

05:59:26 <zoyd> sbp: hi

05:59:36 * sbp checks it out

05:59:39 <sbp> hey zoyd

05:59:47 <zoyd> sbp: i tried your n.py .. bt i get a namespace error of some sort.

05:59:56 <DanC> sbp, do you use emacs? have you seen nxml-mode? it's the holy grail, as far as I'm concerned.

06:00:18 * zoyd is looking to study how a scutter is written

06:00:21 <niq> Hmmm, 1997 .. I guess that pre-dates python's current *ML stuff?

06:00:58 <DanC> "Sep2003: woohoo! Clark's nxml mode is just the ticket!" -- http://dm93.org/z2001/CostEffectiveHTML

06:01:03 <sbp> hehe: "For me, XML puts the fun back into web hacking. I wrote three XML parsers last weekend. Great stress relief!"

06:01:29 <sbp> nxml: oh yes. I got it pretty much straight away. I'm actually more of an XEmacs user, so I'm *really* hoping that jjc gets around to porting it

06:01:54 <sbp> but I had to try it. it's almost tempting enough to make me use emacs with some regularity...

06:02:24 <DanC> I just happen to be using emacs for a while because my xemacs installation went kerflewey

06:02:53 <DanC> [[ I just went and got James Clark?s new nXML Emacs XML editing mode. I poked around a bit, wondering which XML parser and RelaxNG engine he was using, and worrying how much trouble I?d have getting this running and hooked in to my hand-compiled Emacs here on OS X. No, it?s not like that. There are 12,587 lines of elisp here apparently implementing a complete XML 1.0 processor and RelaxNG validation engine. Words fail me. ]] -- htt

06:02:53 <DanC> p://www.tbray.org/ongoing/When/200x/2003/09/18/NXML

06:02:55 <sbp> Bray: "There are 12,587 lines of elisp here apparently implementing a complete XML 1.0 processor and RelaxNG validation engine. Words fail me." - http://www.tbray.org/ongoing/When/200x/2003/09/18/NXML

06:02:59 <sbp> snap!

06:03:00 <zoyd> is that ruby scutter danbri(?) wrote being maintained anymore?

06:03:11 <sbp> kerflewey: doesn't sound fun

06:03:43 <sbp> zoyd: not that I know of; he seems to have passed the baton to the other FOAF developers

06:04:14 <DanC> kerflewey is part of life with debian sid :)

06:04:45 <zoyd> am looking for a simple scutter.

06:04:53 <sbp> at least you've got nxml to make up for it

06:05:08 * niq lacks the manual dexterity for emacs's multi-key controls ... typos galore

06:05:43 <sbp> zoyd: in what language?

06:06:21 * sbp starts thinking about hacking on an RNC module for Python...

06:07:51 <zoyd_> sbp: preferably python, but ruby and perl would do too.

06:08:23 <DanC> RNC?

06:08:33 <sbp> zoyd: have you seen http://rdfweb.org/topic/ScutterSpec ?

06:08:43 <sbp> RELAX NG Compact Syntax

06:08:50 <zoyd_> sbp: yes, but need some code.

06:09:22 <sbp> http://relaxng.org/compact-tutorial.html

06:10:16 <sbp> zoyd => http://frot.org/rdfweb/ayf.html

06:10:43 * zoyd_ downloads

06:11:17 <sbp> RNC is just staggering. it's what DTD syntax aspires to...

06:11:46 <sbp> if one could just interleave start...

06:12:44 <zoyd_> sbp: thanks.

06:12:49 <sbp> you're welcome

07:24:36 * DanC regenerates http://www.w3.org/XML/9711theory/FormalSystem.html after undoing nasty symbol font hack in lsl2html, feels much better

07:32:41 <eaon|zZz> eaon|zZz is now known as eaon|out

08:26:28 <D[a]vey> Hey uh, DanC, you about?

09:14:09 <maxf> hi libby

09:14:19 <libby> hey maxf :)

09:14:27 <libby> hoa re you?

09:14:35 <libby> how are you even

09:14:40 <maxf> heh.

09:14:48 <maxf> Been working all night on SWAD!

09:14:57 <libby> !

09:14:57 <maxf> stuff with Nikki :)

09:15:04 <libby> no project is worth that!

09:15:12 <maxf> but it's fun!

09:15:12 <libby> not even SWAD-E ;))

09:15:16 <libby> yeah?

09:15:21 <libby> ok, in that case...

09:15:39 <libby> ...work some more

09:15:41 <libby> ;)

09:15:48 <maxf> heh. If only it was useful...

09:16:24 <D[a]vey> libby!

09:16:37 <libby> morning davey

09:16:46 <D[a]vey> libby: I have another suggestion.

09:16:52 <libby> I thought it was useful maxf...?

09:17:11 <maxf> on the phone, talk later

09:17:24 <maxf> (dave raggett, may take a while ;)

09:17:24 <libby> ok, cool

09:17:28 <libby> :)

09:18:22 <libby> what's that davey?

09:18:37 <D[a]vey> libby: you *must* *must* *must* set out a defined markup schema for rdfical

09:18:45 <libby> eh?

09:18:55 <libby> we have an rdf schema...

09:19:06 <D[a]vey> in that... as I understand it, with RDF, theres more than one way to do something....

09:19:14 <libby> yep, that's right

09:19:32 <D[a]vey> and as such, rdfical needs to decide on *a* way, and stick with it. Otherwise its just gonna be hell to parse with XSLT or otherstuff... I imagine.

09:19:51 <libby> hm, well, it is rdf and rdf is like that

09:19:59 <libby> which is one problem with rdf

09:20:13 <libby> I think it's a reasonable suggestion

09:20:33 <D[a]vey> sure, but you have the right to say "To make it easiest for people to actually share their data, we're going to use X way of doing this"

09:20:53 <libby> however, for example when we were working out how to include foaf stuff, we had to change the exact xml elements and things, so it may be harder than it looks

09:20:57 <D[a]vey> or maybe decide on a couple of ways, so its either one or the other and everyones happy.

09:21:18 <libby> ldodds did some cool stuff in schematron for this

09:21:50 <libby> for foaf I mean

09:22:07 <D[a]vey> well, see, including FOAF... thats a namespace thing, and surely... thats gonna be something that could come up in *any* XML dialect?

09:22:11 <libby> I think rss 1.0 has something similar too

09:22:41 <libby> well, for some people, that's why RDF is good: it enables you to mix namespaces sensibly

09:23:19 <libby> yes it is going to come up in many dialects *but* RDF has the most flexible syntaxin therms of rdf, so its much more likely to happen tthere.

09:23:26 <D[a]vey> I'm gonna really have to put in some major reading work this week, then I'll be able to make better, more informed suggestions :)

09:23:52 <libby> no, it's a good suggestion, and one that's likely to come up again if people start using this stuff

09:24:02 <D[a]vey> I think the problem I forsee is this, OK, we might have namespaces to deal with... but why should the client on TOP of that have to deal with 10 million different possible RDF syntaxes?

09:24:13 <libby> people don;t want to have to deal with RDF as RDF, which is unfortunate

09:24:32 <libby> well, they could use an rdf toolkit, which are pretty well developed now.

09:24:43 <libby> but most xml people want to stick with their xml tools

09:24:49 <D[a]vey> yes.

09:24:51 <libby> which is natural enough

09:25:02 <D[a]vey> (still trying to get my head round RDF isn't actually XML really thing)

09:25:22 <libby> yeah it's confusing

09:25:49 <D[a]vey> specially at 10:30am when I haven't slept yet ;)

09:26:05 <libby> heh, blimey

09:26:13 <libby> some people find danbri's article useful: http://www.w3.org/2001/10/stripes/

09:26:19 <libby> although not all syntax is striped

09:26:21 <libby> in rdf

09:26:51 <libby> I will have a think about xml and rdfical etc and chat to people about it

09:26:56 <D[a]vey> thats a bookmark for after I've slept ;)

09:27:05 <libby> cool

09:30:07 <libby> against this idea of fixing schemas for it is that you lose the nice flexibility of rdf

09:30:38 <D[a]vey> does ical needs that much flexibility?

09:32:04 <nmg> morning all

09:32:27 <libby> heya nmg

13:06:26 <nmg> nmg is now known as nmg_meeting

13:32:02 <tav_> tav_ is now known as tav

14:00:14 <nmg_meeting> nmg_meeting is now known as nmg

14:00:22 <libby> hey reagleBRKLN, neat artile about encryption and foaf

14:01:37 <reagleBRKLN> hi libby, thanks

14:01:50 <reagleBRKLN> just reading the comments :)

14:02:31 <reagleBRKLN> drats, still no PGP support in XMLSec http://www.aleksey.com/xmlsec/download.html

14:03:46 <reagleBRKLN> Libby, yes, and there is the question of "propagation."

14:04:25 <reagleBRKLN> You'd need something like XACL http://www.trl.ibm.com/projects/xml/xacl/ I suppose, for the RDF

14:04:55 <libby> #"propogation" as in, accidentally or otherwise re distributing prviously encryped stuff?

14:05:00 <reagleBRKLN> And again, that's assuming people respect the policies

14:05:00 <reagleBRKLN> yep

14:05:17 <libby> right, yeah

14:05:45 <JibberJim> that becomes problematical with smushed results I think, you have some private info which reveals l

14:05:47 <reagleBRKLN> there's 3 approaches:

14:05:53 <libby> interesting because people are so incredibly open about what hey put in blogs and so on

14:06:07 <reagleBRKLN> 1. encrypt and hope authorized recipients doesn't redistribute

14:06:10 <libby> yep jim....

14:06:21 <JibberJim> libby the exotic dancer and libby the RDF geek are the same person, it makes it tough to export any data

14:06:27 <reagleBRKLN> 2. specify access control and hope receiving software enforces

14:06:33 <libby> heeey

14:06:42 <reagleBRKLN> 3. create an oracle service where folks always come to you

14:06:56 <libby> what happened to the superperson example? ;)

14:07:08 <libby> oracle service?

14:07:31 <DanC>http://tantek.com/log/2003/0813t1158.html

14:07:32 <dc_rdfig> D: http://tantek.com/log/2003/0813t1158.html from DanC

14:07:34 <reagleBRKLN> I mean, an on-line model where folks always have to come to you, can't store the data locally

14:07:44 <DanC> D:|Weaving The Web quotes and commentary

14:07:45 <dc_rdfig> Titled item D.

14:07:54 <DanC> D:20030813 tantek

14:07:54 <dc_rdfig> Added comment D1.

14:07:55 <libby> this data will explode in 30 seconds?

14:07:56 <JibberJim> I wanted a fake example libby, didn't think it appropriate to reveal your actual secret identity...

14:08:05 <libby> fair enough :)

14:08:10 <reagleBRKLN> speaking of smushing, I've given up: http://goatee.net/2003/09#_05fr " And even though you will be hard pressed to find an instance of my name on this site and I used to ask people not to link to this site, particularly if the link contained my name if you search Google for my name presently, Goatee is the second return! It still figured it out."

14:08:31 <libby> interesting

14:08:59 * DanC wonders if there's a lesson there for the public-sw-meaning forum

14:09:15 <libby> people are being very open about saying stuff about themselves, might get a shock when everything is smushed tgether. but maybe happening alreday

14:10:11 <kao> are you talking drm for rdf data here?

14:10:15 * libby notes UK government plans along these lines: http://www.guardian.co.uk/guardianpolitics/story/0,3605,1052343,00.html

14:10:25 <libby> drm?

14:10:32 <kao> digital rights management

14:10:48 <kao> like, youre not allowed to copy this cd, or use this mp3 on only three computers

14:10:50 <libby> duh, yes

14:11:05 <libby> I guess it could be

14:11:17 <kao> sigh... so much for a free and open rdf world :-(

14:11:20 <libby> but thinking more of information about people

14:11:35 <libby> well I think the focus is different

14:11:38 * JibberJim has now found Joseph's comments, and Libby had already made my superhero point!

14:12:05 <libby> some data about yourslef you kust dont want to give out to everyone. and without hding by obscurity, encryption seems the best way

14:12:06 * reagleBRKLN didn't grok superhero point

14:12:19 <libby> it's simlar to exotic dancer point...

14:12:31 <reagleBRKLN> ah

14:12:43 <D[a]vey> exotic dancer... ?

14:12:49 * D[a]vey wonder what he walked into

14:12:57 <libby> heh, see logs

14:13:05 <kao> as, in, only people who know the decryption key may use this chunk of encrypted rdf data?

14:13:28 <libby> well reagleBRKLN has a more interesting idea, but yes

14:13:54 <kao> oh? any pointers on that?

14:14:19 <reagleBRKLN>http://reagle.org/joseph/blog/technology/foaf-sphere

14:14:20 <dc_rdfig> E: http://reagle.org/joseph/blog/technology/foaf-sphere from reagleBRKLN

14:14:27 <kao> imho you cannot really prevent data on the web from spreading, so the encryption idea sounds good

14:14:29 <reagleBRKLN> E:Sphere's of Control in Social Networks

14:14:30 <dc_rdfig> Added comment E1.

14:14:32 <libby> ah, reagle found it first

14:14:38 <kao> thanks

14:15:03 * libby thinks mightnot be abe to stop decrypted data from sopreading wither

14:15:29 <kao> ok, i see the problem, and agree

14:15:42 <libby> I dont really know

14:15:47 <libby> we'd have to see what happened

14:15:56 <libby> it could easily happen accidentally though

14:16:04 <reagleBRKLN> You need yucky DRM to try to stop it... I remember PGP had a FYEO mode (for your eyes only) where it would only display the text and delete it... but that supposes that the receiving PGP client hasn't been compromised

14:16:17 <reagleBRKLN> in any case, I'm mostly concerned about accidental/incidental exposure.

14:16:20 <libby> and that would suck if people encrypted very very secret and important data

14:16:36 <libby> yeah, I think that's the main issue

14:16:40 <kao> well... usually, you only give decryption keys to parties you trust

14:16:53 <kao> if someone you *dont* trust get the key too, it is compromised

14:17:00 <libby> yeah, that's why accidental release is interesting

14:17:09 <libby> ...and jim's sumshing argument

14:17:12 <kao> in this case, trust = assume party wont spread decrypted data

14:18:16 <kao> what is "accidental" release?

14:18:26 <libby> but tools need to make it easy not to spread it

14:19:08 <reagleBRKLN> after decryption... there could be a use policy associated with the data just pulled out... need to "tag" the RDF with this then, but that's not the way people are used to thinking about the data

14:19:14 <JibberJim> If I've got two identities kao, I give my tool permission to give my email address to anyone who asks for both identities - my Geek identidy, and my international superhero identity.

14:19:36 <libby> hence the smushing problem that jim came up with: you 'smush' the sekret data with non-secret, and that reveals something new about the person...and then you rebroadcast it

14:19:52 <libby> I'm doing quite a lot of rebriadcasting through web-service-like interfaces

14:20:06 <libby> (though not with smushing or encryption)

14:20:14 <JibberJim> so if you come along and ask for "Jim Ley" I give you jim@jibbering.com and if you want "SVG Man" I give you SVGman@superheroes.com - however some people know that I'm really the same person and provide some RDF describing that but to only trusted people.

14:20:16 <libby> rebroadcasting rather

14:20:48 <libby> I agreee reagleBRKLN, it's not the way people are used to dealing with the data

14:20:54 <JibberJim> my store combines the two people based on the trusted RDF - and then people who come along asking for Jim Ley get the wrong email address.

14:21:25 <JibberJim> Smushing is expensive, which is why smushing for each individual access rights is gonna be a scary thing to do - it'll make our tools very slow.

14:21:44 <libby> it doesn;t even have to be smushed: peopel culd accidentally tell the store that svgman and jim are the same person

14:22:10 <kao> but do you need smushing? what about keeping ithe two identities in different contexts/formulae?

14:22:18 * libby does the smushoing locally and temporarily for calebdar stuff. but that's pretty limited

14:22:28 <kao> the secret statement could assert things about both formulae then

14:22:31 <libby> smushing is pretty important for foaf

14:23:05 <kao> because of the indirections - someone whose email is x - ok

14:23:09 <libby> I think it's partly about people being aware that they can make mistakes and relaese private info

14:23:13 <libby> right yep

14:23:33 <libby> although its interesting that most foaf docs I've seen *dont* say much aboiut other people

14:24:55 <libby> really intersting bunch of problem anyway. and I love reagle's idea about 3/5 people you know very well releasing your data being enough.

14:26:41 * kao dimly remembers a cryptography course... partial keys...

14:27:22 <kao> i think there are some systems that require at leats n key parts to decrypt something

14:27:29 <kao> forgot how that worked though

14:27:31 <dajobe> reed-solomon?

14:27:37 <JibberJim> Yeah, we definately need smushing kao - answering questions like "Who lives near me and is interested in SVG and RDF?" you're not gonna get that info from a single RDF doc.

14:27:47 <kao> dajobe: could be, yes

14:28:22 <kao> yes, agreed, jim

14:29:01 <kao> after all, the idea is to get some interesting answers by using multiple data sources

14:29:10 <JibberJim> Incidently, I'm not the superhero SVG Man, it's just an example...

14:29:45 <kao> hm. do i trust your assertion, or your repudiation now? ;-)

14:33:25 <eaon> eaon is now known as eaon|out

14:48:24 <Talliesin> <libby> although its interesting that most foaf docs I've seen *dont* say much aboiut other people

14:48:54 <Talliesin> 1. I don't think the FOAF-o-matic will produce such info.

14:49:18 * reagleBRKLN adds link from blog page/comments to IRC log... we need IRC log trackback! :)

14:49:38 <Talliesin> 2. How well do you have to know someone before you foaf:know them? Do I know you? Do I know timbl (who I haven't chatted to, but I know who he is etc.)

14:49:43 <libby> indeed Talliiesin, good point

14:49:57 <libby> yeah reasgleBRKLN, I keep running into that

15:15:21 * DanC donesn't see why this trackback stuff doesn't exploit arbitrary incoming links

15:16:28 <DanC> i.e. if somebody follows a link from the IRC log to reagleBRKLN's blog, and his blog wants to show backlinks, doesn't that pretty much cover it? I can see a separate class of explicitly POSTed comments, but why not exploit normal backlinks too?

15:16:55 <reagleBRKLN> DanC, you mean from the referrer log?

15:17:44 <DanC> yup

15:18:03 <reagleBRKLN> One could automate that, many blogs did for a while, until the sex spammers caught on

15:18:18 <DanC> sigh.

15:19:05 * DanC noodles on trust metrics to ward of sex spammers

15:20:00 <reagleBRKLN> yes, one idea i thought of is that a white list wouldn't be as hard, since I could only accept links from the blogosphere which is fairly well known and connected

15:20:07 <reagleBRKLN> (hrmm... maybe i should write that up)

15:20:59 * timbl forgot how to install pyxml on os x... gets tthis "noparsers found error on the new machine..

15:21:00 <D[a]vey> I wonder how many e-mails a day Tim Berners Lee gets :/

15:21:21 <timbl> Are you asking?

15:21:50 <D[a]vey> I was just thinking aloud :)

15:22:26 <timbl> I think I get about 100 after filtering very strongly.

15:22:35 <D[a]vey> thats quite a few :)

15:22:39 <timbl> That excludes list membership

15:22:41 <D[a]vey> and uh, Hi ;)

15:23:12 <D[a]vey> I was thinking, because I sent a proposal about opening as the keynote speaker for my conference, no reply... so I'm hoping it was lost in the ether or some such :)

15:23:58 <ndw> ericm?

15:24:18 <timbl> Then you haev to tell mw who you are.

15:24:32 <timbl> (I have no mail from davey#usercloakc.freenode ... ;-)

15:24:35 <reagleBRKLN> hi timbl

15:24:55 <timbl> Hi Reagle, hows it going

15:24:57 <D[a]vey> timbl: I'm Davey Shafik, Chairman on the board of directors for the PHP and Web Standards Conference UK 2004, I would have sent the e-mail using davey@php.net :)

15:25:42 <D[a]vey> I sent it on 28/08/03 if you're trying to find it :)

15:26:01 <reagleBRKLN> it's going ok.

15:26:09 * DanC struggles to parse that date... perhaps 28 August 2003

15:26:22 <D[a]vey> DanC: of course, its a british date :)

15:26:36 <DanC> :)

15:26:41 <reagleBRKLN> too much yucky theory (marx, sartre, etc!) stuff

15:26:50 * timbl notes D[a]veyD[a]vey is away -( auto-away after 30 minutes idle )- since 06:07p -( P:On / L:On )-

15:27:18 <reagleBRKLN> hopefully i'll find my stride and some >80% of my time doing stuff I'm interested in, without getting freaked out or overwhelmed :)

15:27:34 <D[a]vey> D[a]vey is now known as Davey

15:27:36 <Davey> very sorry :)

15:29:12 * ericm waves to ndw

15:30:57 <reagleBRKLN> btw: did do some interesting reading on my own

15:30:58 <reagleBRKLN>http://www.istl.org/02-fall/review5.html

15:30:58 <dc_rdfig> F: http://www.istl.org/02-fall/review5.html from reagleBRKLN

15:31:10 <reagleBRKLN> f: distributed work

15:31:13 <libby> sartre reagleBRKLN? on what course?

15:31:19 <reagleBRKLN> F:distributed work

15:31:19 <dc_rdfig> Added comment F1.

15:31:47 <reagleBRKLN> it's the mandatory PhD seminar, taught by a frightfully intelligent marxist social theorist

15:31:56 * ndw waves back to ericm and sends a /msg his way :-)

15:32:18 <reagleBRKLN> i like my course on socialization though, want to look at how newbies get "socialized" into collaberative geek communities

15:32:41 * libby rather liked reading marx; never read any sartre though

15:32:52 <libby> sounds interesting

15:36:22 <reagleBRKLN> i might enjoy marx if i had some time, but reading grundisse and capital in one week is no fun

15:37:50 <libby> ble

15:39:29 * libby has an intersting discussion rl about whether seweb group here should (if offered) accept reaesrch money from military

15:39:33 * libby thinks

15:39:35 <libby> no

15:39:47 <libby> not that they are offering

15:40:16 <libby> semweb group @ ilrt I mean

15:40:46 * DanC wonders if reagleBRKLN could help with my quest to explain naming in web architecture in terms of information theory and/or economics

15:41:51 <DanC> [[

15:41:52 <DanC> This bit about "strong social expectations" and "always a matter of

15:41:52 <DanC> policy" seems more awkward and arbitrary than it should be. It

15:41:52 <DanC> seems like there should be a simple, compelling argument

15:41:52 <DanC> from information theory and economics about URI persistence

15:41:54 <DanC> and ambiguity.

15:41:56 <DanC> ]]

15:42:02 <DanC> -- my review of the 26Sep webarch draft

15:42:15 <libby> interesting

15:42:58 <DanC> . http://www.w3.org/2001/tag/2003/webarch-20030926/

15:49:41 * Davey can't wait to get on with his site

15:59:13 <ndw> libby, in your foafattend example, you say:

15:59:14 <ndw> <ical:dtstart rdf:parseType='Resource'>

15:59:14 <ndw> <ical:date>2004-05-17</ical:date>

15:59:14 <ndw> </ical:dtstart>

15:59:26 <libby> yep

15:59:44 <ndw> That'd be the same as <ical:dtstart rdf:resource="ptr">; <ical:date rdf:about="ptr">2004-05-17</ical:date>, right?

16:00:16 <libby> yes I think so

16:00:33 <libby> thouhg maybe using rdf:nodeID better than using rdf:about and resource

16:00:34 <ndw> but if you had two ical:dates done your way, they'd be distinct, right?

16:00:57 * libby worries

16:01:03 <ndw> but my way, I could have one date object pointed to by more than one event, right?

16:01:12 <ndw> (maybe I just don't understand how parsetype=Resource works.

16:01:20 <libby> no, you are right

16:01:51 <ndw> is that distinction an important part of the RDFical model, or is it ok for me to point to a single ical:dtstart for all events on a given day?

16:02:04 <libby> and you coudl ahve <dtstart><rdf:DEacription><date>2003-05-04</date></rdf:Descripotion></dtstart>

16:02:17 <libby> no it's not part of the mdel, it's a syntactic thing

16:02:32 <libby> i.e. a way of majking it nier to look at

16:02:47 <libby> I feel it may be aan issue sometimes

16:03:20 <ndw> ok, cool. I'm not sure which way i'll end up doing it.

16:03:45 <ndw> I already have a "calendar" in my model, the convenient thing to do would be to point to the right day in that model, but it wouldn't fit the dtstart form so I probably can't.

16:03:48 <libby> e.g. http://swordfish.rdfweb.org/discovery/2003/09/foafcal/foaficaleg.rdf - first example doesnt allow you to talk about foaf:Person as an attendee

16:04:23 <libby> well it really should not be an issue, but I think that it probably will be, as people will prefer a specific syntactic form for cretain purposes

16:04:30 <libby> certain

16:05:15 <ndw> Ok. I guess I can do it either way since I'll be generating stuff from another form anyway

16:05:15 <nmg> does DAML+OIL have a mimetype?

16:05:34 <ndw> thanks, libby!

16:05:42 <libby> e.g. http://ilrt.org/discovery/chatlogs/rdfig/2003-10-01.html#T09-18-22 earlier today

16:05:47 <libby> np

16:06:20 <libby> ...people want to use xslt etc for rdfical (and foaf: leigh dodds did some neat schematron schemas for that)

16:07:04 <Davey> people like me :)

16:07:19 <libby> indeed :)

16:07:24 <libby> lots of people probably

16:07:25 <ndw> I hear you. I've given up on that.

16:07:30 <libby> certainly in foaf lots

16:07:40 <ndw> I expect to process my RDF with RDF tools and they're going to spit out whatever serialization they want

16:07:54 <libby> that's a big issue

16:07:55 <ndw> I'll use rdftwig or something else to get my data back out

16:08:00 <ndw> it is

16:08:00 <libby> not being able to control the output

16:08:10 <Davey> ndw: in which case the RDF tools do not care if rdfical sets it own rules... ?

16:08:32 <Davey> so long as its valid... if you understand my meaning

16:08:35 <ndw> i don't think general rdf tools are going to care about any special rules

16:08:37 <libby> the rdf tools won;t, butconsuming tools that encounter rdf may find they acnnot understand it

16:08:46 <ndw> yep. it's a big problem.

16:08:49 <libby> ...if outputted by an rdf tool

16:08:58 <Davey> it cannot hurt the RDF side to set rules on rdfical but it CAN hurt the XML side if you do not.

16:09:05 <ndw> rdf tools, afiact, are simply going to have to load rdf graphs and process those

16:09:51 <ndw> yes, i don't object to RDFical rules. And I'll follow them if they exist. But I'm going to slurp up my RDFical with Jena eventually and I'm going to get back whatever Jena spits out.

16:10:34 <libby> yep

16:10:45 * libby niips off...l8r...

16:12:55 <ndw_> ndw_ is now known as ndw

16:49:22 <JibberJim> OT, but does anyone know where I can find an XHTML 2 requirements doc, or something to enable me to actually do a review of XHTML 2 ?

17:06:18 <Davey> Davey is now known as D[a]vey

17:07:39 <maxf> hi dan

17:08:18 <danbri> hello

17:22:48 <D[a]vey> JibberJim: you'll be lucky, theres no specs at all yet. Which I quite annoying :/

17:23:00 <D[a]vey> (as in, no DTD)

17:23:58 <JibberJim> yes, but they need to know the requirements before they start.

17:25:41 <D[a]vey> JibberJim: requirements of what? useragents?

17:25:47 <D[a]vey> oh, what XHTML needs to do?

17:25:55 <D[a]vey> I need major sleep :/

17:27:33 <JibberJim> Yes, so I can review the draft, I don't see the point of publishing a working draft if I don't know the problem the rec is proposing to solve.

17:28:03 <D[a]vey> Hmm.. not run across that document yet

17:41:49 <DanC> wierd... my local logs show:

17:41:59 <DanC> ah. got it.

17:42:32 <DanC> formalizing webarch http://rdfig.xmlhack.com/2003/09/22/2003-09-22.html#1064258658.804608

18:12:39 <aharth>http://seco.semanticweb.org/

18:12:40 <dc_rdfig> G: http://seco.semanticweb.org/ from aharth

18:13:46 <aharth> G: Aggregator for news and people (RSS and FOAF vocabs)

18:13:46 <dc_rdfig> Added comment G1.

18:14:46 <aharth> g:| News & People Aggregator

18:14:56 <aharth> G:| News & People Aggregator

18:14:56 <dc_rdfig> Titled item G.

18:15:23 <aharth> G: based on Jena2

18:15:24 <dc_rdfig> Added comment G2.

18:46:37 <dmiles_afk> dmiles_afk is now known as dmiles

19:14:44 <eaon|out> eaon|out is now known as eaon

20:28:06 <sbp> heh, wow: "So if you are into DOI/INFO for the money, ego, or control, go right ahead with it." - sandro, http://lists.w3.org/Archives/Public/uri/2003Oct/0012

20:29:36 * sandro signs and looks sheepish.

20:29:40 <sandro> sighs I mean

20:29:56 <sandro> sometimes I'm not very tactful.

20:30:25 <sandro> arguably -- this is politics, and sometimes mudslinging really is warranted.

20:30:54 <sbp> well, it's certainly a possibility that some of those things are motivating factors... there's so very little sense in the actual scheme itself

20:32:08 <danbri> are you talking about info: ?

20:32:36 <sandro> yep

20:32:48 <danbri> how did i guess...

20:33:04 <sandro> you can tell me if it was over the top, danbri. :-)

20:41:43 <danbri> it? what msg am i missing?

20:42:35 <JibberJim> sandro, http://lists.w3.org/Archives/Public/uri/2003Oct/0012

20:44:37 <sandro> sbp, what's your level of motivation re: tag: URI scheme? We had a big telecon about it in July, and the IESG gave me and TimK some homework, which neither of us seem to have done.....

20:44:38 <mmealling> no where near over the top.... I've been over the top.... IMHO, more people should....

20:45:05 <sandro> Yes, I guess my message was a lot like yours about doi:, Mike. :-)

20:45:31 <mmealling> as Mr. Paskin has said by inference, its all about replacing DNS...

20:46:11 <sandro> which puts you in an odd place... :-)

20:47:17 <sandro> I sure wish there wasn't a regular stream of horror stories about the DNS.... (the latest being sitefinder, which mostly raises the spectre of "Who Is Really In Control?")

20:48:30 <sbp> motivation on tag:: well, I can see how going through the IESG process to get it done could be annoying...

20:48:47 <sbp> and I think if it were something that you strongly needed to use every day, perhaps you'd be thinking about it a little differently

20:48:55 <sandro> mostly I have no need for tags any more.

20:49:03 <sandro> right

20:49:08 <sbp> of course. you've got w3.org datespace to play with...

20:50:03 <sbp> I think the motivation for someone like me is stronger, since I think I'm bound to lose my domains one of these days. but I'm not publishing many widespread schemata, and there's always PURL...

20:50:28 <sandro> it's been good for me to get a digital camera -- I can't put the pix in w3 datespace, but I want them and their metadata on line for 50+ years. I have some ideas.

20:50:28 <dajobe> who runs purl, sbp?

20:50:50 <sbp> I've been wondering if there is a clear HTTP alternative to TAGs. if there isn't one, then it's probably okay to go ahead with the scheme should there be enough users

20:50:52 <mmealling> oclc

20:50:52 <danbri> oclc

20:50:55 <sbp> purl.org is run by the OCLC

20:50:57 <danbri> snap

20:50:59 <sbp> heh

20:51:37 <sbp> the problem with tag in HTTP space is that it's bound to depend on some central organization at some point or another

20:52:06 <sandro> right

20:52:17 <sbp> which, even for a strong organization like the OCLC or W3C, is a breaking point. W3C could implement some scheme and have it go down--I think I noticed that the mid resolver isn't in datespace anymore...

20:52:48 <sandro> well, unless a community of arises properly.

20:52:58 <sbp> same with the OCLC. what are their credentials? why should I trust them to still be around in 20 years--or, more to the point, still maintaining my mappings in 20 years? what if there's some political or technical snafu?

20:53:07 <sbp> a community of arises?

20:53:21 * mmealling is on the phone...sorry to ignore the conversation

20:53:55 <sandro> if everyone learns that the domain name owner doesnt have any rights over the meaning of a URI, then they will cease to.

20:53:55 <sbp> oh, perhaps you mean if there were some distributed effort for a URI resolver? Aaron's been working on something a little like that with web.resource.org

20:54:33 <sbp> if that's verified by the domain name owner, yes

20:54:50 <sbp> but the domain name owner always has the power to begin with, and the power to delegate control away...

20:55:05 <sandro> not clear at all.

20:55:17 <sbp> yeah. it's not verifyable on a dig-sig sort of level...

20:55:29 <sbp> perhaps people should be made to sign up for domains with a pubkey :-)

20:55:31 <sbp> [shudder]

20:56:51 <dngor_> dngor_ is now known as dngor

20:57:31 <sbp> in the RDF world, which I guess is what we're both thinking of here since there's perhaps more of a need for URI persistance there than for other things, I think the W3C is the best house for RDF namespaces because they maintain the RDF, RDFS, and OWL namespaces

20:58:19 <sbp> so any application built on top of RDF is going to be relying upon those W3C URIs not to break. which gives W3C datespace more whack than any other domain--if you're going to have to trust organizations, you want to trust as few as possible

21:00:32 <sbp> so W3C is the most widely used, and therefore everybody hopes the strongest, part of the system. which is why I have a natural inclination to want to beg for datespace every time I create a new schema

21:02:02 <sbp> FOAF works, of course...

21:02:23 <DanC> "if you're going to have to trust organizations, you want to trust as few as possible"

21:02:26 <DanC> nope.

21:02:44 <DanC> the optimal position is to put your trust in a set of *mutually distrustful* parties

21:02:58 <DanC> e.g. the DNS registrars

21:03:08 <DanC> or ford/gm/chrysler

21:03:42 <DanC> hmm... ford/gm might not be sufficiently distrustful of each other. I think they collude.

21:04:07 * sbp thinks about that

21:04:45 <sbp> I'm not sure I see how that would work with respect to namespaces/schemata/vocabularies on the Semantic Web

21:06:39 * danbri likes to spread the trust about a bit

21:07:13 <danbri> any thoughts on what best practice is for someone like me, who owns a namespace uri that people seem to be using quite a lot?

21:07:23 <sbp> don't break it?

21:07:25 <danbri> anyone here mentioned their URIs in their will, yet?

21:07:27 <JibberJim> Start charging?

21:07:33 * mmealling developed this little shared state model which worked the less anyont trusted anyone else.

21:08:23 <JibberJim> I've thought about it before http://bash.org/?3800

21:08:25 <sbp> okay, don't put all your eggs in one basket... but doesn't that depends upon your system? for some, if one part (e.g. organization) goes down, the whole lot fails

21:08:44 <deltab> "to http://example.org/me/son I leave http://example.org/me/car"

21:09:46 <sbp> Aaron and ESR have thought about it too: http://www.aaronsw.com/2002/continuity

21:10:24 <danbri> factoid from DC conference: show of hands... "How many of you have intimate knowledge of MARC (a library data format) / vs have had no contact w/ marc".

21:10:40 <danbri> fullish rroom. 1/2-ish intimiate w/ MARC. 1/4-ish no contact.

21:10:45 * mmealling raises his hand

21:10:46 * danbri intermediate btw

21:10:59 <danbri> oh, i wasn't polling #rdfig :)

21:11:09 <danbri> (or i'd have hopefully posed the q better...)

21:11:23 <danbri> you've had intimate content w/ marc?

21:11:37 * danbri s/marc/MARC/ :)

21:11:43 <DanC> how it would work for namespaces: w3.org sorta works, but it's not really optimal in the long term. something more like advogato is. I'd like to see both ICANN and w3.org head that way

21:11:57 <DanC> and maybe IANA.

21:12:16 <mmealling> yea.... even been to several MARC standards meetings....

21:12:18 <mmealling> long ago though

21:12:43 <dajobe> sbp: the link on Aaron's page to "ESR's page" shows the problem about owning domains

21:13:06 <DanC> i.e. it would be cool if (and it's almost the case that) nothing an IANA admin person could do could screw up the list of TCP port number assignments. If only collusion by massive numbers of parties could screw up an established port number.

21:13:43 <DanC> ... and likewise if you could use google kharma (i.e. incoming links) as a defense against trademark disputes in DNS space

21:24:21 <aharth> is there something like a "default value" for RDF? i mean how can I make sure that an individual has a certain property, and if not, assign the default to it?

21:24:33 <mmealling> google karma can be spoofed...

21:24:46 <danbri> aharth, no, we don't do defaulting

21:25:15 * danbri mumbles something about nonmontonic logics and the Web being too researchy to standardise

21:26:08 <DanC> aharth, see "Implementing defaults and log:notIncludes" in http://www.w3.org/2000/10/swap/doc/Reach

21:26:45 <DanC> yeah, I guess google-kharma isn't sufficiently resilient.

21:26:50 * bijan laughs

21:26:55 <aharth> dan*, thanks!

21:27:12 <bijan> "nonmonotonic logics and the Web being too reserachy to standardize"

21:27:17 <bijan> HAHAHA

21:27:20 <bijan> Heh.

21:27:23 * bijan dying

21:27:46 * DanC must have missed the joke

21:28:29 <bijan> Just that i think nonmon is no more researchy than mon on the Web

21:28:35 <bijan> It's ALL a huge crapshot and research issue

21:28:41 <bijan> crapshoot

21:29:17 <DanC> ah

21:30:09 * danbri has been known to occasionally claim we shouldn't have standardised OWL so soon

21:30:14 <danbri> ...but it seems to have turned out ok

21:30:40 <bijan> We standardized?

21:30:42 <bijan> :)

21:30:52 <DanC> it's rolling downhill from where i sit.

21:31:18 <danbri> we=w3c'n'friends...

21:31:28 <DanC> i suppose there's another 80% to do, but i sure hope the vendors to that part.

21:32:09 <bijan> What's clear is that OWL DL is (pretty much) well understood and coming out of a pretty strong community; nonmon is also pretty well understood; adding a tiny bit of webizing is easy; making "the sematnic web" out of these parts is...well...unknown

21:49:00 <DanC> OWL DL... doesn't float my boat. I'm more curious about, say, OWL having an impact on UML practice.

21:49:15 <DanC> hmm... http://www.unimodeler.com/ ... anybody tried that?

21:49:49 <DanC> oops... never mind... not open source

21:49:57 <danbri> oh, UML has figured heavily in DC discussions this week,

21:50:07 <danbri> ...cos the LOM (IEEE etc) edu folks using it.

21:50:19 <danbri> I *thought* I was live scribing the dc-arch session yesterday btw

21:50:24 <danbri> ...but i wasn't connected

21:50:51 <DanC> there's a pretty big gulf between open source and UML... nobody's giving away UML tools.

21:50:55 <DanC> (almost nobody)

21:51:08 <DanC> the linux community thinks so little of UML that they reused the TLA for user-mode-linux

21:53:53 <DanC> hm... http://uml.sourceforge.net/

21:55:02 <DanC> ugh... "Version 1.1 (currently in beta) uses an XMI based file format. It is only very loosly based on XMI and is not compatible with other UML programmes (this seems to be typical of XMI usage)."

22:07:09 <aharth> G: feedback highly appreciated

22:07:09 <dc_rdfig> Added comment G3.

22:17:07 <DanC> G:it wants a cookie. I wonder why

22:17:07 <dc_rdfig> Added comment G4.

22:18:41 <aharth> the application is java servlet based. cookies is the standard session tracking mechanism there.

22:20:08 <DanC> evil.

22:20:54 <aharth> *eg* I can try to disable that

22:21:38 <aharth> however, at some point I probably need it when users want to log in

22:28:16 <DanC> folks that want to log in are asking for a cookie. that's fiar.

22:28:19 <DanC> fair, even

22:31:48 <aharth> you can use all functionality even when rejecting the cookies. not sure whether this is a bug or a feature though

22:32:43 <DanC> I did reject the cookie, but most browsers default to accepting cookies, so I think information providers shouldn't hand them out without asking nicely

22:33:31 <aharth> what would be the prefered process? do you have some reference document that I can consult about this?

22:34:55 <aharth> right now I am just using standard java servlet behavior

22:37:54 <DanC> standard java servlet behaviour is something I haven't found time to complain-thru-channels about

22:38:43 <DanC> no, I don't have a reference document. I hope it appeals to your common sense that you shouldn't store a cookie on my machine unless you need to.

22:39:21 * DanC wonders if one of the cookie RFCs discusses this

22:39:53 <aharth> ok I try to find a way to accomplish this. thanks!

22:40:02 <DanC> likewise!

22:40:06 <DanC> the thing looks pretty cool

22:40:29 <DanC> (had to put blinders on pretty quickly and quit playing with it ;-)

22:40:47 <Morbus> has anyone done bookmarks in rdf?

22:41:01 <DanC> I think so

22:41:01 <aharth> thanks, put some late hours work into it. hope it gets more useful as more foaf gets available

22:41:05 <DanC> .google bookmark rdf

22:41:06 <datum> bookmark rdf: http://www.w3.org/2003/07/Annotea/BookmarkSchema-20030707

22:41:12 <Morbus> ahahahah

22:41:17 <Morbus> i just barely bookmarked that the other day.

22:41:25 <Morbus> thanks <g>

22:41:39 <DanC> G:careful... you could spend a lot of time here.

22:41:39 <dc_rdfig> Added comment G5.

22:49:27 <danbri>http://www.siderean.com/dc2003/event.jsp?event=http://www.siderean.com/dc2003/Paper71-abstract.pdf

22:49:27 <dc_rdfig> H: http://www.siderean.com/dc2003/event.jsp?event=http://www.siderean.com/dc2003/Paper71-abstract.pdf from danbri

22:50:08 <danbri> H:|Towards identity conditions for digital documents, Allen Renear et al

22:50:09 <dc_rdfig> Titled item H.

22:50:26 <danbri> H:Most interesting paper I've seen at a dublin core gathering (though didn't get to hear much detail).

22:50:26 <dc_rdfig> Added comment H1.

22:50:45 <danbri> H:Is really about XML Semantics, ie. extracting various flavours of logical representation from XML structures.

22:50:45 <dc_rdfig> Added comment H2.