Semantic Web Interest Group IRC Chat Logs for 2002-08-07

01:58:25 <tansaku_xr> tansaku_xr is now known as tansaku

02:00:22 <tansaku> tansaku is now known as burtonator

02:00:54 <burtonator> burtonator is now known as Xirzon

02:01:19 <Xirzon> Xirzon is now known as tansaku

09:55:08 <dajobe> once more with the rdf syntax doc editing

12:07:44 <Talliesin> lo

12:08:50 * LotR suspects Talliesin misspelled his nick

12:09:40 <Talliesin> It's partly for numerological reasons, but mainly because every username namespace has competition for the correct spelling (even this spelling is often taken).

12:11:21 <Talliesin> It's going to be worse in about 15 years time since every other Wiccan and Druid names seems to have a son named Taliesin. When those kids start getting online...

12:12:18 * Talliesin desperately tries to think of a way to bring all that on-topic somehow.

12:12:38 <JibberJim> RDF will be able to solve the problem :-)

12:14:03 * LotR giggles at the 'rdf will solve everything' attitude

12:14:27 <Talliesin> Wait till you start hearing it from clients.

12:14:35 <JibberJim> nah, not everything, just the multitude of Taliesin's...

12:14:52 <Talliesin> "RDF it. That'll solve it."

12:15:09 <Talliesin> "It's a UI problem, what's RDF going to do?"

12:15:21 <Talliesin> "Well if I knew that I wouldn't have hired you, now RDF it."

12:19:14 <Talliesin> Actually we already had that about Dublin Core

12:19:20 <Talliesin> They wanted Dublin Core

12:20:22 <Talliesin> They didn't know what they wanted in the Dublin Core, or what we to do with it. Probably just misguided patriotism from people who didn't realise it's the Dublin in Ohio, not the one in Ireland.

12:20:41 <LotR> haha

12:21:07 <Talliesin> Hey, I intend to drum up a lot of trade this way :)

12:21:14 <dajobe> lol

12:22:04 <Talliesin> I can already say "Dublin is definitely on the map as far as metadata is concerned" with a straight face.

12:22:15 <Talliesin> The trick is to bite the inside of your cheek.

12:22:17 <dajobe> the map of OH

12:28:17 <Talliesin> Hmm. Now would that be translated as "Atha Cliath" or as "Dubh Linn"...

12:45:19 <dajobe> hmm, rdf:nil (was daml:nil) probably not allowed anywhere in the rdf/xml syntax. It's a URI used as a statement object, not a class or property

12:49:11 <Talliesin> Hmmm.

12:50:21 <eikeon> Upps.

12:50:35 <dajobe> hi eikeon

12:50:47 <dajobe> want >130 new rdf core test?

12:50:50 <dajobe> tests

12:51:01 <eikeon> Sure!

12:51:09 <dajobe> just checking in

12:51:19 <eikeon> Have to go... back in one hour.

12:51:22 <dajobe> actually I added nodeID to my parser. looks like ~5 mins work

12:51:24 <dajobe> ok

12:51:36 <danbri> :)

12:53:34 <Talliesin> Can one say something about nil?

12:53:41 <dajobe> sure

12:53:46 <dajobe> it's ok as a subject/object

12:54:13 <dajobe> just not allowed as predicate since it's a special marker resource

12:54:19 * dajobe guessing now

12:54:59 <dajobe> hmm

12:55:11 <dajobe> I guess <rdf:nil rdf:about="...."> (property ELement) is OK

12:55:23 <Talliesin> More precisely, can one say something about nil, as it is defined by DAML?

12:55:35 <Talliesin> Obviously one can say stuff about nil, since we are doing so now:)

12:55:37 <dajobe> this is a different nil, as defined by me

12:55:48 <dajobe> I just said: <dajobe> it's ok as a subject/object

12:55:53 <Talliesin> ah, no wories then.

12:55:59 <dajobe> this is banned, for e.g:

12:56:14 <dajobe> <foo:bar rdf:nil="blah" baz:foo="..."> (property element)

12:56:29 <dajobe> since rdf:nil isn't a property and is special

12:56:33 <dajobe> anyone?

12:57:26 <dajobe> also banned I think: <rdf:Description><rdf:nil rdf:resource="http://..../"/> </rdf:Description>

12:57:50 * Talliesin admits to not knowing there was an rdf:nil

12:58:09 <dajobe> just adding it

12:58:13 <Talliesin> I was going by your describing it as "formerly daml:nil"

12:58:16 <dajobe> daml:nil etc moving

12:58:24 <dajobe> did I say formerly

12:58:34 <dajobe> oh, I did

12:58:43 <Talliesin> you part of the working group, or is this for your own purposes?

12:58:45 <dajobe> a different one

12:58:47 <dajobe> wg

13:00:15 <Talliesin> And is this going to have the "empty list" meaning of daml:nil

13:00:15 <Talliesin> ?

13:00:30 <dajobe> I don't describe meaning, this is syntax work

13:02:07 <Talliesin> So what is your nil going to do?

13:02:48 <dajobe> mark the end of the triples structure that'sthe container made by something like this:

13:02:59 <dajobe> <foo:bar rdf:parseType="Collection">

13:03:13 <dajobe> <ex:node1>....</ex:node1>

13:03:18 <dajobe> <ex:node2>....</ex:node2>

13:03:19 <dajobe> ...

13:03:21 <dajobe> </foo:bar>

13:06:04 <Talliesin> So would its presence after three items mean that the graph of the collection couldn't be meaningfully merged with another graph of a collection that was identical except for containing a fourth item>

13:06:32 <dajobe> there are no processing restrictions AFAIK; rdf doesn't describe such things, that's for applications

13:06:39 <Talliesin> That is, does it signify a definite end to the collection?

13:07:05 <Talliesin> Yes, that would be quite a departure, which made me curious about the possibility.

13:07:19 <dajobe> it marks a triple in the result which tells you where the collection (first/rest stuff) ends

13:08:10 <Talliesin> hmm.

13:08:29 * Talliesin must re-read DAML+OIL for a start

13:08:30 <dajobe> like lisp, so I've been told

13:08:44 <dajobe> there's nothing I can find in daml+oil that tells you much more

13:09:07 <Talliesin> ah, it's like a programming language you don't use, and you are the one that has to work this out? :)

13:09:09 <dajobe> see http://www.daml.org/2001/03/reference.html#collection

13:09:14 <dajobe> yeah

13:09:15 <danbri> re rdf:nil, will it be spelled out in full as a URI?

13:09:27 <dajobe> it'll not be in the rdf/xml syntax at all

13:09:36 <danbri> eg http://www.w3.org/1999/02/22-rdf-syntax-ns#nil

13:09:42 <danbri> ah right

13:09:42 <dajobe> unless you are talking about it (rdf:about) or pointing at it (rdf:resource)

13:09:58 <dajobe> so just need to mention it, to ban it as a property

13:10:02 <dajobe> and to reserve it

13:10:10 <danbri> but it'll be in the ntriples...?

13:10:13 <dajobe> I can retreat from the ban

13:10:14 <dajobe> yes

13:10:30 <danbri> but wrong to serialise it?

13:10:30 <dajobe> ... if it turns out it might be a class or something

13:10:48 <dajobe> serialising it in rdf/xml or ntriples will be in subj/obj, which will be oK

13:11:00 <danbri> we can have singleton thingies that aren't classes nor properties; the old MartialStatus example from RDFS did that.

13:11:07 <danbri> ah, good

13:11:11 <dajobe> I've jus labelled it 'resource'

13:11:20 * danbri nods

13:12:15 <dajobe> see http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/#section-Namespace

13:12:21 <dajobe>http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/

13:12:22 <dc_rdfig> A: http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/ from dajobe

13:12:36 <dajobe> A:|RDF/XML syntax WD editor's draft

13:12:37 <dc_rdfig> Titled item A.

13:13:11 <Talliesin> Seems to me that's the best way.

13:13:11 <dajobe> A:Updating this at the moment. Already changed the notation section, added rdf/html notes.

13:13:12 <dc_rdfig> Added comment A1.

13:13:25 <dajobe> A:[http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/#section-Namespace|namespace changes] now include the collection terms

13:13:26 <dc_rdfig> Added comment A2.

13:13:53 <dajobe> I guess I should mail the list, I'm over time

13:16:19 <Talliesin> Maybe it should be banned from being a predicate, but RDF isn't the correct level to impose that ban?

13:16:50 <dajobe> in the rdf/xml syntax; yes - some terms are alreayd banned as predicates etc.

13:17:04 <dajobe> e.g. <rdf:Description rdf:Description="foo"/> isn't allowed

13:19:08 <Talliesin> Ban it

13:19:27 <Talliesin> (newbie opinion is provided "AS IS" and no liability will be accepted)

13:21:09 <dajobe> lol

13:21:36 <Talliesin> Unless <foo> <rdf:nil> <bar> can make sense.

13:23:16 <Talliesin> Could rdf:nil have a subProperty?

13:24:29 <dajobe> it's not a property

13:28:07 <Talliesin> Can something be property and not a predicate?

13:29:08 <dajobe> woosh

13:29:21 <dajobe> sounds like a model question to me

13:29:29 * dajobe does syntax

13:31:01 <Talliesin> More a philosophical question than anything else.

13:31:50 <dajobe> is there a philosopher in the channel

13:31:54 <dajobe> uh oh

13:31:55 <Talliesin> :)

