Semantic Web Interest Group IRC Chat Logs for 2004-04-10

03:41:49 <DanC>http://www.w3.org/TR/2004/WD-xml-id-20040407/

03:41:50 <dc_rdfig> A: http://www.w3.org/TR/2004/WD-xml-id-20040407/ from DanC

03:41:57 <DanC> A:|xml:id Version 1.0

03:41:58 <dc_rdfig> Titled item A.

03:42:03 <DanC> A:W3C Working Draft 7 April 2004

03:42:04 <dc_rdfig> Added comment A1.

03:42:07 <DanC> A:about flargin time!

03:42:07 <dc_rdfig> Added comment A2.

03:42:41 <DanC> A2:woohoo! about flargin time!

03:42:41 <dc_rdfig> Replaced comment A2.

03:44:27 <sbp> A:I must also express my praise for this particular draft, and frustration at its slow coming to fruition. Totally kick-ass.

03:44:28 <dc_rdfig> Added comment A3.

03:45:33 <sbp> now they just need to repeat with @xml:style

03:50:56 <DanC>http://tbray.org/ongoing/When/200x/2004/04/03/OpeningDay2004

03:50:56 <dc_rdfig> B: http://tbray.org/ongoing/When/200x/2004/04/03/OpeningDay2004 from DanC

03:51:12 <DanC> B:|A Cog in the Baseball Machine

03:51:12 <dc_rdfig> Titled item B.

03:51:28 <DanC> B:learn somethin' new every day. Bray used to catch.

03:51:28 <dc_rdfig> Added comment B1.

04:08:54 * DanC tries bloglines... yummy... Sam Ruby on GRDDL... http://www.intertwingly.net/blog/1759.html

04:10:09 <danbri> I pointed him at GRDDL on monday; on tuesday he said "I like it"

04:10:13 <danbri> This was re Atom

04:10:19 * danbri reads

04:10:47 <danbri> how far along is grddl for non-xhtml input?

04:26:11 <DanC> umm... done?

04:26:33 <DanC> i.e. designed, implemented, with zero-install online demo, and tests.

04:26:57 <DanC> ah... "howto" not done.

04:27:06 <eikeon> clear

04:27:25 <DanC> clear what?

04:27:38 <eikeon> /clear even :)

04:27:53 * eikeon sleepy

04:36:40 * sbp makes progress with toIcal.py

04:37:32 <DanC> oh?

04:39:37 <sbp> yeah, I finally worked out how to do it, so I'm currently restructuring it to work

04:40:23 <sbp> can I assume that a list of FLOATs is going to be a GEO?

04:40:49 <sbp> well, I'm going to have to since there's no other information

04:40:50 <DanC> umm... that doesn't appeal to me

04:40:52 <DanC> why?

04:41:29 <DanC> it goes the other way, no? the code knows it's looking for a list of floats

04:41:54 <sbp> ah, yes

04:42:30 * sbp probably shouldn't be doing this at 6AM, but is determined and interested

04:47:01 <danbri> the list of floats approach feels overly mechanistic a mapping to me... after all, don't we re-write the string structuring micromarkup in dates/times as they go from ical to rdfical?

04:47:56 <DanC> yes

04:48:05 <danbri> I'd prefer cal:latitude/longitute properties. And then discussion would be whether they were wgs84 or not. I don't see much by way of community practice around ical's geo facility so answering that one seems tough to do in a vacuum...

04:48:49 <danbri> if there were lots of tools, producing and consuming, and faqs etc that said 'we prefer wgs84', perhaps absence of that in the RFC could be overlooked

04:49:03 <danbri> (much as other ical-related specs (CAP?) help clarify things like cardinality...?)

04:50:04 <DanC> the conversion code doesn't do anything interesting on a per-property basis. It only looks up the property type. So the conversion code knows it's got a list of float, but it doesn't know it's a lat/lon pair.

04:50:50 <danbri> the rfc-to-schema convertor? oh you mean instance data convertor?

04:51:00 <DanC> yes, the instance data converters.

04:51:34 <DanC> if valueType == 'TEXT':

04:51:34 <DanC> self.doTEXT(sts, val, prop, predName)

04:51:34 <DanC> elif valueType == 'INTEGER':

04:51:34 <DanC> self.doINTEGER(sts, val, prop, predName)

04:51:36 <DanC> and so on

04:51:55 <danbri> how is the data substructure stuff handled, then? something somewhere knows that 20040502 -> 2004-05-02Z (or whatever the difference is, I forget).

04:52:22 <DanC> yes:

04:52:24 <DanC> elif valueType == 'DATE-TIME':

04:52:24 <DanC> self.doDateTime(sts, val, prop, predName)

04:52:24 <DanC> elif valueType == 'DURATION':

04:52:24 <DanC> self.doDuration(sts, val, prop, predName)