13:33:11 <Talliesin> Though your rejecting as a model question adds weight to my:

13:33:12 <Talliesin> <Talliesin> Maybe it should be banned from being a predicate, but RDF [syntax] isn't the correct level to impose that ban?

13:33:37 <dajobe> can you tell me diff between an rdf property and rdf predicate?

13:34:36 <Talliesin> From my limited understanding:

13:35:34 <Talliesin> A predicate associates a subject and an object, defining a relationship between the two.

13:36:47 <Talliesin> A property is a resourece that can act as a predicate.

13:36:54 <Talliesin> Though I am open to correction.

13:37:22 <dajobe> hmm

13:37:37 <Talliesin> I did 'fess up to being a newbie.

13:37:38 <dajobe> I guess rdf combines both approaches

13:37:49 <dajobe> frame-based and more relational

13:41:02 <dajobe> woo, raptor does rdf:nodeID

13:45:47 * JibberJim is happily using raptor (in rdfdump form currently) from windows script host scripts.

13:46:10 <dajobe> that's nice

13:46:37 <dajobe> could you email me a zip of a build with any notes you have?

13:51:12 <JibberJim> Sure dajobe, when I've got the scutter working, I'll write it up, including the raptor bits, the build is just a cygwin build which is "errno" replaced with "-1" in the two files.

13:51:35 <dajobe> there must be a win32 call to replace that i can use, somehow

13:51:51 <dajobe> when an open fails, how do you know what the error was

13:54:04 <JibberJim> pass.

14:06:52 <JibberJim> dajobe - you just need to include <errno.h> for cygwin builds.

14:07:11 <JibberJim> works fine then with proper error messages from rdfdump.

14:07:34 <dajobe> ah, thanks

14:10:27 <eikeon> Can rdf:first rdf:rest and rdf:nil appear in rdf/xml... or does a serializer have to make use of a rdf:parseType="Collection"?

14:10:48 <dajobe> first and rest are properties (um, predicates?) and so do appear

14:10:58 <dajobe> rdf:nil is only going to be used in subject or object

14:11:08 <dajobe> and hence will never be seen as "rdf:nil"

14:11:11 <dajobe> but the full URI

14:11:20 <dajobe> (or &rdf;nil or somesuch)

14:12:43 <dajobe> I guess if you wanted to re-create parsetype collection, you'd have to check that the node you had in hand, didn't have any incoming rdf:first/rdf:rest properties, and from that you could walk the graph and try to rebuild it. Easier to just emit more triples ;)

14:14:08 <dajobe> dc_rdfig: view

14:14:08 <dc_rdfig> A: RDF/XML syntax WD editor's draft (http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/)

14:14:26 <eikeon> Yep... am just serializing it more generically... might be tempted to add an option to the serializer at some stage though.

14:14:26 <dajobe> A:[http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/|names test cases updated] with rdf:first,rest,nil,List,nodeID

14:14:26 <dc_rdfig> Added comment A3.

14:14:59 <JibberJim> dajobe, can I pass a base URI in to rdfdump to be used rather than the file link?

14:15:00 <dajobe> A:a new test case contains [http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/all.rdf|all legal rdf/xml forms in one file]. I hope that 'all' is true here!

14:15:00 <dc_rdfig> Added comment A4.

14:15:09 <dajobe> JibberJim: yes, that's the 2nd (last) arg

14:19:51 <dajobe> A:well, not *all* forms; but all names used as property elements/attributes and node elements

14:19:51 <dc_rdfig> Added comment A5.

14:24:53 <eikeon> Why not allow rdf:nil in the rdf/xml syntax?

14:26:10 <dajobe> for the same reason <rdf:Description rdf:Description="foo"/> isn't allowed

14:26:12 <dajobe> it's daft

14:27:01 * DanC_jam makes some progress on typed literals in cwm... or at least: in rdfn3.g and KIFSink.py

14:28:03 <DanC_jam> hmm... I really don't like the design of the Thing classes. Seems easier for the store to know where things occur, than to have the things know where they occur.

14:28:32 <tim-away> That's interesting.

14:29:05 <DanC_jam> I'd think the term 45 should be sharable accross stores.

14:29:13 <tim-away> BTW Passed 51 out of 51 general regresssion tests.

14:29:21 <eikeon> Ah... I did not think first. rdf:nil is ending up as the value of an rdf:about anyway in the generic serialization... /me needs a cup of coffee.

14:29:47 <DanC_jam> ah; when I checked in my cleanup recently, tim, there was one that failed; I left it that way on purpose to discuss it with you...

14:30:03 <DanC_jam> did you fix the test with the crazy ../../../../../../ result?

14:30:09 <tim-away> Oh, when I checked it out there were several that failed! :)

14:30:30 <DanC_jam> well, some of them fail because of home directory differences.

14:30:47 <DanC_jam> maybe I missed a few others.

14:30:51 <tim-away> One thing I did was to rereplace your refTo with mine. Both had bugs. Mine I understodd better and have therefore fixed. More test cases are in the uripath.py

14:31:09 * DanC_jam takes a look...

14:31:31 <tim-away> When making a relative path, and the target shares no common path with the base, I prefer to generate a root-relative URI.

14:31:37 <tim-away> hang on ....

14:32:15 * eikeon notices the sharable across stores bit... :)

14:32:30 * tim-away checks in

14:32:32 * DanC_jam doesn't get any new stuff in response to cvs update; presumes timbl's checking in now...

14:32:52 <tim-away> cwm 1.102

14:33:12 <DanC_jam> so... refTo doesn't require that dest is absolute?

14:33:25 * tim-away suggests pause while electrons streak across the continent

14:33:39 <DanC_jam> i.e. your relativeTo didn't; my refTo did... I wonder which way refTo goes now

14:33:53 <DanC_jam> timbl, have you seen the way pydoc works? try pydoc uripath

14:34:09 <DanC_jam> or pydoc -w uripath (which creates uripath.html)

14:34:52 * tim-away reads

14:35:04 <DanC_jam> timbl, have you looked at eikeon's node class? he subclasses built-in python types. pretty cool. I think it's a good design for typed literals.

14:35:15 <tim-away> ooo

14:35:28 <DanC_jam> I think it requires python 2.2

14:36:37 * DanC_jam frowns at refTo_DanC. cvs remembers, timbl.

14:37:09 <danbri> oooh too :)

14:37:24 * danbri can do that in ruby too

14:37:31 <DanC_jam> what's wrong with this test case? ('http://ex/x/y/z', 'http://ex/r', '../../r')

14:37:41 <dajobe> A:welcome rdf:nodeID to the rdf/xml syntax

14:37:41 <dc_rdfig> Added comment A6.

14:37:58 <tim-away> I looked at some rdflib stuff, and copies some generator properties like objects() etc

14:38:41 <tim-away> I also fixed my code so I don't use "if F" to see if a formula returned is not None, so now I should be able tyo implement __len__ and __iter__ for formulae.

14:38:44 <DanC_jam> hm.. ('http://ex/x/y/z', 'http://ex/r', '/r'), # I prefer this.

14:38:44 <DanC_jam> - tbl

14:39:05 <tim-away> However, it is pretty critical for speed that the code uses interned objects instead of strings, IMHO.

14:39:41 * tim-away notes refTo algorithm has some arbitrary choices.

14:39:42 * DanC_jam notes that strings aren't exclusive of interned objects

14:39:59 <tim-away> meaning?

14:40:07 <DanC_jam> you can intern strings

14:40:35 <tim-away> Yes, but does rdflib.store.add(p,s,o) expect strings or interned objects?

14:40:56 <DanC_jam> it expects nodes

14:41:08 <DanC_jam> ... which aren't (required/expected to be) interned

14:41:27 <tim-away> But you are not allowed to use a string - in otehr words it is up to the store.

14:41:31 <tim-away> That is fine.

14:41:55 <tim-away> That is how RDFSink is moving - you generate whatever the sink likes by calling sink.Literal("foo") etc.

14:42:27 <DanC_jam> no, rdflib's nodes are sink-independent.

14:42:46 <tim-away> What did you mean about eikeon subclassing python built-in types?

14:42:57 <DanC_jam> look at class URIRef(str)

14:43:06 <tim-away> Oh, there is a system-wide agreement about how to intern things?

14:43:10 <DanC_jam> his URI references are a subclass of python's strings.

14:43:32 <DanC_jam> yes, I'd like the node class to have an intern dictionary, I think

14:43:54 <tim-away> I didn't know you could do that. class Literal(__internals__.String) OWTTE?

14:44:18 <DanC_jam> do that: it's new. I think in 2.2 or maybe 2.1

14:44:42 <tim-away> Well, that's funny we come full circle. I suggested we have a defualt store which everything is stored in, and you said, no, not reentrant enough, globals suck.

14:44:57 <tim-away> So you have to create a store.

14:45:05 * eikeon plans on adding intern-ing back in...

14:45:17 <deltab> class Literal(str): ...

14:45:31 * danbri wondered about having a default store attached as a class variable to the Graph class, and putting RDF/RDFS/OWL vocab in it

14:45:39 <DanC_jam> full circle: guilty.

14:45:40 <eikeon> stopped interning since interned strings in python are immortal.

14:46:26 <tim-away> And for each eikeon:Store which is like a timbl:Formula, you can create it independently but the interning is shared..

14:46:49 <tim-away> Sounds like there should be a defualt value to the "store" parameter.

14:46:52 <DanC_jam> independent/shared: yes. that's starting to make the most sense, to me.

14:47:07 <tim-away> I am moving to all the interesing operations bveing on the formula anyway, so teh store disappears.

14:47:12 <DanC_jam> stor param: on what?

14:47:42 <tim-away> Ummm. I suppose on some llyn.newFormula()

14:47:48 <DanC_jam> ah

14:48:13 <tim-away> So if you really want to have a separe store you can say llyn.newFormula(myStore)

14:48:37 * DanC_jam wonders if eikon would consider changing the name of the node class to term. node is horribly ambiguous between the syntax space and the domain-of-discourse

14:49:03 * DanC_jam just hashed out use/mention stuff at length in an RDF/topicmap nocturn last night here at ExML

14:49:15 * eikeon got rid of the use of the term node in rdflib 0.9.5

14:49:48 <DanC_jam> whee!

14:50:01 <eikeon> Am now using Identifier... and have mored URIRef etc into there own .py files.

14:50:20 <tim-away> I noticed that eikon, you were using generators instead of returning lists.

14:50:22 <DanC_jam> umm... are string literals identifiers?

14:50:34 <tim-away> (I think I use Symbol at teh momebr)

14:50:49 <tim-away> (I think I use Symbol and Literal and BNode)

14:50:51 <eikeon> DanC_jam: I was unsure about that... currently they are in rdflib 0.9.5

14:50:54 * DanC_jam thinks generators are way cool, but doesn't have enough experience to be confident in this opinion

14:51:09 <DanC_jam> traditionally, literals are terms, but not identifiers.

14:51:20 <DanC_jam> i.e. in the logic literature

14:51:28 <tim-away> I think I use Symbol(uri) and Literal(str) and BNode(scope) and Universal(scope, id) and Existential(scope, id))

14:51:45 <eikeon> tim-away: Yeah... the generators instead of lists is performance motivated... used to use a visitor pattern.

14:51:56 <DanC_jam> (well, logic-lit:literal is something else altogether... an atom, P(X), or a negated atom, not(P(x)) )

14:52:34 <eikeon> Are Identifiers then Terms?

14:52:43 <DanC_jam> hmm... I don't see merit in a BNode class; just use fmla.bNode('hint-at-name')

14:53:04 <DanC_jam> yes, Identifers are Terms

14:53:12 <tim-away> I found that I was copying lists in the caller, when they might cchange during processing, and this didn't work when I switched to a generator.

14:53:16 <DanC_jam> i.e. not an exposed BNode class

14:54:16 <eikeon> tim-away: Can create a list from a generator with list(aGenerator) when a list is needed.

14:54:58 <tim-away> Sorry - thsoe were factory methods on the sink. They return various clases -- up to the strore really...fior example mI have a new Anonymous class for tings whose id is arbitrary, and need to make a Variable class.

14:55:14 <tim-away> tim-away is now known as tim_lap

14:55:16 * DanC_jam is kinda jazzed to be doing actual software engineering, with regression tests and unit tests, and explicitly documented APIs.

14:55:34 <tim_lap> aaah.

14:56:09 * tim_lap is loth to meddle as bugs from corrupted lists are horrid!

14:56:26 <DanC_jam> I prefer Symbol() and Literal() to be their own class. The string 'abc' can and should be shared accross formulas, stores, etc.

14:57:07 <DanC_jam> symbols too. You can do some cool stuff with namespace in python, ala: RDF['type'] or even RDF.type

14:57:26 * DanC_jam likes the RDF.type idiom, ack AaronSw

14:57:28 <tim_lap> DanC: re pydoc -- Should I generate all the HTML files, then for the web, in Makefile at the top level?

14:57:54 <DanC_jam> all HTML: I think so. I think i'd prefer they went in a differen directory, though.

14:58:04 * DanC_jam noodles...

14:58:11 <tim_lap> When you do cool stuff, then you need at some point an object for a subject *in the context of a given formula*.

14:58:22 <DanC_jam> why?

14:58:26 <tim_lap> Then, you can say joe.color or joe[color]

14:58:50 * eikeon started with RDF.type but changed my mind as to not clash with methods etc (as . is already spoken for and [] was not)

14:58:52 <tim_lap> If joe is just an interned symbol, then these don't have a context in which the question is being asked.

14:59:07 <danbri> yes, that's the point I keep going round and round on

14:59:23 * tim_lap understands eickon's thoughts about . and [] and shared them though "." is still very tempting!

14:59:26 <DanC_jam> hmm... Aaron wrote some code that did that (joe.color) recently... he chumped it; I haven't reviewed it. I'm still mulling it over. It smells like use/mention bugs to me.

14:59:31 <danbri> for rdf adoption, simplicity etc., saying joe.colour (or joe.c_color) is very useful

15:00:00 <tim_lap> So suppose subjects() returns a list of such objects.

15:00:05 <tim_lap> s/list/generator/

15:00:26 <DanC_jam> re RDF.type: the Namespace() class I use has a sym() method, ala: RDF.sym('type'), for the case of reserved words. I suppose RDF['type'] is as good as RDF.sym('type')

15:00:48 <tim_lap> for person in F.subjects(pred=friend, obj=me): print F.name

15:00:54 * eikeon would probably switch to using + or += before .

15:01:08 * DanC_jam smells more use-mention bugs.

15:01:13 <eikeon> lol

15:01:15 <DanC_jam> is subjects() terms or resources?

15:01:27 <eikeon> terms.

15:01:43 * eikeon is about to add resource objects... have not done so yet.

15:01:47 * tim_lap sorry, for person in F.subjects(pred=friend, obj=me): print person.name

15:02:02 * DanC_jam wonders why resource objects come up

15:02:25 * tim_lap doesn't know what a resource object is

15:02:35 <danbri> a resource object being a term in the context of some datasource?

15:02:39 <DanC_jam> if subjects() returns terms, then timbl's person.name stuff is a use/mention bug.

15:03:52 * tim_lap sighs

15:04:11 <tim_lap> Okl, explain why to use that syntax for a query on the store is a use/mention bug

15:04:24 <DanC_jam> person.name is 'person'

15:04:27 <DanC_jam> if person is a term

15:05:07 <tim_lap> You are telling me what "name" means. But it is just a software iodentifier, here it represents the contact:name term.

15:05:35 <DanC_jam> yes, but the term doesn't have a contact:name; the domain of contact:name is Person, and person is a term, not a Person.

15:05:53 <tim_lap> nam = F.Symbol("http://www.w3.org/2000/10/swap/pim/contact#firstName")

15:06:09 * DanC_jam prefers s/F.//

15:06:53 <tim_lap> But I want to search F for any occurrences of the triple with p name x and I had a nice python shorthand fro it.

15:07:32 <DanC_jam> I think you had a very, very confusing python shorthand for it

15:07:33 * tim_lap can handle nam=llyn.Symbol(...)

15:07:34 <eikeon> danbri: a resource object as I am thinking is what one needs to find all the p, o's of a given resource etc -- as a resource might have a number of subject URIRefs as is the case in foaf (with the folding etc)

15:08:17 <DanC_jam> eikon's resource objects sound like timbl's shorthand

15:08:23 <eikeon> So querying the store for all the p, o's of a given subject is not as useful.

15:08:42 <tim_lap> I think that you will find that python code is full objects with fields which are called "name" but are really the string representing the name.

15:09:22 <tim_lap> eikeon, its easy for you with only one formula in the system.

15:09:29 <DanC_jam> yes, OO code is rife with use/mention bugs. People learn RDF via these APIs, and I don't want them to get more confused.

15:09:43 <tim_lap> for me, i have to ghenerate such a resource object for the context of a given formula.

15:09:58 <tim_lap> actually, you have >1 "store" so you have to do it with resepct to the store.

15:10:28 <tim_lap> hey -- could I make a stoew and use it as an item in a triple in another store?

15:10:35 <DanC_jam> how about an analog to subjects(): subjectResources().

15:10:58 <tim_lap> DanC, you'll never return the resources. Only python objects.

15:11:02 <DanC_jam> umm... in rdflib, I don't think stores are nodes/terms

15:11:22 <tim_lap> No , not yet ;-)

15:12:18 * tim_lap wonders whether eikon could call his "store" "formula"

15:12:43 * eikeon needs to take closer look at cwm so that I am more familar with terms.

15:12:50 <DanC_jam> re store/formula: the WG calls them graphs, btw.

15:12:51 * Seth wonders if eikon could call his "store" "context"

15:13:27 <dajobe> no!

15:13:31 <eikeon> Yes, rdflib triple stores are a set of triples.

15:13:35 * DanC_jam notes that graph, like node, is ambiguous/confusing about whether it's a piece of syntax or stuff in the domain of discourse

15:13:41 <tim_lap> A formula is just a store at heart. Variables apart.

15:14:11 <DanC_jam> er... subjectProxies()?

15:14:54 * tim_lap repeats ... 'context' is a relationship, "Formula" is a class.

15:15:18 <DanC_jam> anyway... as long as subjects() returns terms, person.name doesn't work, for me. Terms can be shared across formulas, but person.name is likely to have different results in different formulas.

15:15:24 <tim_lap> DanC, in what way in the code is a subjectProxy different from a subject?