04:52:27 <danbri> maybe location could be handled as a datatype-ish thing too?

04:52:36 <DanC> how?

04:52:52 <DanC> the RFC says GEO: takes a list of floats.

04:52:59 <danbri> elif valueType == "LOCATION' self.doLocation(sts,val,prop,predName)

04:53:08 <DanC> there is no LOCATION type.

04:53:17 <danbri> I made that up, indeed

04:53:54 <danbri> is the problem the granularity? everything else is on a property-by-property level, this geo stuff is w.r.t. a cluster of properties?

04:53:56 <DanC> why does everybody want to wedge other meanings into ical:geo? it means what RFC2445 says it means. If you want a different meaning, choose a different URI. Crunch all you want; there are plenty of URIs.

04:54:34 <DanC> RFC2445 says ical:geo maps an event to a pair of floats that are the lat/long of a place.

04:54:46 <DanC> it does *not* say ical:geo maps an event to a place. it just doesn't.

04:55:32 <danbri> but you feel its ok to remap the datatyped spaces for times?

04:55:40 <danbri> datetimes etc

04:55:58 <danbri> rather than simply reflect out what ical does, and 'crunch all you want' afterwards?

04:56:16 <DanC> I don't follow you. I think we are reflecting what ical does.

04:56:32 <DanC> RFC2445 doesn't say dtstart takes a string; it says dtstart takes a datetime.

04:56:45 <DanC> in fact, the RDF version of iCal really should use datatypes.

04:56:52 <danbri> i thought the datetime syntax got transformed...

04:57:10 <danbri> ah, but they're both datetimes, is that the position?

04:57:15 <DanC> yes, the syntax gets transformed. the conversion code knows about the RFC2445 value types.

04:57:53 <DanC> "both datetimes"... I don't think I'm following you.

04:58:51 * sbp puzzles over why sts.any(comp, ICAL.sym(predName)) returns ('FLOAT',) rather than ('FLOAT', 'FLOAT')

04:59:23 <danbri> the syntactic form in ical, and the the format we emit as rdf, ....are both considered by you to be 'datetimes', hence we're not doing violence to the RFC. Whereas with geo, we are discussing a map from list-of-float to Location, which changes the meaning not just the encoding?

05:00:06 <DanC> RFC2445 lists are homogeneous, sbp

05:00:20 <DanC> yes, danbri.

05:00:51 <sbp> ah, thanks

05:01:31 <DanC> the thing that really sucks, danbri, is that RFC2445 datetimes are almost, but not quite, just like XML Schema datetimes.

05:02:00 * eikeon plans to add cwm compatibility methods to rdflib... any, each, ... with any luck I'll get to it this weekend. But first, sleep.

05:02:02 <eikeon> g'nite.

05:02:35 <DanC> In XML schema, you can say 10am -0400 = 11am -0300. But you can't equate those in iCalendar because of interactions between timezones and recurring events.

05:02:35 <danbri> Maybe a compromise position: Sometimes people know more about a dataset than licensed by the formalities of the fileformat it is stored in. To assist those folks make best export to the semweb, perhaps ical-to-rdf tools could have *optional*, 'use this if you know what you're doing' facilities to also emit statements that use the geo wgs_84 vocab? (since there are many more consumers of that vocab than of the ical float-list thing).

05:02:46 * danbri nods

05:02:51 <danbri> bye eikeon

05:03:23 <DanC> the conversion code could emit extra wgs_84 stuff, but it can't use ical:geo in that case.

05:03:36 <danbri> why not both?

05:04:01 <DanC> i.e. it has to do { :e1 ical:geo (26 54); cyc:eventOccursAt [ geo:lat 26; geo:lon 54] } ...

05:04:16 <danbri> if I know that my laptop's iCal calendar for me has lat/longs which are wgs_84, and I want to export, what's wrong with both?

05:04:25 <danbri> yes, i mean both.

05:04:37 <danbri> ah thought you meant "but in such case, it should suppress the float-based triples.

05:04:41 <danbri> ok, makes sense now.

05:04:48 <DanC> and not... gee... I dunno how to even write an expression where the object of ical:geo is both a list of floats and a thing with a lat/long

05:04:57 <danbri> agreed.

05:05:03 <danbri> we don't want the dc:creator mess again.

05:05:16 <danbri> is the cyc ns URI stable / well known btw?

05:05:24 * DanC gets that happy consensus feeling

05:05:50 <DanC> umm... cyc scores a B- on stability and C+ on well-known-ness.

05:06:27 <DanC> i.e. cyc hasn't 404'd, but they sorta randomly pick a new location every 6 to 9 months.

05:06:28 <sbp> ha, it's working. snippet: [[[

05:06:29 <sbp> SEQUENCE:3

05:06:29 <sbp> GEO:40.442673;-79.945815