15:15:55 <tim_lap> (I contend it isn't at all, until you introduce daml:equivalent.)

15:15:55 <Seth> DanC, if the system is modeling a domain of resource (and just to the extent that it does model the domain of discourse) there is a one to one correspondance between nodes and things in the domain .. since the system cannot actually ~see~ the domain of discourse, then it does not matter at all.

15:16:19 <Seth> domain or resource = domain of discourse

15:16:34 <DanC_jam> "introduce"? daml:equivalent is there, whether you "introduce" it or not

15:16:48 <tim_lap> Not in cwm.

15:16:53 <DanC_jam> yes, in cwm.

15:16:58 <tim_lap> Only in axioms one feeds cwm.

15:17:01 <DanC_jam> nope.

15:17:08 <tim_lap> how so?

15:17:27 <tim_lap> cwm only knows terms.

15:17:37 <tim_lap> rdflib only knows terms.

15:18:11 <DanC_jam> no, it knows that from { :Bob :brother :tim } it can deduce { :Bob :bother _:somebody }. i.e. it knows that terms denote things.

15:18:18 <tim_lap> Where is the code which understands "=" (apart from as a shorthand symbol)?

15:18:59 <DanC_jam> the code is in query/match

15:19:39 <tim_lap> That is all it does - a match. "somebody" is a wildcard. The fact that the graph match has wildcards in doesn't mean cwm understands anything.

15:19:42 <DanC_jam> it knows that { :Bob :brother ?somebody } matches { :Bob :brother :tim }. i.e. it groks (a form of unification); i.e. it knows that terms denote things.

15:19:52 <DanC_jam> it does to me.

15:20:25 <tim_lap> Well, ho to te programmer does Resource(F, joe) differ from Term(F, joe)?

15:20:32 <tim_lap> s/ho/how

15:21:02 <eikeon> Resource can do the folding... can have more than one subject.

15:21:03 <DanC_jam> well, Term(F, joe) is redundant. Term(joe) is enough.

15:21:53 <tim_lap> You can say that to you these things have a semantic interpretation,. but as Seth says, at tyhis level there is a 1:1 mapping the operations you think of as semantic on resources are 1;1 with the syntactic matching of the search underneath.

15:21:54 <Seth> in sailor, joe is a node, not just some string like "joe"

15:22:06 <DanC_jam> the point is that the term 1 or <foo> is the same term across lots of formulas. (it happens that what 1 denotes is the same across formulas, but that doesn't generalize to all terms). what <foo> denotes may vary from formula to formula.

15:22:49 * DanC_jam gives up, suggests timbl read the RDF model theory spec or something.

15:23:28 <tim_lap> The thing I was talking about represnets the knowledge that a formula F has about a subject symbol(joe)..

15:23:29 * Seth giggels .. suggests timbl ignore RDF model theory

15:24:11 <tim_lap> How can the python code ever know what joe denotes in F?

15:24:19 <DanC_jam> knowlege: very well. but that's different from what subjects() returns, if it returns terms.

15:24:43 <DanC_jam> py code: it doesn't.

15:24:45 * eikeon sees a layering thing... store.subjects that returns resource is higher level than one that returns terms.

15:25:28 * DanC_jam is really tired of ridding the world of use/mention bugs (e.g. in topicmaps/RDF nocturn last night), wishes timbl would join his side.

15:25:42 <eikeon> Hopefully can hide store.subjects that returns terms at a low level and mostly deal with resource.

15:25:47 <tim_lap> What the customer wanted, the proverbial tyre swing, is to be able to write "print joe.name, joe.color, joe.shoesize". That is what danbri points out will make rdf usable to a lot of folks. It matches the syntax of OO work.

15:26:08 <DanC_jam> ok, you can have that. just don't call them terms.

15:26:25 <DanC_jam> i.e. don't tell me that subjects() returns terms and then use them ala joe.color

15:26:45 <DanC_jam> but *do* give me a method that returns terms

15:27:01 <DanC_jam> and be *sure* that your query method takes terms.

15:27:07 * tim_lap agrees use/mention bugs in languages and langauge specs a bad thing but doesn't think that python objects are restricted to a particular place in the layer structured .. indeed sofwtare objects can be whatever youu wnat them to be.

15:27:39 <Seth> at(joe) ve(color) vance say

15:27:51 <tim_lap> No, no one called this thing a term AFAIK.

15:28:04 * DanC_jam is lost... which thing?

15:28:06 * danbri calls it a Node, for better or worse

15:28:15 * DanC_jam wishes danbri would stop

15:28:36 * DanC_jam wishes danbri had seen the damage the word 'node' caused in the RDF/topicmap nocturn last night

15:29:04 <danbri> DanC, you looked over my code ~december and nodded approvingly at 'node' and 'graph'

15:29:22 <DanC_jam> perhaps I did.

15:29:41 <danbri> I need a word for artificat that stands in for something, and that umbrellas over 'term' (for urirefs) and bNode thingumies

15:29:44 <danbri> s/need/want/

15:29:46 <tim_lap> Hmmm. We could callit object. It is a clased world set of data.

15:30:05 <DanC_jam> 'term' umbellas over bNodes

15:30:28 <DanC_jam> calling it object is consistent with logic literature, in a way. it classes with rdf:object, but perhaps that can be managed.

15:30:33 <DanC_jam> clashes

15:30:38 <tim_lap> It nicely bridges the gap betwen semweb and oo by pointing out that if you take a semweb term and put it into the closed world of a given formula, it has all the properties of an object.

15:30:45 <Seth> node is what is inside the computer, thing\resource is what is outside the computer .. if the system is modeling then those are 1 to 1

15:31:06 <tim_lap> The overloading of "object" is just a pain!

15:31:30 <tim_lap> I keep them so separate in my mind I forget they have the same spelling.

15:31:34 * eikeon thinks he got node from the MT doc... as I tried to follow it as closely as possible when creating rdflib objects -- is there a new version of the doc in the works we can check?

15:32:18 <sbp> "There are three kinds of node in any RDF graph: urirefs, literals, and blank nodes." - 0.2 http://www.w3.org/TR/rdf-mt/

15:32:23 <DanC_jam> for person in F.subjectObjects(pred=friend, obj=me): print person.name # subjectObjects is pretty goofy

15:32:45 <Seth> sbp, a uriref is not a seth:node !

15:32:50 <DanC_jam> well, if the world agrees that nodes are terms, not resources, perhaps we can manage.

15:33:13 * dajobe has been using f.sources(pred, obj) f.targets(subj, pred) and f.arcs(subj, obj)

15:33:18 <sbp> difficult to poll the world effectively...

15:33:22 <Seth> DanC, terms are not seth:nodes !

15:33:32 <tim_lap> Hmmm maybe every python object should be thought of in these terms. The problem is that the method call doesn't take an object as its param, only some little string.

15:33:38 <DanC_jam> arcs... does that return predicates? or reified statements?

15:33:47 <tim_lap> goofy?

15:34:09 <DanC_jam> subjectObjects is just not an aesthetically pleasing name

15:34:31 <tim_lap> You said it not me! :)

15:34:42 <Seth> seth:nodes are python lists

15:34:46 <dajobe> arcs: predicates

15:35:01 <tim_lap> maybe just thatWhichHas(pred=..., obj=)

15:35:04 <dajobe> (list of matching predicates)

15:35:13 <DanC_jam> thatWhich... yeah, that has a ring to it

15:36:06 <DanC_jam> er... pred=friend... is friend a term or an object?

15:36:19 <tim_lap> term.

15:36:23 <DanC_jam> ok

15:36:44 <DanC_jam> now... pls document that in a python docstring when/if you code it up.

15:37:00 <tim_lap> It might be very practical iff confusingto be able to use an object as a term, as it it has a unique base term from which it is coined.

15:37:08 * DanC_jam made some code-review comments in doc/cwm.html ; wonders if he checked them in...

15:37:32 <tim_lap> pydoc is new to me... does it pick up docstrings from classes and methods?

15:37:32 <DanC_jam> yes; meanwhile, using a term as an object makes for ambiguity.

15:37:39 <DanC_jam> pydoc:yes

15:37:55 * DanC_jam noodles: pydoc --rdfschema cwm_string

15:37:57 <tim_lap> You can't use a term as an object.

15:38:06 <DanC_jam> agreed. whew!

15:38:26 * tim_lap thinks of ways to break that

15:38:27 * eikeon is off to add a Resource(term) to rdflib... or at least noodle over it for a bit ;)

15:39:21 <tim_lap> I think as eikon syas you have to use [] instead of "." becasue (a) "." is kinda useful and might get clashes and (b) you want to pass it a Term not a python identifier.

15:39:33 <DanC_jam> back to where I started: so RDF parsers, when encountering literals, should call a function that returns an interned term, agreed?

15:39:39 <Seth> well actually you can use a term as an object, but not inside the python code. Externally in the html page i can say at(joe) but that same code written in python would be at('joe')

15:40:00 <tim_lap> danc: agreed

15:40:09 * DanC_jam should perhaps check in what progress he's made on typed literals in rdfn3.g

15:40:32 <tim_lap> ACTION timbl: Make a default store and make it easy to use.

15:40:46 <tim_lap> ACTION timbl: Make a these Object things.

15:41:22 <eikeon> DanC_jam: Think that should be up to the application using the parser. no? Can just create objects and call an add method or something... and application can intern if it likes... or does this not work.

15:41:53 <tim_lap> application using the parser? the parser is passes a sink.

15:42:07 <tim_lap> The sink returns internal representations.

15:42:13 <tim_lap> These are sink-dependent.

15:42:32 <DanC_jam> sigh. and I thought we went over this.

15:42:34 <tim_lap> Eg some sinks at the moment -- all in fact return pairs (tpe, value)

15:43:00 <DanC_jam> I'm suggesting a change in design.

15:43:14 <tim_lap> You don't think we willregret it?

15:43:18 <DanC_jam> I sugges that terms are not sink-dependent

15:43:39 <DanC_jam> regret: I dunno; but I thought I had convinced you.

15:43:52 <jang> yes

15:43:58 <jang> oops, wrong window

15:44:06 <tim_lap> You had convinced me to have a global process-wide defualt stroe.

15:44:08 <tim_lap> You had convinced me to have a global process-wide defualt strore.

15:44:24 <DanC_jam> phpht. that's not what I meant to convince you of.

15:44:32 <DanC_jam> I meant to convince you that terms are store-independent.

15:44:39 <tim_lap> But will there be any way for eikeon's store and mine to coexsit in a process?

15:44:52 <DanC_jam> i.e. we only need one python object for the term "abc" or the term 12.

15:44:58 * Seth wonders what a dan:term is

15:45:29 <DanC_jam> my proposal is to eikon and timbl. if they agree that terms are interned, they can co-exist.

15:45:31 <tim_lap> I suppose if we are trying to stnadrdize this and build it int the python runtime, then ok.

15:45:57 <DanC_jam> python runtime: exactly. I'm looking at integrating RDF typed literals with the python runtime. that's how I got here.

15:45:57 * tim_lap will have to look at what he strores on the literal.

15:46:14 <tim_lap> oh, ok.... I can go there.

15:46:22 <eikeon> I am happy with interning terms... just need to implement the interning.

15:47:09 <eikeon> DanC_jam: Cool! re: python runtime

15:47:16 <tim_lap> So what bits don't you like about thing.py -- apart from that?

15:47:41 <DanC_jam> well, I didn't like the fact that the progress() and verbosity() stuff was in there, so I factored that out.

15:47:48 * tim_lap notes thing will have to calll llyn, so import llyn.

15:48:03 <tim_lap> Thanks - that factoring out was good.

15:48:25 * DanC_jam has forgotten what he doesn't like about thing

15:48:30 * tim_lap notes thing will have to calll llyn, so import llyn. Not good. Else llyn registers when imported as a store with thing.

15:48:32 <jang> hang on!

15:48:36 <jang> interning terms:

15:48:46 <DanC_jam> I'm pretty sure I didn't like the fact that I couldn't tell what thing was all about... esp. not from pydoc's view.

15:48:50 <jang> you said that "term" sat over "bnode"

15:49:04 <DanC_jam> um... good point..

15:49:10 <jang> interning bnodes between separate stores isn't always what you want to do

15:49:18 <jang> only sometimes

15:49:19 <DanC_jam> term sits over bnode, but only literal terms are interned.

15:49:22 <tim_lap> Ok, add doc.. doing.

15:49:39 <DanC_jam> I probably saw some use/mention oddities in thing.py

15:49:39 <jang> what I've done is a bonde that carries store-specific identity for its lifetime...

15:49:48 <tim_lap> I think I will have llyn register itself with thing so that thing does not have to know about llyn.

15:49:49 <jang> ... but the lifetimes of those bnodes is generally short

15:50:01 <jang> (a query, effectively)

15:50:11 * tim_lap notes gentelmen prefer bondes.

15:50:17 <DanC_jam> yes, bnodes are local to formulas/stores/whatever

15:50:31 <jang> however, I want this to work:

15:50:53 <jang> for triple in (store1.fetch(*,*,*))

15:50:58 <jang> store2.assert(triple)

15:51:03 <tim_lap> By store, do you mean formula stroe or triple store?

15:51:26 * DanC_jam didn't care when he said it

15:51:29 <tim_lap> That works for me with 2 formuale in the same global invisible store

15:51:41 <eikeon> jang: Probably best to create new bNode in that case. no?

15:51:49 <jang> nope

15:51:57 <jang> well, I don't think so anyway

15:52:06 <jang> if store1 contains

15:52:12 <tim_lap> You have to craeet a new bnode.

15:52:12 <jang> _:a <foo> 1 .

15:52:18 <jang> and _:a <foo> 2 .

15:52:18 <DanC_jam>http://www.w3.org/2000/10/swap/test/dt/typedLit.n3

15:52:18 <dc_rdfig> B: http://www.w3.org/2000/10/swap/test/dt/typedLit.n3 from DanC_jam

15:52:23 <tim_lap> The wne one is quantified in the scope fo the new store.

15:52:29 <jang> then I want store 2 to wind up with 1, not two, bnodes

15:52:37 <DanC_jam> B:typedLit.n3 -- playground for typed literal syntax in N3/n-triples

15:52:37 <dc_rdfig> Added comment B1.

15:52:51 <jang> what I do is this:

15:53:02 <jang> when I get a bnode out of a query...

15:53:05 <DanC_jam> B:|typedLit.n3 -- playground for typed literal syntax in N3/n-triples

15:53:05 <dc_rdfig> Titled item B.

15:53:08 <DanC_jam> B1:""

15:53:08 <dc_rdfig> Deleted comment B1.

15:53:12 <jang> .. it carries a "store1" identity with it

15:53:29 <jang> when I insert that into store2, it gets a store2 identity as well

15:53:40 <jang> now, the query carries a "cache" of the bnodes it's produced

15:53:53 <jang> so there's query-specific interning of bnodes, effectively

15:54:08 <jang> ie, the next time I get that bnode from that query, it carries a store1 and a store2 identity

15:54:28 <jang> however, the marriage between those two only lasts for the lifetime of the query in my default implementation

15:54:41 <jang> because I wanted it to work analogously to fetching rdf over the net

15:54:57 <jang> actually, there's a little more to it

15:55:11 <jang> because when a query is created using bnodes, those bnodes are seeded into the query cache

15:55:16 <jang> but that's basically the idea.

15:55:43 <bijan> It seems that Edsger W. Dijkstra is dead.

15:55:48 <jang> so you get a nice semantics in the programming language: as long as you've got a handle onto the bnode object, you've got a handle onto the identities you've given it in various stores

15:55:52 <jang> bloody hell

15:56:02 <jang> that's a shame

15:56:18 <bijan> Yes.

15:57:01 <sandro> link to news story?