05:06:29 <sbp> URL;VALUE=URI:None

05:06:29 <danbri> consensus, yes me too. I'd like to get Kanzaki's perspective (we talked about this over lunch yesterday), but I think it addresses his main worries.

05:06:30 <dc_rdfig> Label SEQUENCE not found.

05:06:30 <sbp> ]]]

05:06:30 <dc_rdfig> Label GEO not found.

05:06:50 <DanC> looks good, sbp

05:06:56 <danbri> logger, pointer?

05:06:56 <danbri> See http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-04-10#T05-06-56

05:07:52 <DanC> I'd like to explore using SUMO where I've been using cyc...

05:08:00 <DanC> Adam contacted me again pretty recently.

05:08:09 <DanC> But so far, SUMO's not GETtable yet.

05:08:25 <DanC> (well, you can GET the source in KIF in cvsweb)

05:10:26 <DanC> I suppose we could make a new people-places-and-things schema... but that seems like madness.

05:11:14 <DanC> or we could heap more stuff into foaf, but I wonder if that's wise.

05:12:05 <DanC> what did lea dods (sp?) do for the conference wiki thingy?

05:12:28 <danbri> I'd prefer 'bulk' things to go in other namespaces, but foaf is good for little convenience bits of glue, too.

05:12:50 <danbri> ie. if the sw needs a handy little property and making a whole ns for it is overkill, foaf is appropriate.

05:13:12 <danbri> there's a lot more user education to do, having develoeprs think of it as a dictionary of terms rather than a file format...

05:13:17 <DanC> xmlns:conf="http://www.mindswap.org/~golbeck/web/www04photo.owl#"

05:13:22 <danbri> (bloating a dictionary is one thing; bloating a file format is worse)

05:13:33 * danbri wonders if libby around

05:13:35 <danbri> .time BST

05:13:36 <datum> Sat, 10 Apr 2004 06:13:36 BST

05:13:41 * golbeck sees her name show up

05:13:43 <danbri> maximally unlikely

05:14:02 <DanC> I'm increasingly concerned about / vs. #; e.g. the recent discussion with Hayes.

05:14:56 <danbri> I didn't notice / vs # crop up explicitly there, but yes. Would be nice to get it nailed. If migration has to happen, that's a major major w3c project. And a tough one to cast into a positive outreach light (though it could be).

05:15:03 * DanC is reading http://www.ldodds.com/conference/Wiki.jsp?page=ConferenceMetadataExample

05:15:32 <DanC> w3c project? I'm not aware of any w3c namespaces that use /

05:15:54 <DanC> it's a big project for everybody using dc:title

05:16:21 <DanC> and foaf and xmp and...

05:16:24 <danbri> well, who else but w3c is going to say "hey Rdf folks. all those files that use / namespaces are borken. but it's ok, 'cos we'll have a publicity drive around the new versions of your ontologies or a party of something to cheer people up...'