15:57:02 <DanC_jam> B:when starting to implement this, I made some [code review notes|http://www.w3.org/2000/10/swap/doc/cwm#QA]

15:57:02 <dc_rdfig> Added comment B1.

15:57:08 <bijan> Not in news yet, afaict.

15:58:53 <bijan> Date: 07 Aug 2002 15:46:14 +0000

15:58:53 <bijan> From: Erik Naggum <erik@naggum.no>

15:58:53 <bijan> Newsgroups: comp.lang.lisp

15:58:53 <bijan> Subject: Edsger W. Dijkstra

15:58:53 <bijan> This just arrived, much to my shock and sorrow:

15:58:54 <bijan> From: "Edsger W. Dijkstra" <ewdkstra@xs4all.nl>

15:58:56 <bijan> Subject: from the family

15:58:58 <bijan> Cc: faculty@cs.utexas.edu

15:59:00 <bijan> Grateful for most that has befallen him, has peacefully passed away,

15:59:02 <bijan> Edsger Wybe Dijkstra,

15:59:06 <bijan> our husband and father.

15:59:08 <bijan> We hold him very dear.

15:59:10 <bijan> I'm looking for more public confirmation.

15:59:21 <bijan> er...more official confirmation

16:01:30 <sandro> He's still listed on http://www.cs.utexas.edu/home/people/prof_np.shtml but I guess that's not surprising.

16:02:01 <bijan> Yep.

16:02:11 <bijan> He must have died today or late yesterday.

16:02:15 <bijan> Cremation on sat

16:02:25 * DanC_jam didn't realize there was a connection between Naggum and Dijkstra

16:03:20 <DanC_jam> B:some implementation support in [rdfn3.g|http://www.w3.org/2000/10/swap/rdfn3.g] and [KIFSink.py|http://www.w3.org/2000/10/swap/KIFSink.py]

16:03:20 <dc_rdfig> Added comment B2.

16:03:44 <DanC_jam> tim, I'd really like your opinion on syntax for typed literals in N3. can you take a look at B:?

16:04:29 <dajobe> are those all the XSD names?

16:05:09 * tim_lap is not happy about typed literals really.

16:05:10 <Seth>http://nutria.cs.tu-berlin.de/roodolf/index.html

16:05:10 <dc_rdfig> C: http://nutria.cs.tu-berlin.de/roodolf/index.html from Seth

16:05:16 <DanC_jam> yes, but note the comments around NOTATION and such

16:05:26 <dajobe> sure

16:05:39 <Seth> C:|RooDolF allows you to query the Google search engine via the Google Api and have your results returned in standard RDF format.

16:05:39 <dc_rdfig> Titled item C.

16:05:44 <DanC_jam> you don't eventually want date literals in N3, timbl?

16:06:09 <DanC_jam> C:what vocab did you use?

16:06:09 <dc_rdfig> Added comment C1.

16:06:15 <tim_lap> Rats. resource(store, uri). Will move to Symbol(uri, store=None)

16:06:42 <tim_lap> I want date and numeric literals in N3 eventuyally.

16:07:00 * dajobe wonders about revisiting the ntriples "foo"-en stuff now

16:07:06 <tim_lap> I don't like the current state in which you have untyped literals which are not just strings but sort of ambiguous things.

16:07:09 <dajobe> i.e. replacing '-' with something

16:07:19 <DanC_jam> ambiguous things?

16:07:26 <DanC_jam> the type defaults to string, no?

16:07:31 <tim_lap> I don't like "foo"-en and I don't like xml"foo".

16:08:01 <tim_lap> I think the whole darn lot should be parsed into [ lang:en "foo"]

16:08:13 <tim_lap> and [ xml:xml "foo" ]

16:08:15 <tim_lap> etc

16:08:15 <dajobe> we can do that and break all previous uses of xml:lang, sure

16:08:40 * DanC_jam really doesn't want to re-open "foo"-en today, pls

16:08:46 <tim_lap> No, we just have two normal forms, one with complex literals and one without, and a mapping bnetween them.

16:08:46 <dajobe> ok

16:09:18 <tim_lap> So long as the mapping is 1:1 then it should be ok.

16:09:19 <Seth> C: sailor screen shot of [http://robustai.net/sailor/screenshots/RoodolfSearch_of_Seth_Russell.html|a Rudolph retrieval of seth russell from google]

16:09:19 <dc_rdfig> Added comment C2.

16:09:31 <jang> the major reason I'm interested in "foo"-en, which is frankly an abortion...

16:09:41 <jang> ... is because it kept a foot in the door for typed literals

16:09:49 <jang> that is, not just brain-dead "everything's a string"

16:10:01 <DanC_jam> timbl, right now, I implemented date"2001-12-23".

16:10:03 <jang> because everything plainly isn't

16:10:40 <tim_lap> Well, I'm much happier with python (for example)'s notion of what is an atomictype than with RDF's current. But fortunately i can mapo betwen them.

16:11:07 <tim_lap> You mean xsd:date"2000-12-23" ?

16:11:14 * DanC_jam would really like timbl's opinion on the syntax used in http://www.w3.org/2000/10/swap/test/dt/typedLit.n3

16:11:22 <DanC_jam> no, just date"2000-12-23".

16:11:25 <DanC_jam> it's not extensible.

16:11:39 <tim_lap> ugh. Leave me with strings in that case.

16:11:52 * DanC_jam repeats:

16:11:57 <tim_lap> There willbe billins of interesting things to encode in strings.

16:11:58 <DanC_jam> you don't eventually want date and integer literals?

16:12:22 <tim_lap> date, no. Arithmetic not defined. No point.

16:12:27 <tim_lap> integer, yes.

16:12:39 * sandro is distracted by an excellent collection of programmer's quotes: http://www.vanderburg.org/soft-quotes.html (LOL quote from jwz: "To a database person, every nail looks like a thumb. Or something

16:12:39 <sandro> like that.")

16:12:55 <tim_lap> :-))

16:13:03 <DanC_jam> the question is wehter { :x :p date"2001-12-23". :y :q date"2001-12-23" } log:includes { :x :p _:something. :y :q _:something }. that doesn't hold/follow for [ xsd:date "2000-12-23"].

16:13:40 <DanC_jam> "I want date and numeric literals in N3 eventuyally." -- timbl, 11:06:42

16:14:04 <tim_lap> I retract that. I chanegd my mind.

16:14:27 <DanC_jam> do you want the x/p/y/q case to work?

16:14:30 <tim_lap> I want integer and complex and real literals eventually.

16:15:51 <tim_lap> In actually daling with dates, we seem to have done OK dealing with them as strings.

16:16:52 <tim_lap> To actually process tehm, you have to turn them into numbers.

16:17:14 <jang> actually, dates are one of the oddities

16:17:20 <tim_lap> You typically ahve to make a lot of assumptyions on teh way, becasue the strings liek yors above don't have timezone info etc.

16:17:31 <jang> I've long said that literals ought to be "self-denoting" but that's quite hard for a locus in time

16:19:02 <DanC_jam> doing numbers without doing the rest of XML schema datatypes is sorta politically incorrect, but I might be able to defend it. hmm.

16:19:03 <tim_lap> Another question is wehter { :x :r "2001-12-23". :y :q "2001-12-23" } log:includes { :x :p [time:inSeconds _:s]. :y :q [time:inSeconds _:s] }.

16:19:13 <tim_lap> That question works.

16:19:50 <tim_lap> I think that theire was enough debate over the date stuff that to declare it a rathole is fair.

16:20:41 <DanC_jam> dealing with dates as strings works in a lot of ways, but I do have code that knows that [ dt:date "2001-10-12"] cyc:before [ dt:date "2001-11-12"].

16:21:18 <DanC_jam> locus in time: good point.

16:22:08 <tim_lap> And code that knows that [ is timeInseconds of "2001-10-12Z"] math:lessThan [ is time:inSeconds of "2001-11-12Z"]

16:23:10 <DanC_jam> ok... so just strings and numbers. I think I can sign up for that...

16:23:19 <DanC_jam> ... a few questions about numbers?

16:23:30 * tim_lap btw ... thing.()Symbol ok instead of thing.Resource?

16:23:35 <DanC_jam> i.e. integers only? arbitrary precision?

16:24:15 <DanC_jam> er... thing.Symbol(), yes. Do make a Namespace class, too, while you're at it, pls. alal RDF['type']

16:24:31 <DanC_jam> numbers: floating point?

16:24:32 <tim_lap> Umm... this is wading into a big area. I would like a system in which no limitations were introduced which were not introduced by the math.

16:24:47 <tim_lap> numbers: the works!

16:25:07 <tim_lap> What is the delta between python and xsd?

16:25:14 <DanC_jam> numbers: does { :s :p 1.0 } log:includes { :s :p 1 } ?

16:25:39 <tim_lap> No, because 1.0 cannot be shown top be equal to 1

16:25:41 <DanC_jam> xsd has arbitrary precision decimals; python has arbitrary precision integers

16:26:02 <jang> one answer is yes, but implementations may fail to realise it

16:26:08 <DanC_jam> xsd has float and double with specified precision. python has float with implementation-dependent precision

16:26:31 <jang> 1.0 not being the same as 1 isn't a mathematically-introduced limitation

16:26:32 <DanC_jam> log:includes is something with specified interoperability expectations, jang.

16:26:47 <tim_lap> Depends on whether "1.0" means "something between 1.05 and 1.15" or "10/10".

16:27:04 <eikeon> Is Symbol and Resource synonymous then?

16:27:20 <DanC_jam> in xsd, the decimal 1.0 is equal to the integer/decimal 1, but the floating point 1.0 is not equal to the integer/decimal 1. floating point numbers are inexact.

16:27:30 <tim_lap> I think Dan would prefer me to change Resource to SYmbol to avoid use-mention confusion.

16:27:37 * DanC_jam nods

16:27:39 <tim_lap> Also probably Thing to term

16:27:47 <DanC_jam> ooh! please?

16:27:52 <deltab> some floats are inexact

16:27:58 <deltab> 1.0 isn't :-)

16:28:08 <jang> floating point numbers are perfectly exact; it's just that +-*/ don't mean what you think they mean when used on them :-)

16:28:19 <DanC_jam> 1.0 is inexact. it's an open interval around 1. floating point addition isn't associative.

16:28:36 <jang> or:

16:28:42 <tim_lap> (In xml datatypes use of the string "1.0")

16:28:42 <deltab> ah, I see what you mean

16:28:52 <jang> 1.0 is exact. floating-point addition isn't quite what we think of as mathematical addition

16:29:25 <DanC_jam> jang, you're just WRONG! ;-). there are differnt ways of looking at it, yes.

16:29:38 <Talliesin> IIRC 1.0 is exact, however it may have been produced from an expression to which the mathematically exact answer is not exactly 1.0

16:29:42 <jang> heh, I feel like the universe is back to rights now

16:29:48 <jang> danc and I disagree :-)

16:30:34 * DanC_jam can see a zillion test cases between us and a complete design for numeric literals in RDF

16:30:46 <tim_lap> test case; If I say x=3.141592653, if x == 3.141592653 print "Jang's right" XSD implementations may not agree with jang, withoyt any + - involved.

16:31:18 <jang> in which case they're broken

16:31:36 <DanC_jam> in xsd, float 1.0 and decimal 1.0 aren't comparable. i.e. the spec doesn't say whether they're equal or not.

16:31:42 <jang> because the same token has been parsed as different values for that to be the case

16:32:08 <Talliesin> Well the Spec leaves the degree of precission used by the implementation up to the implementation.

16:32:12 <jang> actually, I'm more of the opinion that the types of number we introduce as rdf literals ought to follow an int/real distinction

16:32:43 <jang> purely from a pragmatic "i've heard DB and query people grumble about this " point of view

16:32:45 <DanC_jam> no, Talliesin, xsd has min/max constraints, and implementations have to know about floating point comparison to a specified precision.

16:33:12 <DanC_jam> jang, by "real" do you mean floating point?

16:34:03 <DanC_jam> numbers: does { :s :p 1.0 } log:includes { :s :p 1 } ? I'm happy with a 'no' answer.

16:34:24 <Talliesin> DanC_jam, where is that position specified?

16:34:31 <Talliesin> oh wait

16:34:34 <Talliesin> my apologies

16:34:39 <sandro> Working in python, I'm missing strong typing. I like knowing the types of arguments to a procedure. Is there some idiom I should be using? (I have Logical Formula in like 4 different forms -- how do I keep them straight?)

16:35:00 <Talliesin> Confused it with decimal

16:35:01 <jang> yeah, that is: I'd rather see floating-point than real as a literal type

16:35:10 <DanC_jam> arg typing gets kicked around in comp.lang.pythong every once in a while... there are static typing projects.

16:35:14 <deltab> sandro: I believe you mean static typing

16:35:52 <jang> I'd also rather see "real numbers" as literal types, but I'm semi-convinced these days that the lack of ability to actually implement them means there's not much point

16:36:08 * DanC_jam would hope that static typing is in a python FAQ somewhere

16:36:17 <Talliesin> Anyway are you saying that 1*power(2,0)!=1 ?

16:37:25 * DanC_jam isn't sure

16:38:20 <DanC_jam> python, I think maybe there's some reserved/ignored syntax for arg typing... and some ancillary tools that grok it... maybe pychecker groks it?

16:38:45 * DanC_jam thinks he's missing lunch...

16:38:48 <Talliesin> because if 1*power(2,0)==1 then 1.0 is precise.

16:39:13 * DanC_jam doesn't see how that follows

16:39:33 <Talliesin> Okay, we have a float

16:39:49 <sandro> deltab, is there a difference? Does strong typing mean something else to you? (google suggests they mean the same thing.)

16:39:52 <DanC_jam> I have never seen a programming language without warts in its numeric stuff. ML, perhaps the cleanest language design around, has major warts around numbers.

16:41:12 <Talliesin> Yep they all have warts.

16:41:12 <deltab> strong typing means that you must explicitly convert between types - strong typing systems wouldn't allow 1.0 in place of 1, or vice versa

16:41:54 <Talliesin> But does the wart result in an imprecise datatype or an imprecise calculation.

16:42:17 <DanC_jam> ?

16:42:43 * DanC_jam is reading up on type theory, where it's quite clear that types are all about calculation

16:43:28 * DanC_jam finds lots of stuff, via google, on "python static typing"

16:43:51 <Talliesin> I'm saying that with an IEEE float if you do something like power(10,10000000000)/(power(10,10000000000)-1) then while that calculation doesn't produce exactly 1.0 the 1.0 you have in the variable (or whatever) you use to store the result is exactly 1.0

16:44:34 <tim_lap> A very clever system would have an axiom that 1 pow(anyReal) == 1 and so could retun 1 instead of 1.0. This wouldprobably be rarely used and almost always coerced to 1.0 by the caller, but it would be cute.

16:44:51 <Talliesin> Which is not to say I therefore believe a language should allow it to be implicitly cast to the integer 1

16:46:27 <Talliesin> [ot] hmm. I wonder if there's any way of calculating x pow(y) which would exit on x=1 as a side-effect of the way it works.

16:46:28 <DanC_jam> python types sig is being retired: http://mail.python.org/pipermail/types-sig/2002-July/001384.html

16:48:25 <FUNDRAISING> [Global Notice] Hi, all. As you may know, OPN has been adopted by Peer-Directed Projects Center, a newly-created Texas nonprofit organization. We're two days into our initial fundraising drive. Please look at http://openprojects.net/contrib.shtml and help us get things going as quickly as we can.

16:48:36 <eikeon> sandro: Could add assert(isinstance(arg, Foo))'s to help some -- still would not catch at compile time but may help some.

16:48:46 <DanC_jam> Uche against static typing in python: http://mail.python.org/pipermail/types-sig/2001-March/001100.html

16:48:46 <FUNDRAISING> [Global Notice] The current total is $772.12. Thanks to everyone who's contributed so far, and thank you all for using OPN!

16:50:08 <FUNDRAISING> [Global Notice] Apologies, all. That URL should be http://openprojects.net/contributions.shtml ... Thanks.

16:50:57 * JibberJim agrees with Uche there. (well not as a python user, but as a user of a loosely typed lang.)

16:51:46 <sandro> hm, interesting debate. I probably mostly need a clearer naming convention, mostly, but some assert(isinstance(arg, Foo))'s are probably good, too.

16:52:04 * eikeon agrees to. Though I was going to miss static typing more than I have in my switch to python... as I have pretty much always done statically typed langs before Python.

16:52:53 * JibberJim doesn't think ECMAScript's Edition 4 proposals for mixed loose and strong typing too bad though.

16:55:45 <DanC_jam> timbl, see welty on semantics in webont: [[

16:55:48 <DanC_jam> 1b) Using OWL to change the syntax of OWL

16:55:49 <DanC_jam> I strongly agree with Ian's position here. It is well known that when

16:55:49 <DanC_jam> you use a logical system to *talk about itself* you are introducing

16:55:49 <DanC_jam> incompleteness.

16:55:49 <DanC_jam> ]]

16:56:26 <DanC_jam> ... [[ Unless you break processing into two discrete steps, the way

16:56:26 <DanC_jam> compilers/loaders do (i.e. compile time and run time) you are also

16:56:26 <DanC_jam> introducing a huge amount of machinery to support this. Machinery that no

16:56:26 <DanC_jam> one really knows how to build. ]]

16:57:38 <Seth> or more simply just use range constraints on properties to know whether you are talking about the map or the territory

16:57:47 <sandro> source link, DanC?

16:58:00 <DanC_jam> sorry, slow link

16:58:08 <DanC_jam> recent mail from welty to www-web-ont-wg

17:07:46 <sandro> Hmm, nice paper from Chris Welty defining Ontology: http://lists.w3.org/Archives/Public/www-webont-wg/2002Aug/0056.html

17:13:24 <Seth> C: another sailor screen shot [http://robustai.net/sailor/screenshots/RoodolfSearch_of_Dijkstra.html| only this one guesses the html and is more user friendly]

17:13:24 <dc_rdfig> Added comment C3.

17:28:36 * Seth is still wondering if TimBl will explain why he's trying to get rid of triples expressing quantification in n3

17:29:00 <MorbusIff> LIELO!

17:29:00 * lilo` looks in

17:29:34 <lilo`> hiya MorbusIff

17:29:40 <MorbusIff> how's life?

17:32:29 <lilo`> it's okay

17:32:51 <lilo`> we're just going through the throes of initial funding for the nonprofit 8)

17:33:12 * sbp waves

17:33:26 <sbp> where did our +P disappear to, lilo? :-)

17:33:32 <lilo`> it's an interesting process, and very slow, and I'm not sure it's germane 8)

17:34:16 <sbp> :-)

17:34:23 <sbp> congrats on the current total, BTW

17:34:26 * sbp has to run

17:35:33 <lilo`> heya sbp

17:35:58 <lilo`> let me fix it

17:36:10 <lilo`> it's an experimental feature

17:37:22 <lilo`> thanks!

17:37:27 <lilo`> we'll keep at it

17:37:59 <lilo> no bandits today that I can tell

17:38:10 <MorbusIff> [OLM]

17:38:12 * lilo` really needs time to coordinate some changes to the server code

17:38:34 <lilo`> which I guess is part of what the fundraising is about

17:38:48 <lilo> hmmm, that client is soooo lagged

17:39:16 <lilo`> oh, dear, now I see why this client is so horribly lagged

17:39:24 <lilo> indeed

17:41:18 <lilo`> better

17:42:00 <tim_lap> Hi lilo... KUTGW

17:42:07 <lilo`> tim, hey!

17:42:09 <tim_lap> ooops missed

17:42:09 <lilo`> KUTGW?

17:42:19 <tim_lap> Keep up the good work

17:42:24 <lilo`> oic, thanks :)

17:42:38 <lilo`> we're slowly getting the nonprofit up to steam

17:42:58 <tim_lap> looked for any foundation funding? could work out.

17:43:10 <lilo`> haven't had time to spend researching grants

17:43:23 <lilo`> that's sort of the catch-22 of starting up a nonprofit

17:43:40 <lilo`> we'll definitely be doing some grant research though

17:43:49 <tim_lap> You mean that grants come with more than "keep doing what you are doing"?

17:43:51 * DanC_jam reminds himeself to donate

17:44:00 <lilo`> tim_lap: yup :)

17:44:07 <lilo`> DanC: thanks

17:44:10 <tim_lap> Hmmm.. not all

17:44:19 <lilo`> tim_lap: really?

17:44:48 <lilo`> tim_lap: I have several understandings about grants, maybe they're not correct....I'd love to take a few minutes with you, if you can shed any light

17:44:51 <sandro> ... and the time & effort to find grantors, and get the grant, ... are non-trivial!

17:44:58 * lilo` nods at sandro....

17:45:07 <lilo`> that's my impression at this point

17:45:09 <sandro> (hey, lilo....)

17:45:15 <lilo`> (hi :)

17:45:44 <MorbusIff> MorbusIff is now known as Morbus

17:46:20 <lilo`> as matters stand I have to spend most of my time just keeping afloat

17:46:32 <lilo`> I think that'll change once we have a small operating budget

17:46:55 * DanC_jam wanders off...

17:47:02 <lilo`> but grants are not typically the way you get an operating budget together

17:47:13 <lilo`> they're usually targeted to specific projects

17:55:27 <mhgrove> mhgrove is now known as mike-demo

18:01:14 <lilo`> anyway, I have just been wandering the network a bit, with emphasis on developer-related channels

18:01:34 <lilo`> I don't figure developers have big bucks these days, but I figure you guys probably appreciate the network :)

18:01:34 <sandro> what else is there?