05:17:31 <danbri> without a positive spin (and I'd look to w3c for that), the request for updating will be ignored, I expect. DC will say "are rss, xmp doing it"; rss will say [etc]...

05:17:50 <DanC> hmm... I picture it working like broken HTML markup. There's plenty of it out there, and it sorta works, but W3C doesn't endorse it.

05:18:17 <danbri> the xmp situation is the most concerning. millions of pdfs etc in situation where update will take years.

05:18:38 <danbri> and during the migrations, when multiple property URIs are in use, headaches for application developers.

05:18:53 <danbri> Hmm this could be made easier if DAWG endorse a design supporting optionals.

05:19:06 <DanC> I find it kinda mind-boggling that adobe didn't so much as ask for advice on their choice of / vs #

05:19:15 <sbp> whoops, sent to www-calendar instead of www-rdf-calendar. feel free to forward it

05:20:08 <danbri> SELECT ?n from THEWEB where (foaf:name ?x ?n) OR (foaf2:name ?x ?n) AND (foaf:homepage ?x http://danbri.org/) OR ...etc etc.

05:20:18 <danbri> could get hairy quickly

05:20:34 * DanC prefers subPropertyOf connections to OR

05:20:41 <danbri> mind-boggling. really?

05:20:53 <DanC> yes. OR involves NOT

05:20:55 <danbri> with subPropertyOf, you could derrive a contradiction in some cases?

05:21:14 <DanC> contradiction?

05:21:28 <DanC> I like the 'assuming' idea that floated accross rdf-dawg recently:

05:21:46 <danbri> if timbl is right, and non-# http: URIs denote documents, then they can't be properties, esp if properties and documents are disjoint.

05:21:55 <DanC> assuming { foaf:name rdfs:subPropertyOf foaf2:name } select ?N where (foaf:name ?x ?N).

05:22:07 <sbp> hmm. it's not come through on public-cwm-talk either. DanC, could you possibly check to see whether you have a patch from me Date: Sat, 10 Apr 2004 06:18:22 +0100

05:22:10 <danbri> if foaf2: is in # namespace, but a subproperty of foaf1 stuff... hmm

05:22:28 <danbri> my thoughts muddled, but it seems to propagate the error (if indeed an error) rather than make a clean break.

05:22:41 <DanC> I see what you mean about a contradiction. But I don't think OR helps.

05:22:44 <danbri> Yes, 'assuming' is a nice approach generally.

05:23:26 <DanC> what can I search for, sbp? gimme a subject word?

05:23:37 <sbp> Subject: Patch for toIcal.py v.2.19

05:23:43 <danbri> I guess I'm talking about optionals, along lines of "get me the foaf:nick and/or foaf:name of everyone whose workplaceHomepage is http://www.w3.org/"

05:24:01 <DanC> connolly@homer ../Admin[513] grep toIcal ~/Mail/message-log-2004-0414

05:24:01 <danbri> the Annotea folks have some experience of this, re dc1.0 to dc1.1 migration. Maybe ericp has some sample queries?

05:24:02 <DanC> connolly@homer ../Admin[514]

05:24:17 <sbp> glee. SMTP is broken, and infomesh.net DNS is too

05:24:18 <sbp> hang on...

05:24:27 <DanC> yes, he's mentioned dc1.0 to dc1.1 migration.

05:24:36 <DanC> why did dc change namespaces, btw?

05:24:59 <DanC> seemed like the right thing at the time?

05:25:12 <sbp> http://uwimp.com/sbp/toIcal.patch.txt

05:25:33 <DanC> (14 in 0414 is a week number, btw)

05:26:19 <danbri> eric, "we tried to update to dc1.1 uris, but allow for possibility that olde clients might still send and expect dc1.0?

05:26:49 <danbri> ..."these older clients can round trip 1.0, but will get 1.1 from annotations created by newer clients

05:26:57 <DanC> why does doSIMPLE take more args than it uses?

05:26:58 <danbri> ..."and therefore not know what they mean.

05:27:23 <danbri> ..."basically, what didn't do was declare any equivence between them. If DCMI meant something different by them, we preseve/respect that

05:27:51 <danbri> eric, "see my DAWG use case

05:28:14 <DanC> *if* DCMI...??!? I thought DCMI minted the namespace names.

05:28:26 <sbp> DanC: same question for doTEXT, doINTEGER, and doURI in your v.2.19!

05:28:36 <sbp> makes it nice and consistent

05:28:46 <danbri> DCMI might have regrets, I think

05:28:51 <danbri> s/if/given that/

05:29:11 <DanC> but doTEXT actually uses those args.

05:30:02 <sbp> no, it doesn't use "sts" and nor does it use "predName"

05:30:29 * danbri talks w/ ericp about this a bit

05:30:32 <DanC> ok, bug

05:31:04 <sbp> let's just say it leaves room for future development! :-)

05:31:18 <DanC> ew

05:31:27 <danbri> Hmm if we are really going to unleash a massive namespace migration on the world, I expect there'll be a lot of expectations to DAWG that the rdf query language will support (in some way) convenient namespace aliasing.

05:31:30 * DanC tries pychecker, loses...

05:31:40 <danbri> ...whether thru disjunctions, optionals, assumptions clauses, special magic

05:31:42 <DanC> File "/usr/lib/site-python/pychecker/checker.py", line 226, in allBaseClasses

05:31:42 <DanC> for base in c.__bases__ :

05:31:42 <DanC> TypeError: iteration over non-sequence

05:32:09 <DanC> I don't expect any massive namespace migration. I just expect a slow fade.

05:32:51 <sbp> I'd run pychecker on itself if I were you

05:33:23 <DanC> and I hope to keep DAWG to strict conjuctive queries, for the first version. 'assuming' is neato, but too hairy.

05:33:23 <danbri> slow fade: i doubt it.

05:33:33 <danbri> foaf, rss, dc won't go indpendently

05:33:54 <ericP> disjunction discussion in DAWG: http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0083

05:34:00 <DanC> argument by assertion. I can play that game. yes, foaf, rss, and dc will go independently.

05:34:01 <danbri> and xmp are v unlikely to go it alone

05:34:10 <danbri> Argument by control!

05:34:16 <DanC> ?

05:34:22 <danbri> I'm around the relevant tables

05:34:36 <sbp> argument by danbri privilege

05:34:53 <danbri> I'd be happy to argue for an all at once, but not going to say in good faith to DC "hey, go change this, the rest of us might get around to it sometime"

05:34:53 <DanC> same thing as argument by assertion

05:35:03 <sbp> heh

05:35:38 <danbri> RSS is different, because of the politicking and whatnot around rss2, atom etc. I'd rather spend time there looking into bring Atom into W3C.

05:36:09 <danbri> And FOAF is a guinea pig, sure we could go first there.

05:36:25 * DanC chuckles as danbri makes my argument for me

05:36:33 <danbri> ...but to get tool/dev folk to follow the ns change, they'd need persuading.

05:37:06 <danbri> And my concern is: what will persuade all these folk. While schemas may be 1 at a time, applications ('cos of the way sw works) often consume multiple nampescaes at same time.

05:37:20 <DanC> I don't expect dc to ever change.

05:37:28 <DanC> and probably not foaf.

05:37:34 <DanC> the shot only goes round the world once.

05:37:48 <danbri> perhaps getting namespace-aliaising utilities into redland, jena etc would ease the transition pain

05:38:03 <danbri> if rss1 changes, it'll be via 'spirit of rss1' living on in some atom-as-rdf flavour

05:38:10 <DanC> maybe the foaf community still evolves enough to do a switch.

05:38:40 <Remosi> hmm

05:38:40 <danbri> of all the overlapping communities around rdf vocabs, they're the ones that follow this level of nerdy detail the closest

05:38:46 <Remosi> isn't that why we have sameAs ?

05:38:58 <danbri> sameAs is just what we _don't_ want.

05:39:08 <Remosi> why?

05:39:29 <DanC> yes, it's why we have sameAs... or subPropertyOf, at least. I think "good support for subPropertyOf" is what danbri means by "aliasing support"

05:39:43 <danbri> If http://example.com/ns#title and http://example.com/ns/title could be two names for the self-same thing, we wouldn't need the migration in the first place!

05:39:58 <ericP> a description of the trade-offs involved in using a subPropertyOf or sameAs approach to querying data that may have multiple predicates that are interchangable for the purposes of the query: http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0056

05:40:06 <danbri> Tim says that http://example.com/ns/title can't be a name for an rdf property/predicate.

05:40:13 <danbri> if it can, then we don't need to migrate.

05:40:30 <DanC> ooh... score one for RDF Core... subPropertyOf allows #title and /title to denote different things and yet share property extensions.

05:40:36 <ericP>http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0056

05:40:37 <dc_rdfig> C: http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0056 from ericP

05:40:55 <ericP> C:description of the trade-offs involved in using a subPropertyOf or sameAs approach to querying data that may have multiple predicates that are interchangable for the purposes of the query

05:40:55 <dc_rdfig> Added comment C1.

05:41:00 <danbri> maybe subpropertyof could do it then, but not sameAs

05:41:16 <danbri> but subpropertyof probably has domain and range of Property?

05:41:23 <DanC> yes

05:41:47 <DanC> timbl's going to lose if he takes a 100% strict position on http://example.com/ns/title not denoting a property.

05:42:02 <DanC> you can only say it should not.

05:42:17 <danbri> interesting

05:42:19 <DanC> just like publishers shouldn't arbitrarily 404 their URIs

05:42:25 <danbri> i figured it the other way around

05:42:45 <danbri> i'd only bother encouraging a ns migration, mass form, if it was a genuine 100% error.

05:42:58 <danbri> Otherwise, I think you and i are sounding consensual... a slow migration would be fine.

05:43:04 <DanC> the whole semantic web can't come crumbling down because one person says a #-less URI denotes a person (MarkB) or a property (dublin core).

05:43:25 <danbri> If it is a 'best practice' convention, not a massive bug... yes, slow, 1-by-1 makes sense.

05:44:02 <DanC> the evidence is pretty compelling that it's not a massive bug. cwm doesn't fall over when you feed it dc:title, and neither does anything else.

05:44:19 <danbri> tim did try to booby-trap cwm in that way, I thought.

05:44:36 <sbp> it can still be an error. just like a function may have a bug; if the function doesn't get called in the program, then you won't notice the error. if a hashless URI is used to denote a person or a property and your code doesn't depend on it denoting a generic document, then you won't notice it. it's still an error

05:44:36 <DanC> but cwm sorta reminds you that dc:title isn't cool by writing it out long-hand all the time.

05:44:37 <danbri> but redland, jena, mozilla, rdflib, sesame, ...etc don't.

05:45:42 <sbp> you can't just arbitrarily claim that it's not an error

05:45:48 * DanC reads http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0056 , wishes for a user story

05:45:50 <sbp> if the position were clear, it would be resolved by now

05:46:06 <sbp> it has not been resolved, hence it may well be an error. QED

05:46:21 <DanC> I can't arbitrarily claim...? gee... I thought I just did. ;-)

05:46:26 <sbp> heh, heh

05:46:36 <danbri> we're talking about maybe 25-50% of published-in-the-web RDF statements. If it is a 'this is a bit old hat, think about doing it better if you make successor namespaces', that's cool. If we say they're all statements that, in a mathematically grounded way, are guanteed never to be true descriptions of the world, we're in a very different place.

05:47:04 <danbri> like rdf:Bag etc.

05:47:39 <DanC> yes, I look at it like rdf:Bag. Hence my hesitation to invest further in / namespaces, while I do occasionally use them.

05:47:49 <Remosi> I'm sorry, I must be pretty dumb, but I still don't get this? a URI without a fragment can only refer toa document however a uri with a fragment can refer to information about something else?

05:48:12 <danbri> that is the claim, yes. For http: URIs only. It is disputed.

05:48:14 <DanC> that's timbl's position, yes, Remosi.

05:48:50 <danbri> http: and https: URI schemes, possibly others, ftp:, gopher: ... taken on a case-by-case basis per their relevant specs.

05:48:55 <Remosi> so it's back to the good ol' "what's a resource?" argument again?

05:48:55 <DanC> "It is disupted"... understatement. You can measure the dispute on a bathroom scale, if not a richter scale.

05:49:06 <Remosi> heh

05:49:09 <sbp> richter: heh!

05:49:39 <danbri> It is the last remnant of the angels-on-pinheads reputation rdf had for fuzzy, pointless debates in 1999/2000 or so, after the 1st REC, before RDFCore.

05:50:04 <Remosi> aww

05:50:19 <Remosi> but theres no fun in a argument if there are concrete reasons for things :)

05:51:28 <sbp> John Reynolds via Phil Walder via James Clark: "Semanticists should be obstetricians, not coroners of programming languages."

05:52:05 <sbp> I think someone said something similar of XML specifications; something like "We're supposed to be computer scientists, not coroners of specifications."

05:52:30 <sbp> if the meaning of what an HTTP URI denotes had been clearly specified in RFC 2616, we wouldn't be in this mess

05:52:36 <Remosi> indeed

05:53:09 <Remosi> so this means that current schemas must be migrated

05:53:20 <danbri> I wonder if anyone in the web services community is taking note of the debate. They might be interested to know if they can't identify Web Services with non-# http URIs.

05:53:28 <danbri> no Remosi, it doesn't.

05:53:35 <sbp> not necessarily, rather

05:53:37 <danbri> TimBL has not persauded many people.

05:53:45 <sbp> I'd say most

05:54:13 <danbri> Sure. 5billion+ people remain largely unmoved by his protests.

05:54:20 <Remosi> heh

05:54:27 <danbri> also, most rdf people.

05:54:31 <sbp> heh. even in close W3C/SW circles, though. right

05:54:45 <DanC> hmm... mkTEXT missed an update to doTEXT in v2.19

05:54:58 <danbri> yes. DanC seems sympathetic. Am not sure who else at all there is. Maybe sandro, not sure.

05:55:16 <Remosi> well, this is the first time I've heard of this discussion, it doesn't seem to be referenced anywhere

05:55:27 <danbri> .google hashversusslash

05:55:28 <datum> hashversusslash: sorry, no results were found.

05:55:41 <danbri> there's a page for it in the wiki, i forget name it seems\

05:55:59 <Remosi> Sure, but knowing I have to google for the debate kinda defeats the purpose

05:56:12 <DanC> the text of RFC2616 supports timbl's position pretty strongly, sbp. It says "network accessable resource" or something pretty close to that...

05:56:45 <sbp> DanC: whoops. I hadn't freshened my dev.w3.org tree when I started to work on it

05:56:48 <DanC> yes, web services folks are tuned in, via tag issue abstractComponentRef-37 (which was accepted over my objection, since it's a dup)

05:57:01 <sbp> and ah, that's intriguing

05:57:19 <DanC> .google HashVersusSlash

05:57:19 <datum> HashVersusSlash: sorry, no results were found.

05:57:27 <DanC> .google HashUri

05:57:28 <datum> HashUri: http://esw.w3.org/topic/HashURI

05:57:54 <DanC> (ah yes... naming wiki topics after debates is an antipattern.)

05:58:17 <sbp> (why's that?)

05:59:12 <DanC> (something near http://c2.com/cgi/wiki?DontNamePagesThoughtsIssuesIdeasOrOpinions ...)

05:59:23 <danbri> hmm RFC2616 doesn't restrict its notion of 'resource' to http:-named resources.

05:59:50 <sbp> (heh. the URI itself is argument enough)

06:00:15 <danbri> 3.2.2 "The "http" scheme is used to locate network resources via the HTTP protocol."

06:00:25 <danbri> that's a statement about practice. Sure, the scheme is used that way.

06:00:43 <DanC> hmm... http://c2.com/cgi/wiki?WikiIsNotAboutDebate

06:00:46 <Remosi> what about URN's and NAPTR?

06:01:16 <Remosi> could that skip the entire debate? urn:hostname:schema:node could then be NAPTR'd to a # or a /

06:01:19 <sbp> I read that part of 3.2.2 to mean solely used in that manner

06:01:38 <danbri> The semantics

06:01:38 <danbri> are that the identified resource is located at the server listening

06:01:38 <danbri> for TCP connections on that port of that host"

06:01:58 <danbri> 'the' server, 'the' resource.

06:02:05 <danbri> that'd be interesting to formalise.

06:02:46 <DanC> but urn:hostname:schema:node is #-less. I think timbl's position is independent of scheme.

06:02:48 <danbri> www.w3.org has multiple servers, http://www.w3.org/people/danbri/ is located at ...? all of these? one of these?

06:03:08 <danbri> I thought timbl only talking about http: URIs?

06:03:23 <sbp> I don't think any RFC holds up all that well to a bunch of semanticists and literary teratologists picking it apart word by word on an IRC channel years after its publication

06:03:48 <DanC> I think timbl's talking mostly about http: URIs. But I think his position is that it's the # that does the trick, not the http:

06:04:09 <danbri> sbp, me neither. so i resent having massive change or moderate FUD inflicted on foaf,rss,dc... based on selective reading of a fuzzy spec.

06:04:40 <sbp> agreed on that account; hence my comment earlier about lack of definition

06:04:42 <danbri> yes, danc, that's a good characterisation. the # gets you out of any commitments the URI scheme might make w.r.t. classes of thing allowed to be identified with those names.

06:05:11 <DanC> the HTTP RFC text is not compelling, but it does support timbl's argument, and it's not the whole of timbl's argument, danbri.

06:05:41 <sbp> and shunts the whole argument to MIME type specifications. but then that does include the URI scheme's specification to some extent, since that arbitrates over network access to obtaining a representation of the resource

06:06:08 <danbri> An ontology would be an interesting way to attempt to resolve this... ie. define a class that is timbl:DocumentishInfoResource ....

06:06:39 <sbp> I've tended to use http://www.w3.org/2000/10/swap/pim/doc#Work as that class

06:06:44 <DanC> timbl went the ontology way in reply to Hayes recently...

06:07:18 <DanC> doc:Work isn't quite big enough. InformationResource includes things you can only POST to

06:08:14 <DanC> [[[

06:08:15 <DanC> Some URIs, however identify InformationResources.

06:08:15 <DanC> { ?u a InformationResourceIdentifier.

06:08:15 <DanC> identifies ?x } => { ?x a InformationResource }.

06:08:19 <danbri> <s:comment>An abstract information thing of value, typically intellectual property</s:comment>

06:08:22 <DanC> ]]] -- http://lists.w3.org/Archives/Public/public-webarch-comments/2004AprJun/0001.html

06:09:17 <sbp> ah, but that was sent on the 1st of April

06:09:23 <sbp> so clearly an April Fools joke :-)

06:09:25 <danbri> an rdf property isn't its extension. properties are defined by communities, etc. I don't see it as being obvious the one way or the other, whether they are 'InformationResources'.

06:09:34 <danbri> reading 0001

06:10:01 <DanC> 0001 says # is special:

06:10:03 <DanC> { (?u "#" ?v) string:concatenation ?w } <=>

06:10:03 <DanC> { ?w irid ?u; localid ?v. }.

06:11:48 <danbri> interesting. but seems to skip over the possibility (evangelised in other bits of w3c work) that information resources can have multiple representations

06:12:32 <DanC> er... why not skip over that?

06:13:11 <DanC> it would be a digression, no?

06:13:14 <danbri> because of local namespace collision

06:13:15 <danbri> [[

06:13:16 <danbri> If you take the identifier of an

06:13:16 <danbri> informationresource

06:13:16 <danbri> and add a hash and a local identifier of something mentioned within that

06:13:16 <danbri> information resource, you forge a global identifier for whatever the

06:13:16 <danbri> local identifier

06:13:18 <danbri> was for.

06:13:21 <danbri> ]]

06:13:36 <danbri> works ok if there's only one representation

06:13:51 <sbp> hmm. "ApplicationIdentifier"--you'd think he'd call it "ResourceIdentifier" given the backing of the ability for an HTTP URI + frag to identify any resource

06:13:54 <danbri> if multiple reps, and they support an appropriate notion of 'locally mentioned', you get a clash.

06:14:03 <danbri> or you can get a clash

06:14:23 <DanC> it also works ok if there's more than one representation,no?

06:14:35 <danbri> eg. http://www.w3.org/Icons/w3c_main has multiple represntations in various image formats.

06:14:39 <DanC> yes, you can get a clash. so?

06:14:59 <danbri> each of those might have local identifiers

06:15:05 <sbp> I'd say that content negotiation on that resource is broken

06:15:25 <danbri> timbl's definition is couched in terms of 'the' not 'a'

06:16:01 <sbp> XPointer is most horrid in that respect; the more granular you get, the less generic a use you can put it to in representations that may have fragment identifiers labelling parts of them

06:16:11 <DanC> I think where he wrote "the identifier" he meant "an identifier" but nowhere did he write "the representation"

06:16:13 <danbri> ...but he gives a recipe that'd allow http://www.w3.org/Icons/w3c_main#foo to be the 'global uri' for several different things, without any obvious bad-practice on part of the publisher, content creator, etc.

06:16:33 <danbri> yes, he glosses over existence of representations

06:16:54 <DanC> he didn't drill the point about bad practice.

06:17:30 <sbp> yet according to timbl's beliefs, http://www.w3.org/Icons/w3c_main is bad practice, right?

06:17:45 <DanC> is it?

06:18:00 <sbp> as far as I can tell. I'm asking for your opinion

06:18:02 <danbri> I would love to know.

06:18:10 <DanC> which identifier is given different meanings in different representations of w3c_main?

06:18:53 <sbp> http://www.w3.org/Icons/w3c_main#xpointer(/)

06:19:34 <DanC> huh? which representation gives a meaning for that fragment?

06:19:38 <danbri> I think there are just png and gif formats there at the moment

06:19:55 <sbp> ah, so there are. my apologies

06:20:35 <DanC> and even if an SVG were available there, it wouldn't be broken. Not until you put SVG *and* say HTML or RDF.

06:20:47 * sbp gets to work on a pngpointer() specification

06:20:56 <DanC> and yes, XPointer gives me the willies.

06:21:38 <danbri> say #date on a GIF means date created, #date on a PNG means, 'whatever is in the "date" slot in the metadata fields PNG provide.'

06:22:09 <danbri> HTTP/1.1 406 Not Acceptable

06:22:09 <danbri> Date: Sat, 10 Apr 2004 06:20:00 GMT

06:22:09 <danbri> Server: Apache/1.3.28 (Unix) PHP/4.2.3

06:22:09 <danbri> Alternates: {"w3c_main.png" 0.7 {type image/png} {length 5904}}, {"w3c_main.gif" 0.5 {type image/gif} {length 5684}}

06:22:09 <danbri> Vary: negotiate,accept

06:22:23 <sbp> hmm. but #xpointer(/) on a JPEG... I'm not sure what it identifies, but I'm quite sure that it doesn't identify an XML infoset root level

06:22:24 <danbri> what about #length or #size...?

06:22:52 <danbri> most non-xml formats don't define semantics for # local names, i guess

06:23:21 <sbp> yeah. text/html is the only exception I can think of

06:24:24 * danbri gets that going-round-same-debate feeling, gives it a rest for now

06:24:29 * sbp nods

06:25:21 <DanC> we started someplace relatively practical before we went alt-hyper-meta-bucky, didn't we?

06:25:33 <DanC> ah yes, connecting events to places

06:25:45 <sbp> alt-hyper-meta-bucky... chuckle

06:26:02 * DanC is glad we didn't go coke-bottle

06:27:23 <danbri> yes, i think some useful discussing happend (esp compromise re cal/geo, and account of pragmatic views re / vs # migration).

06:27:31 * sbp scrolls way, way up, and reads the part he missed whilst patching toIcal.py

06:27:33 <danbri> discussing the technical aspets of # vs / went same as ever

06:28:04 * DanC indulges in a visit to http://info.astrian.net/jargon/terms/q/quadruple_bucky.html

06:31:49 * sbp needs to read the jargon file more often, clearly

06:36:56 <DanC> the jargon file is one of those "warning! if you go in there, you're likely to not come out again for hours!" places on the web, for me.

06:37:27 <sbp> agreed. it's the hacker's grouphug.us, or bash.org

06:40:08 <sbp> the latest thing that managed to outer event horizon me was the T.V. Tropes Wiki: http://spacecrib.sytes.net/friki/view?TheCatalogue

06:40:44 <sbp> and I keep coming across others likewise attracted by the density of the matter therein

07:07:39 <DanC> hmm... mkURI doesn't seem to return anything. need to test it.

07:09:28 * DanC needs to take son to baseball practice in about 5 hrs... wanders off to sleep

07:13:00 <danbri> g'night

09:38:56 <adamhill> adamhill is now known as _dreaminofjeanni

17:28:46 <golbeck_> golbeck_ is now known as golbeck

17:44:35 <sh1mmer> hi libby :)

17:53:51 <libby> heya sh1m. did you like shaun of the dead?

17:54:50 * JibberJim was going to go see that.

17:55:23 <libby> ah it's cool

17:55:31 <libby> but it scared me :/

17:55:54 * libby a wimp

19:31:18 <_dreaminofjeanni> _dreaminofjeanni is now known as adamhill

22:06:47 <adamhill> adamhill is now known as _adamhill

23:49:48 <_adamhill> _adamhill is now known as adamhill