18:01:41 <lilo`> support channels

18:02:05 <lilo`> we have a fair number of them as well

18:02:56 <lilo`> anything you folks can think of that might help, let me know

18:03:10 <lilo`> I'm around and can be reached at lilo@openprojects.net as well

18:03:20 * lilo` wanders back to the fray :)

18:03:50 <sandro> who was that masked boot-loader? :-)

18:07:57 <tim_lap> Robert Levin, irc.openprojects.net ____________ <-- role?

18:08:21 <sandro> "Lead", I think. :-)

18:09:24 <tim_lap> Ok, I have a problem that I want Symbol(uri) to return a different sybclass depending on the uriref. This must be a common python problem.

18:09:33 <tim_lap> What do I do -- use just a function?

18:10:00 <deltab> yes

18:10:37 <tim_lap> Nothing like a direct answer. Thanks, I will use a function!

18:33:19 <eikeon> tim_lap: You can do it by overriding __new__ as well. Not sure what the pro/cons are... function should work fine ;)

18:41:27 <mnot> __new__ is, er.., new in 2.2, no?

18:41:38 * mnot assumes you're talking about Python

18:41:41 <deltab> yes

18:42:32 * mnot discoveres web.pydoc.org - oooohhh, ahhhhh

18:43:03 <eikeon> Yep __new__ was introduced in python 2.2

18:43:29 <bijan> Let's not forget the factory pattern: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/86900

18:45:23 <bijan> Hmm. or maybe we should :)

18:47:27 <tim_lap> I'm happy with functions right now.

18:48:53 <eikeon> Yep, I did not want to open a can of worms... just wanted to point out another choice to ponder on a rainy day.

18:49:08 * Seth reads w3c-rdfcore-wg and fears that the WG will never reach a consensus on datatyping :(

19:00:51 <olmy> everything is an object!

19:01:11 * Seth waves at olmy

19:01:54 * olmy waves back

19:02:13 <Seth> you must be using an old version of sailor

19:03:27 <olmy> oh

19:03:43 <olmy> where is the latest?

19:03:44 <Seth> new version has a read bar at the top for rdf files

19:03:55 <olmy> i'll check...

19:03:56 <Seth> .092 latest published

19:04:42 <Seth> but i havent changed the rdf parser since that .. only new changes in .o92m are for n3

19:05:11 <tim_lap> eikeon, the functions in http://www.w3.org/2000/10/swap/thing.html are my curent best fit with what DanC wanted,. for my forumla, read your store; for my store read your system.

19:05:46 <tim_lap> modulo tyops and speling

19:06:21 <eikeon> tim_lap: Cool... looking now.

19:06:55 <olmy> seth: is that with the read button?

19:06:56 <Seth> im not ready to publish the revised n3 parser cause tim hasn't justified lopping quantification triples yet ;-) ... just a friendly barb, no malice intended

19:07:05 <tim_lap> They are just a shim ... now I have to start fixing everything to use them!

19:07:34 <tim_lap> Seth, i can't think of anything more to say about quantification triples.

19:07:40 <Seth> yes, read button is like a hyperlink to a rdf file, but you can type the url of the file in at the top

19:09:08 <Seth> tim, well i answered you complaint about substitution of identicals in intensional contexts in a private email, and your complaint about monoticity in the cat yesterday, so imho lopping the triples is still not justified.

19:09:49 <danbri> TimBL, class Term defines asList(self)

19:09:50 <danbri> Boolean Is this a list? (override me!)

19:09:59 <danbri> ...do you mean isList(self) ?

19:11:14 <tim_lap> I meant asList -- I have an interning of lists, because lists are in fact another form of literal, something with a first and rest is interned so it can be compared with other lists for equality as a single opcode. This is hairy and I am glad i haven't touched it fro a while.

19:11:46 <tim_lap> So when you get it as a List, you get the List object.

19:12:15 <tim_lap> Normally if not aliost it returns None.

19:12:18 <danbri> maybe i'm reading the doc wrong, I read it as returning a Boolean, not a List.

19:12:27 <tim_lap> Ahh. true.

19:13:06 <danbri> good to have these docs, btw. What are they built with?

19:14:04 <tim_lap> ooops sorry.. fxiing.

19:14:12 <tim_lap> docs built with pydoc -w <modulename>

19:14:58 <danbri> BTW I'm just adding Cwm to http://www.w3.org/Status ...taking blurb from Cwm home page

19:16:10 <eikeon_> logger, pointer?

19:16:10 <eikeon_> See http://ilrt.org/discovery/chatlogs/rdfig/2002-08-07#T19-16-10

19:16:26 <tim_lap> Danbri, There is an embryonic table of conversions into and out of RDF in 2002/*/*swad-dataflow.html which might be a good link to there or even copy, paste and elaborate.

19:16:26 <olmy> seth: can you give me a sample url?

19:18:09 <eikeon_> Where are Universals defined... am looking for them in cvs land.

19:18:28 <eikeon_> eikeon_ is now known as eikeon

19:18:55 <SethR> olmy, read in http://robustai.net/sailor/semDocuments.quads and you get a whole directory of them :)

19:19:21 * danbri can't dereference URIs with regexes in them ;-)

19:19:42 <bijan> 404 -- file not grepped

19:19:49 <danbri> :)

19:19:57 * danbri doesn't have whoel site checked out

19:22:51 <danbri> done (w/ pending mirror updates), see http://www.w3.org/Status#cwm

19:24:26 * tim_lap updates the thing doc a bit.

19:28:24 <tim_lap> I think maybe I should go futher than just having a default store for formulae but also have a default wokingFormula which triples can go into and out of by default.

19:28:42 <tim_lap> Kinda closed world but maybe pragmatic

19:38:48 * eikeon is following suit by generating pydoc for rdflib: http://rdflib.net/latest/rdflib.html -- Any way to get pydoc to generate doc recursively... or do I need to list one module at a time.

19:39:06 <tim_lap> pydoc -?

19:39:47 <tim_lap> If yo feeed it a filename including a "/" *should* do the module in it, and if a directory all moduels within that.

19:40:02 <tim_lap> But I got an error with pydon -w ./cwm.py

19:40:15 <tim_lap> Try pydoc -w ./

19:40:53 * tim_lap has to prepare a talk.

19:41:07 <eikeon> Cool... pydoc -w ./ worked.

19:41:09 <eikeon> Thank you.

19:52:03 <SethR> olmy, if you want help with sailor, you should /join #sailor

19:54:26 <olmy> ok

19:57:06 <olmy> have to go. bye.

19:57:52 <eikeon> Hum... re: pydoc's data section -- Loses a bit of infomation... see: http://rdflib.net/latest/rdflib.const.html vs http://rdflib.net/latest/rdflib/

19:58:13 <eikeon> vs http://rdflib.net/latest/rdflib/const.py (got chopped)

20:33:15 <SethR>http://robustai.net/sailor/semDocuments.quads

20:33:15 <dc_rdfig> D: http://robustai.net/sailor/semDocuments.quads from SethR

20:33:27 <SethR> woops .. wrong one

20:34:04 <SethR>http://robustai.net/sailor/

20:34:04 <dc_rdfig> E: http://robustai.net/sailor/ from SethR

20:34:27 <SethR> E:| Version .092m of sailor agents

20:34:27 <dc_rdfig> Titled item E.

20:34:47 <SethR> E: can now read RDF and display it in user friendly manner

20:34:47 <dc_rdfig> Added comment E1.

20:35:05 <SethR> E: allows you to surf the semantic web ...

20:35:05 <dc_rdfig> Added comment E2.

20:35:50 <SethR> E: read in the directory at http://robustai.net/sailor/semDocuments.quads and click on the red ~read~> buttons

20:35:51 <dc_rdfig> Added comment E3.

20:36:27 <SethR> E: also works on N3 files, but you may not be satisfied with the lack of quantification triples

20:36:27 <dc_rdfig> Added comment E4.

20:43:21 <FUNDRAISING> [Global Notice] Good evening to everyone. As you may know, OPN has been adopted by Peer-Directed Projects Center, a newly-created Texas nonprofit organization. We're starting our third day of our initial fundraising drive. Please look at http://openprojects.net/contrib.shtml and help us get through it as quickly as we can. Your contribution will help.

20:44:05 <FUNDRAISING> [Global Notice] The current total is $800.95. Thanks to everybody who has contributed so far, and again, thanks for using OPN!

20:47:42 <SethR> i just made a quick fix .. if anyone had just downloaded, they should download again

20:49:58 <SethR> E: many thanks to eikeon and sbp for their fine parsers :)

20:49:58 <dc_rdfig> Added comment E5.

20:54:43 <SethR> E: read in [http://www.ilrt.bris.ac.uk/discovery/2001/06/content/swws2001-07-30.rdf|and check out how nested bNodes really look like]

20:54:43 <dc_rdfig> Added comment E6.

20:58:10 <SethR> E: [http://robustai.net/sailor/screenshots/nested_bNodes.html|or just click here to see a screen shot]

20:58:11 <dc_rdfig> Added comment E7.

20:59:30 <SethR> E: note that clicking on the red ~read~> buttons in the screen shot won't work unless you have installed sailor in the default port

20:59:31 <dc_rdfig> Added comment E8.

22:35:00 <bijan>http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html

22:35:00 <dc_rdfig> F: http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html from bijan

22:35:19 <bijan> F:|Dijkstra's obit from University of Texas

22:35:20 <dc_rdfig> Titled item F.