Semantic Web Interest Group IRC Chat Logs for 2003-08-13

This is an automatically generated IRC chat log made by the logger bot from the Semantic Web Interest Group IRC chat at irc://irc.freenode.net/rdfig (also known as server irc.freenode.net channel #rdfig if that URI does not work for you).

NOTICE: #rdfig logs are being turned off 2004-12-03. Please switch to the new and shiny #swig channel for Semantic Web Interest Group chat. Change your client to #swig and enjoy the new experience. Or read the latest #swig logs to see what you've been missing :)


Semantic Web Interest Group Logs > 2003 > 2003-08 > 2003-08-13 (Latest) (Search)

01:33:48 <ChanServ> [#rdfig] This channel is logged and blogged: http://logicerror.com/rdfIRCWelcome

01:37:43 <dmwaters> {global notice} hi all. it appears that one of our main us hubs has disappeared. any further messages will be given in wallops, /mode your_nick +w

02:48:05 <jql-zzz> jql-zzz is now known as jql

05:30:58 <Gandalfur> Gandalfur is now known as thorisson

05:33:21 <Thorisson> hello

07:14:41 <jql> jql is now known as jql-zzz

07:23:54 <GNUWookie> GNUWookie is now known as Wookiee-Work

08:57:55 <apluc_aem> apluc_aem is now known as EdTivrsky

09:18:27 <chrisc_> chrisc_ is now known as chrisc

10:24:17 <verbosus> Hello everyone: has the EXIF/RDF scheduled chat already happened?

10:27:02 <deltab> no, it's only 10:27Z

10:27:05 <darobin> verbosus: no, it's later

10:27:28 <danbri_> hi verbosus

10:27:45 <verbosus> Hi there deltab, darobin, danbri.

10:27:58 <darobin> lo

10:28:18 <verbosus> Sorry, I just couldn't translate between my time (GMT +0100) and the scheduled chat one.

10:29:03 <darobin> it's at 1500 french time, so if .it has the same DST should be the same for you

10:30:11 <verbosus> Yes, thanks darobin.

10:30:53 <deltab> DST is aligned across the EU, I think

10:31:57 <verbosus> Portugal and the UK are in another timezone (+1 from here), AFAIK.

10:32:10 <verbosus> Ireland as well, of course.

10:34:28 <dajobe> you can ask datum

10:34:31 <dajobe> .time GMT

10:34:32 <datum> Wed, 13 Aug 2003 10:34:31 GMT

10:35:20 <verbosus> Thanks dajobe, that's very handy.

10:35:58 <danbri_> danbri_ is now known as danbri

11:16:17 <hendry> What is the time in EST?

11:16:38 <dajobe> depends on which E=Eastern, Estonian, Eritrean, ...

11:17:18 <hendry> dajobe: new york time

11:17:19 <libby> .time EST

11:17:19 <datum> Wed, 13 Aug 2003 06:17:19 EST

11:18:40 <libby> this is very handy too hendry: http://www.timeanddate.com/worldclock/fixedform.html

11:21:30 <hendry> libby: What about a unix tool? like getting date to switch to EST ... (?)

11:22:06 <libby> sorry, not sure what you mean hendry....

11:22:38 <dajobe> TZ=EST date

11:22:57 <dajobe> that works from most unix prompts

11:25:51 <hendry> dajobe: then you have to reset it back. k

11:26:10 * hendry tries out PhotoSMORE

11:26:21 <dajobe> it doesn't change the timezone, just displays the date in the zone you give

11:29:09 <hendry> dajobe: oh sorry. didn't run them together. I exported. Oops. Cheers

11:30:14 <hendry> With PhotoSMORE, can you annotate images? Can only seem to do Image manip tasks

11:32:07 <hendry> I think you can. According to this : http://www.mindswap.org/~aditkal/photoSMORE.jpg

11:32:27 <hendry> But the UI sucks bad.

11:38:29 <libby> blimey that looks familiar :)

11:45:46 <hendry> libby: the shepard?

11:46:31 <libby> the shepard is one of jibberjim's photos i think, and jim aslo did the outlining thing in svg

12:04:10 <hendry> GregElin: mornin'

12:04:21 <GregElin> Is that Kai?

12:04:42 <GregElin> Hey, Kai. Glad you could make it.

12:06:20 <hendry> I wish the tool my group are working on was presentable at this time.

12:06:27 <GregElin> hi libby

12:08:51 <GregElin> Kai, can you describe it? Do you think it might be ready by 8.27?

12:11:01 <hendry> GregElin: Should be ready then.

12:11:31 <darobin> has anyone done work bridging XForms and RDF?

12:12:06 <hendry> It

12:12:34 <hendry> Sorry, it's similar to RDFPIC for simplicity. But it sports a tree view and selection tools

12:12:44 <libby> darobin, charles mcCathieNville has been doing some stuff generating RDF using xforms

12:12:58 <darobin> anything available online?

12:12:59 <hendry> There are SE docs here : http://db.cs.helsinki.fi/~msisalmi/twiki/bin/view/Digimon/DocumentCollection

12:13:28 <darobin> I was thinking that replacing XForms' constant use of XPath with some rdf ql might do most of the trick

12:13:52 <darobin> (emphasis on might)

12:14:06 <libby> interesting

12:14:19 <libby> I was wittering about somethign similar for xslt recently

12:14:34 <libby> I do;t think char;es' stuff does anything like that tho

12:15:47 <earle>http://www.advogato.org/article/696.html

12:15:48 <dc_rdfig> A: http://www.advogato.org/article/696.html from earle

12:16:20 <earle> A:|Introspector Project refocused on DotGNU(.NET) and RDF(Semantic Web)

12:16:20 <dc_rdfig> Titled item A.

12:16:35 <earle> A:"The DotNet system presents you with much more metadata then you could ever want."

12:16:35 <dc_rdfig> Added comment A1.

12:16:36 <darobin> google finds something about using xforms as an intermediate step between rdfs and rdf authoring, but it has no details

12:17:17 <Wack> i've done some work in bridging xforms to rdf

12:17:24 <libby> some of chaals' stuff: http://www.w3.org/2001/sw/Europe/200305/axforms/

12:17:26 <earle> A:"[The] features will unite the semantic web and the dotnet world. Programs and Executions can be treated as data, Data can be treated as Logical statements and fed into proof engines."

12:17:26 <dc_rdfig> Added comment A2.

12:17:27 <libby> really wack?

12:17:49 <darobin> Wack: any details?

12:17:50 <Wack> well, theoretically xforms; it only works with vanilla html forms now

12:18:00 <GregElin> brb

12:18:23 <Wack> but i've used xforms controls etc to augment rdfs schemas in order to help generating the html

12:19:06 <Wack> it's a module in our website development framework

12:19:19 <Wack> all data storage and in-request data is in an rdf model

12:19:42 <darobin> libby: thanks for the pointer. It seems quite specific to EARL, but appears to have some interesting stuff

12:20:21 <darobin> Wack: so given some rdf it generates the HTML interface to edit it?

12:20:22 <Wack> so it was only a matter of time to bridge rdfs and a form generating/validating/processing module

12:20:32 <Wack> that's the plan, yes

12:20:40 <darobin> very interesting

12:20:53 <Wack> although it currently is dependent on the 'hints' you give it

12:20:54 <GregElin> Back!

12:21:22 <darobin> well you almost always need a little hinting

12:21:56 <darobin> to begin with, if a datatype <-> widgets that worked in all cases existed, we'd know about it :)

12:22:05 <Wack> and it's limited to creating statements with literals as objects (unless you point to choices which can be any other (anonymous or not) resource in the model)

12:22:20 <libby> darobin, I think there's another url for chaals' work, but ccan't fnd it

12:22:54 <darobin> libby: thanks a lot, nevermind, I'll pester him when he turns up ;)

12:23:02 <Wack> and the subject is always a resource representing the form "instance", so creating a host of instances of different rdfs classes is not possible yet

12:23:29 <darobin> Wack: ok, those limitations seem fairly normal for work in progress, they should be liftable

12:24:30 <Wack> I can put up the schema-schema i've created that should describe the idea more or less?

12:25:04 <darobin> I'm thinking along the lines of if you replace XPath with an rdfql you can access the instance in a way that makes sense, and from there all the bidirectional events stuff should work

12:25:14 <darobin> (perhaps with some rough bits around the edge)

12:25:23 <darobin> Wack: sure, that'd be great

12:25:40 <GregElin> Oy...so many acronyms. Is there an existing list anyway?

12:26:08 * darobin wishes he was paid to do research on anything he pleases whenever he pleases

12:27:15 <libby> very interesting idea darobin. seems to be lots of general interest about the relationship between graphs and tree and rdf and xml tools like that at the moment...

12:27:31 <darobin> yes

12:28:10 <darobin> and I suspect a number of tools made to work on trees, like xforms, work only on trees because people haven't thought of making them work elsewhere

12:28:41 <darobin> XForms needs trees on the UI side, because the event model is pretty heavily tied to trees

12:28:42 <libby> I agree

12:28:52 <libby> re graph/tree thing

12:28:52 <darobin> but I don't see why it needs it on the instance and model

12:29:27 <darobin> (and UIs as trees tends to make sense anyway)

12:29:31 <libby> so mizlla has xul, a thing for graph->tree transfrmation, mostly for UI stuff I think

12:29:38 <libby> s/mizilla/mozilla/

12:29:40 <darobin> yes

12:29:48 <darobin> mizilla is a cute name :)

12:29:50 <libby> though I've never got any demos working right

12:29:52 <libby> heh

12:30:21 <darobin> they seem to work for me. at least, my mozilla works and a number of the UI bits come from RDF (eg the mailbox tree)

12:30:44 <darobin> I think there's a paper on the moz site explaining that they have no general purpose graph2tree facility though

12:30:46 * darobin digs

12:31:02 <libby> yeah, I meant, there are some demos (I think made by danbri) using the Mooz stuff ith different sorts of data. bt they're fiddly to debug

12:31:14 <libby> s/mooz/moz/

12:31:43 <libby> important stuff is there though: a QL (with optionsals) and a templating language

12:32:11 <darobin> yup

12:32:42 <darobin> from http://www.mozilla.org/rdf/doc/xul-template-reference.html footnote 1 [[ Originally, we thought that it would be possibly to have a generic "graph-to-content" translation algorithm that, when combined with CSS2, could produce any appropriate content model (see this document). It quickly became clear that this was not the case ]]

12:32:50 <darobin> and this http://www.mozilla.org/rdf/content-model.html

12:34:23 <libby> do you mean with respect to a query languge, or something else?

12:34:47 <darobin> libby: do I mean which part?

12:35:15 <GregElin> (stepping away)

12:36:51 <libby> I think I'm on the wrong tack darbin: I was thinkingof generic graph to tree queries, since RDF queries are often like graphs

12:37:00 <libby> anyway...

12:37:45 <darobin> oh

12:38:03 <darobin> you mean turning a query that's like a graph into a query that's like a tree?

12:38:12 <libby> I think I'm just thinking twistedly

12:38:14 <libby> yeah

12:38:42 <libby> I was wondering what % of RDFgraphs can be expressed as trees

12:38:46 <darobin> I hadn't thought of that :)

12:38:58 <libby> sorry, I mean, what % of RDF queries can be expressed as trees

12:39:39 <darobin> what makes rdf q more graphlike?

12:39:40 <libby> if many could be, then a tree-like syntax for rdf queries might be useful. if you see what I mean

12:40:18 <darobin> tree-like as in XPath-like?

12:40:24 <libby> it tends to be, just because rdf people think of graphs and think of queries as graphs with muissing parts. or many do

12:40:26 <libby> yep

12:40:44 <darobin> ah yes, then I see what you mean

12:40:51 * darobin 's brain falls into place

12:41:01 <libby> I'm not being terribly clear today :)

12:41:23 <darobin> I'm not exactly up to date on that topic :)

12:43:03 <libby> my favourite hobby horse at the moment, although I've done no coding whatsoever to support it

12:43:36 <irc> irc is now known as DanC-AIM_

12:43:44 <darobin> I see the interest in the approach of having a query that's a graph with missing bits, so you dip in in the graph you're querying and the interesting bits stick to it

12:43:57 <edd> nice imagery

12:44:01 <darobin> but is it still interesting to have more "stupid" queries?

12:44:03 <DanC-AIM_> This nickname is reserved???

12:44:25 <darobin> ie just get a boring set of triples back, à la sql?

12:44:25 <libby> heh, cute, darobin

12:44:30 <darobin> :)

12:44:40 <libby> like fluff

12:44:44 <sbp> -NickServ- The nickname [DanC-AIM_] is not registered

12:44:46 <libby> boring?

12:44:58 <edd> a set of triples is a graph..

12:45:02 <darobin> well, more "usual" :)

12:45:18 <GregElin> back

12:45:47 <Wack> darobin: http://www.angelite.nl/2003/05/22-form-schema.rdf (I had to change dns etc, so it took some time before it was available ;)

12:45:58 <libby> usual queries='sticky' queries?

12:46:02 <darobin> edd: yup, I'm being unclear, I guess what I meant is is it still interesting to see them flatly, as a list of individual triples, as if at that point they weren't interlinked

12:46:14 <darobin> this would facilitate the tree view

12:46:26 <darobin> libby: no, more like "mundane", or "pedestrian"

12:46:35 * darobin doesn't like RDBMS ;)

12:46:49 <libby> it's useul to get triples list sometimes; sometimes a graph, sometimes bindings

12:47:14 <darobin> I'm just trying to think of a way in which the tree view would be easiest

12:47:19 <DanC-AIM_> /me can't see the /topic, wonders if I've stumbled on a meeting, or if the channel is just unusually active for this time of day

12:47:33 <libby> nah just chatting DanC-AIM_

12:47:40 <Wack>http://www.angelite.nl/2003/05/22-form-schema.rdf

12:47:41 <dc_rdfig> B: http://www.angelite.nl/2003/05/22-form-schema.rdf from Wack

12:47:43 <libby> meetign in 15mins on images and EXIF and RDF

12:47:56 <darobin> and probably not making much more sense than my usual braindump :)

12:48:12 <libby> why does a list of triples make it more tree-like?

12:48:12 <darobin> Wack: 404 :(

12:48:22 <DanC-AIM_> I wonder if norm knows about the image mtg

12:48:26 <DanC-AIM_> And gerald

12:48:45 <darobin> well it's the silliest tree, the root is the list, each triple is a branch with its own data as leaves

12:48:53 <darobin> (probably too boring)

12:49:00 <libby> ah, I get you

12:49:06 <libby> woudl that be useful?

12:49:12 <darobin> that was my question

12:49:19 <libby> so that sounds rather like cannonical XML/RDF

12:49:21 <Wack> B:|A generic (loosely on XForms based) form generation/validation/processing schema for existing RDFS schemas

12:49:22 <dc_rdfig> Titled item B.

12:49:22 <sbp> B=:http://www.angelite.nl/2003/05/form-schema.rdf

12:49:27 <darobin> since then, my brain has moved on to thinking "prolly not"

12:49:30 <sbp> B:=http://www.angelite.nl/2003/05/form-schema.rdf

12:49:31 <dc_rdfig> Replaced URL of B.

12:49:44 <libby> DanC-AIM_, a message re meet went around rdf-interest...

12:49:49 <Wack> ai you're right ;) typo, should be 22- though

12:50:00 <DanC-AIM_> /me wonders if the image chat was announced

12:50:18 <Wack> B:=http://www.angelite.nl/2003/05/22-form-schema.rdf

12:50:18 <dc_rdfig> Replaced URL of B.

12:50:31 <libby> on rdf-interest, geo list, chump twice and wiki... DanC-AIM_

12:50:55 <darobin> I guess a better way of making a ql look treelike would be to have sth like xpath each step of which is just graph traversal

12:51:09 <darobin> which is the case in xpath, except it's only in tree directions

12:51:14 <libby> that's the way I was thinking

12:51:33 <sbp> Wack: glad to see that you've used xml:base in there

12:51:33 <libby> I was wondering if xpath sntax would work for garphs

12:51:35 <darobin> so it's a sequence of moveTo commands

12:51:50 <darobin> Wack: thanks for that, i'll look into it this week-end :)

12:53:19 <marccanter> yo

12:53:26 <marccanter> anybody here?

12:53:37 <mortenf> hi marc

12:53:40 <marccanter> I am meta-data - therefor - I am

12:53:44 <marccanter> Morten!

12:53:49 <Wack> B:The basic idea is that http://www.angelite.nl/2003/05/22-form-schema#Field is a rdfs:subClassOf the rdfs:Property class.

12:53:50 <dc_rdfig> Added comment B1.

12:53:52 <mortenf> welcome!

12:54:24 <marccanter> I haven't had a chance to thank you - Morten - thank you

12:54:31 <mortenf> :) np

12:54:40 <danbri> hi all

12:54:54 * danbri will scribble an agenda in a sec

12:54:58 <Wack> B:Thay way, any form:Field instances I make are rdfs properties as well, although not vice versa per-se :/

12:54:58 <dc_rdfig> Added comment B2.

12:55:06 <danbri> basically show'n'tell, compare/contrast

12:55:55 <deltab>http://www.ics.mq.edu.au/~cassidy/papers/extreme03.html

12:55:55 <dc_rdfig> C: http://www.ics.mq.edu.au/~cassidy/papers/extreme03.html from deltab

12:55:56 <darobin> is dino coming today, or only for the next meet<,

12:56:10 <danbri> I was hoping today, but didn't respond to my pings.

12:56:13 <deltab> C:|Generalizing XPath for Directed Graphs

12:56:13 <dc_rdfig> Titled item C.

12:56:29 <darobin> ooh thanks deltab!

12:56:32 <danbri> Dean's got a good excuse, this is quite an antisocial hour in australia, i believe.

12:56:47 <darobin> it is indeed!

12:58:28 <danbri> danbri has changed the topic to: RDF+Exif image metadata chat (1300UTC for 1hr) http://esw.w3.org/topic/ImageDescription, agenda: http://rdfig.xmlhack.com/ wiki at http://esw.w3.org/topic/ irc logs http://ilrt.org/discovery/chatlogs/rdfig/latest

12:59:08 <danbri> BLURB:RDFIG RDF/Exif meeting

12:59:08 <dc_rdfig> D: RDFIG RDF/Exif meeting from danbri

13:00:07 <danbri> D:See [http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0058.html|announcement], [http://esw.w3.org/topic/ImageDescription|ESW:ImageDescription] for background materials

13:00:07 <dc_rdfig> Added comment D1.

13:00:28 <danbri> D:time: now (aka [http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=8&year=2003&hour=13&min=0&sec=0&p1=0|1300UTC for 1hr])

13:00:28 <dc_rdfig> Added comment D2.

13:01:04 <danbri> D:Goals: compare/contrast RDF/XML representations of Exif photo metadata, show'n'tell...

13:01:04 <dc_rdfig> Added comment D3.

13:01:53 <danbri> OK, hi all. Welcome to #rdfig for those new to the channel. Let's wait a couple of minutes before starting properly, for folks to arrive.

13:02:07 <verbosus> Hello danbri.

13:02:16 <danbri> Non-image metadata folks, we hereby commandeer #rdfig for the next hour! Try and stop us ;)

13:02:21 <mortenf> D:See also [http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0021.html|pointers to exif schemas]

13:02:21 <dc_rdfig> Added comment D4.

13:02:57 <danbri> A few words on infrastructure. When you see people chatting with the "dc_rdfig" bot, they're in effect writing weblog entries live into our http://rdfig.xmlhack.com/ site.

13:03:03 <bert_test> bert_test is now known as Bert

13:03:42 <danbri> We use this for agenda management and link sharing. The channel is also public and logged. Begin a line [off] if you don't want the logger to record it (though that doesn't stop it having been uttered in a public place...).

13:03:59 <danbri> Let's have an attendee list...

13:04:47 <danbri> D:Attending: [http://www.w3.org/People/DanBri/|Dan Brickley] (W3C (dayjob) / FOAF (side project)), interest in mixing Exif metadata with content description using Wordnet, SVG etc).

13:04:47 <dc_rdfig> Added comment D5.

13:05:17 <danbri> ...if you could introduce yourself in that way, the meeting record will record your attendance. List affiliations and interests if you like; otherwise just a name is fine.

13:05:18 <mortenf> D:[http://purl.org/net/morten/|Morten] present; interested in general image description

13:05:19 <dc_rdfig> Added comment D6.

13:05:30 <danbri> hey dino :)

13:05:39 <marccanter> As Pink says - let's get this Party started

13:05:43 <danbri> glad you could make it... we're just doing intros

13:05:48 <marccanter> I gues sthat's tehw rong format - huh?

13:05:53 <libby> D:attending [libby miller|http://ilrt.org/people/libby] ILRT/foaf, general images description

13:05:54 <dc_rdfig> Added comment D7.

13:05:54 <dino> hi. will be there in a second.

13:05:57 <danbri> hey marc :)

13:06:04 <novaspivack> hey

13:06:16 <danbri> Something like: "D:BlahBlah" will get picked up by the bot.

13:06:34 <chrisGoad> D: Attending [Chris Goad|http://www.mapbureau.com/cgfoaf.rdf]; also interested in general image description

13:06:34 <dc_rdfig> Added comment D8.

13:06:49 <sniffles> D:[http://unadorned.org/|Steph Troeth]; ditto

13:06:50 <dc_rdfig> Added comment D9.

13:06:55 <verbosus> D:[http://cavedoni.com/|Antonio Cavedoni] present: I'm interested in writing an application to manage my digital pictures, using EXIF and RDF as the metadata infrastructure.

13:06:55 <dc_rdfig> Added comment D10.

13:07:10 <Thorisson> Hello everybody.

13:07:33 <marccanter> D:Attending[http://blogs.it/0100198]: (West Coast/multimedia/blog nerd) Here 'cause Greg Elin asked me to, will rock teh house once the music starts

13:07:33 <dc_rdfig> Added comment D11.

13:07:34 <karlcow> D:Attending:[http://www.w3.org/People/karl/|Karl Dubost] (W3C(dayjob)) / Cow (night job), interest in having a single reference for a rdf schema language to describe pics with exif and IPTC.

13:07:34 <dc_rdfig> Added comment D12.

13:07:41 <danbri> logger, pointer?

13:07:41 <danbri> See http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-07-41

13:07:45 <novaspivack> Hey Kris

13:07:52 <marccanter> NOVA!

13:07:56 <novaspivack> Hey Mark!

13:08:03 <Thorisson> Hey Nova.

13:08:08 <novaspivack> Thanks for the lengthy email yesterday

13:08:09 <shellac> dje: attending

13:08:14 <marccanter> :-)

13:08:22 <danbri> D:See also [http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-07-41|full chat transcript]

13:08:23 <dc_rdfig> Added comment D13.

13:08:24 <marccanter> Paolo and Matt need the help

13:08:27 <Bert> D:Attending: Bert Bos (W3C), interested in using DC (and anything else that is easy to use) inside XMP inside JPEG, for my personal photo collection.

13:08:28 <dc_rdfig> Added comment D14.

13:08:33 <GregElin> D:Attending: [http://duhblog.com:8668/duhblog/space/Greg+Elin|Greg Elin] Interested in image description, metadata, new to RDF. Working on software to manage image as plurality of objects http://www.fotonotes.net/demo

13:08:33 <dc_rdfig> Added comment D15.

13:08:41 <novaspivack> Was up drinking with my brother and old friends last night.......

13:08:43 <verbosus> marccanter: I know Paolo as well (I'm from Italy).

13:08:47 <Bert> (I copied that "D:" at the start, or was that a typo?)

13:08:51 <novaspivack> this is WAY too early for me

13:08:55 <marccanter> Andiamo!

13:08:58 <GregElin> Nova...glad you made it!

13:09:09 <marccanter> dud e- it's 6 here - don;t complain

13:09:13 <danbri> OK, I see nine folks signed up, and plenty more lurkers.

13:09:27 <novaspivack> marc: Ouch! Now That's dedication

13:09:32 <Ecyrd> Good evening.

13:09:33 <deltab> Bert: 'D:' identifies this item (the fourth)

13:09:44 <pete> D:Attending [http://peterkaminski.com/|Peter Kaminski] (Socialtext, Social Software Alliance)

13:09:44 <dc_rdfig> Added comment D16.

13:09:45 <edd> Bert: looks OK to me, see http://rdfig.xmlhack.com

13:09:55 <maxf> D:Attending[http://www.w3.org/people/maxf|Max Froumentin] general interest in image annotation.

13:09:56 <dc_rdfig> Added comment D17.

13:10:01 <danbri> So, context for this gathering: various of us have been doing image description using (mostly) RDF/XML metadata, as well as toolbuilding, standards work etc.

13:10:05 <marccanter> Pete's in de house!

13:10:08 <novaspivack> I have a feeling our ubercoder Jim Wissner will not be awake for this as he codes all night usually

13:10:22 <danbri> This is a *huge* subject area, so for today's gathering we've tried to bite off a more manageable piece.

13:10:33 * dino back

13:10:45 <danbri> There was a thread on www-rdf-interest noting that we now have several different schemas for representing Exif metadata in RDF.

13:10:58 <shellac> D: attending

13:10:58 <dc_rdfig> Added comment D18.

13:11:07 <mortenf> see pointer to that thread in D3

13:11:09 <danbri> Dino was also telling me about some plans from the SVG (w3c vector graphics) group re exposing Exif metadata...

13:11:17 <mortenf> erh, D4

13:11:44 <dino> technique wouldn't be limited to SVG - just an interface to image metadata

13:11:47 <GregElin> (I should mention this is the first of two conversations planned on image data and metadata. Today we are trying to get all caught up on EXIF and RDF, two more established trends...)

13:12:07 <danbri> We don't have a particularly rigid agenda as a lot depends on the interests of who turned up, but my hope is we can make some progress towards converging on a common representation of Exif in RDF/XML, and understand that in the wider picture of image metadata.

13:12:17 <libby> image metadata in an image dino?

13:12:37 * danbri nods re Greg's point; several of us agreed also to meet up next week see http://esw.w3.org/topic/ImageDescription,

13:12:44 <dino> yep. could be anything, not just EXIF.

13:12:59 <danbri> OK, so to tighten up agenda, does anyone want to bid for a specific agenda slot.

13:13:16 <danbri> I'd like to hear from dean (dino) about SVG's plans...

13:13:29 <danbri> Who else here has worked on a specific Exif/RDF representation?

13:13:31 <mortenf> i'd like to ask karl if he has any specific plans re a unified exif schema?

13:13:40 <libby> next meet is in 2 weeks by the way....http://www.timeanddate.com/worldclock/fixedtime.html?day=27&month=8&year=2003&hour=14&min=30&sec=0&p1=0

13:13:43 <pete> can i suggest audio back channel at +1-702-851-4040, passcode 73344 ("rdfig")?

13:14:08 <danbri> Pete, that's a little expensive for non-americans... though thanks for the offer

13:14:11 <GregElin> I'd like a quick overview of where EXIF stands and is going.

13:14:18 <pete> optional, of course

13:14:25 <dino> I'd like some background on existing EXIF/RDF representations

13:14:50 <pete> i'm happy to dial out to 1 international attendee, too

13:14:53 <karlcow> - Issues about copyright: Any?

13:14:58 * dino searching for information forwarded to him by Kodak.

13:15:03 <karlcow> - Issues about vocabulary choices

13:15:11 <karlcow> - Issues about XML/RDF

13:15:15 <skimpIzu> whats a fig ?

13:15:26 <karlcow> - Issues about versioning.

13:15:30 <danbri> see http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0021.html for a list of existing schemas

13:15:38 <libby> an rdf interest group skimpizi

13:15:41 <libby> an rdf interest group skimpizu even

13:15:55 <danbri> D:Agenda fodder: SVG update; Copyright issues; Versioning; ...

13:15:55 <dc_rdfig> Added comment D19.

13:15:57 <skimpIzu> sorry! a little tired. thought extra 'f'

13:16:15 <hendry> .time EST

13:16:16 <datum> Wed, 13 Aug 2003 08:16:16 EST

13:16:37 <danbri> Karl, I suspect we'll run into more questions than answers today, so I'm looking to collection questions/issues and have folk volunteer to go away and try to progress them. Does that make sense?

13:16:45 <mortenf> i've been playing around with exif, created a [http://www.wasab.dk/morten/2003/07/sempex/|Perl script] that emits rdf, using the schema at http://www.kanzaki.com/ns/exif (and Image::Info, RDF::Redland)

13:16:52 <verbosus> karl, danbri: is it possible to have someone from the EXIF wg for next scheduled chat?

13:17:15 <karlcow> yes danbri. Complete sense. I propose you are the chair and open and close the agenda item.

13:17:19 <danbri> that would make sense. I sorta wanted to get our own house in order a bit and look into state of what we have...

13:17:53 <danbri> Current RDF schemas for Exif include: Kanzaki's, Gerald's, Karl's, TimBL's, Norm's ...

13:18:03 <danbri> I have one too, but it was a nasty hack.

13:18:44 <danbri> OK, given the time in Australia, I propose we hear from Dean first; meanwhile folks can multi-task and take a look at the schemas in http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0021.html while listening attentively to Dean

13:18:45 <dino> which is the least nasty? :)

13:18:55 <dino> thanks! :)

13:19:00 <danbri> Dean, good question! Let's have a beauty contest later in the chat.

13:19:10 <danbri> Dean, 10 mins on SVG incl questions?

13:19:22 <danbri> logger, pointer?

13:19:22 <danbri> See http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-19-22

13:19:39 <dino> ok, you don't need to know anything about SVG here, apart from the fact that it is a client side technology that does lots of stuff with images.

13:19:51 <skimpIzu> why does man imagemagick not show exif

13:19:55 <dino> and as well all know, many images nowadays are dig photos.

13:20:17 <dino> also, most people use SVG in a scripting environment

13:20:19 <danbri> D:[http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-19-22|SVG + image metadata] (Dean)

13:20:19 <dc_rdfig> Added comment D20.

13:20:40 <dino> so lots of programmers want access to image metadata (EXIF is only a part of that)

13:21:10 <verbosus> TimBL schema is 404: http://www.w3.org/2000/10/swap/pim/exif#

13:21:21 <dino> anyway, lots of people have asked for a standard way to get to the metadata of an included image

13:21:23 <danbri> timbl-- #f'shame

13:21:49 <dino> and the SVG working group are happy to take it on

13:22:00 <danbri> dean, OK cool. So the XML DOM (or SVG DOM) is expected way of interacting with this?

13:22:04 <dino> (we have lots of imaging companies there - Canon, Kodak, etc)

13:22:14 <skimpIzu> why does man imagemagick not show exif

13:22:25 <dino> well, my current feeling is that it should be exposed as an XML DOM

13:22:35 <dino> just for consistency

13:22:45 <dino> since other images in SVG will be exposed that way

13:23:01 <danbri> More on SVG for those without google: http://www.w3.org/Graphics/SVG/Overview.htm8

13:23:16 <danbri> Can you briefly explain 'XML DOM' vs 'SVG DOM'?

13:23:18 <dino> however, we could also define a DOM interface that allows get() on EXIF stuff

13:23:28 <verbosus> skimpIzu: AFAIK imagemagik doesn't grok EXIF at all. It can preserve it while operating on an image, but it can't read/manipulate it.

13:23:42 <dino> XML DOM is defined for all XML grammars

13:23:49 <dino> SVG has an XML DOM

13:24:07 <dino> and also an extended DOM, kind of a generic graphics API

13:24:09 <danbri> This is interesting as not clear how generic you'll want to make this. Exposing Exif would be awesome, but could we also expect to access metadata about the _content_ of the image? (like <foaf:depicts><wordnet:Cat foaf:name="Tom"/></foaf:depicts>)...

13:24:12 <dino> just does the graphics stuff

13:24:14 <danbri> ...the latter seems much more ambitious

13:24:25 <dino> yes, definitely

13:24:38 <dino> like I said, EXIF really isn't all that common a request

13:24:51 <dino> many other image formats have more useful metadata

13:25:06 <dino> medical images, aerial photos with geo references, etc

13:25:08 <danbri> ...since describing the content of an image is a very underconstrained task; "describing stuff that is in a picture" isn't interestingly more constrained than "describing stuff", ie. arbitrary properties are pertinent.

13:25:19 <libby> interesting....

13:25:38 <dino> if anyone (Jim) wants to give an opinion please do

13:25:44 <Bert> In fact, why not a Web DOM instead of a XML DOM? JPEG is not XML but has metadata, too

13:26:02 <dino> now, the way w3c works usually is some fool (ie SVG) takes this on, and hopefully everyone else reviews and then uses

13:26:03 <danbri> So, if the SVG WG do this properly (imho), they'll in effect have a slot where we could have a simple RDF API for scripters? Since much image metadata work is done at the RDF level...

13:26:05 <karlcow> It's why IPTC, NEWSML, RDFPIC etc have format for describing images

13:26:09 <dino> it wouldn't be specific to SVG of course

13:26:13 <GregElin> what do you mean, Dan

13:26:16 <JibberJim> Hi, I'd be happy I think just with a get("EXIFNAME") as it's all read only data, we're not going to update it or anything.

13:26:22 <karlcow> EXIF is good on the technical part.

13:26:56 <dino> imo, exif doesn't give you much interesting stuff.

13:27:05 <verbosus> JibberJim: one may want to edit the UserComments field.

13:27:06 <dino> at least, not much that you'd really want on the client

13:27:08 <danbri> EXIF is sorta boring but essential, and I undestand people are stuffing geo info in there now, so it is increasingly interesting.

13:27:22 <JibberJim> A full XML vocab isn't necessary for just read only, (we could edit it, but how would we save it?)

13:27:28 <danbri> My only use for Exif to date has been auto-rotating pictures from my (sadly lost) Canon.

13:27:44 <danbri> Ah yep, good question. Read-only makes things simpler.

13:28:05 <Bert> Readonly: hmm, but a std way to do read/write would be nice, too. I could use somebody else's library.

13:28:06 <dino> maybe Bert could speak up about the EXIF orientation bit, but there were plans for that to be honoured natively.

13:28:06 <karlcow> EXIF will be interesting for technical profession, people who keeps records of the parameters of the image, speed, etc... like astrophysicists for example.

13:28:23 <verbosus> danbri: one may also want to edit the last modified date of a picture

13:28:24 <danbri> So Dean, given time constraints today, how can imagey folks and rdfy folks and RDF/imagey folks track, participate etc...

13:28:26 <danbri> ?

13:28:30 <karlcow> Another format for description is interesting too (IPTC like or more complete)

13:28:32 <JibberJim> As long as height/width is also honoured natively!

13:28:35 <dino> umm.. good question.

13:28:50 <_joshua> Hi

13:28:52 <dino> i guess there will be something in SVG 1.2 drafts soon

13:29:09 <danbri> I'd love to see a requirements doc from SVG WG that we could review...

13:29:10 <dino> but if there is enough interest, then we could split it out as a note or something.

13:29:18 <dino> remove it from SVG.

13:29:20 <libby> hi _joshua

13:29:23 <_joshua> What'd I miss?

13:29:36 <dino> the good thing is that we have a few people that are really into this stuff.

13:29:42 <danbri> _joshua, see logs linked from rdfig.xmlhack.com

13:29:45 <libby> dino is telling us about images and svg and exif

13:29:45 <dino> Canon and Kodak obviously

13:29:49 <hendry> GregElin: I need to be off. I don't think I can contribute to any EXIF issues besides. So perhaps later this month!

13:29:49 <dino> but also Adobe

13:29:50 <karlcow> dino, I think it might give it more publicity and make it possible for people to reuse it.

13:29:54 * danbri nods

13:29:59 <mortenf> _joshua, see logs: http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13.html

13:30:00 <danbri> ok hendry, thanks for coming

13:30:11 <dino> The Adobe SVG team are the same team that developed Photoshop ALbum

13:30:13 <_joshua> Gotcha.

13:30:19 <JibberJim> EXIF is I think relatively simple and whilst essential is not that useful, XMP is more exciting.

13:30:21 <dino> so they know exif quite well.

13:30:23 <libby> more general image description stuff next time hendry

13:30:43 <dino> however, they will tell you that there is a lot of variation in the EXIF spewed out by today's cameras

13:30:44 <danbri> Dino, are you convinced that image metadata problems shade into general descrition issues: if you're describing a picture of a Sheep called 'Dolly', you should be using the same markup as someone who is describing a Sheep called 'Dolly'...

13:30:47 <verbosus> JibberJim: yes, but how many digicams use XMP now?

13:30:56 * danbri notes we're over 10 mins on this

13:31:01 <_joshua> I have a dumb question: is it more interesting to extract EXIF data and represent it outside the image files, or is it more interesting to keep metadata in the file itself?

13:31:05 <danbri> Ah, glad you mentioned XMP.

13:31:06 <Bert> (EXIF Orientation field is a bit of a problem in practice, since it is hard to predict which software honours it and which doesn't. The people making photo printers have tried to resolve that with CSS, but that doesn't really improve it.)

13:31:07 <JibberJim> IS EXIF an evolving standard, can people add new fields to it?

13:31:09 <dino> i'll shut up now!

13:31:14 <danbri> XMP is Adobe's metadata framework thing.

13:31:23 <dino> EXIF is evolving

13:31:24 <_joshua> Also, what about TIFF metadata (GeoTIFF, etc)

13:31:32 <danbri> Dean, do you have any sense for how XMP is connected (or not) to the SVG work within Adobe?

13:31:36 <_joshua> I thought EXIF is key->value

13:31:40 <dino> actually EXIF is just TIFF metadata if I'm not mistaken

13:32:02 <dino> XMP and SVG are not too related within Adovbe

13:32:13 <_joshua> Gotcha

13:32:14 <dino> apart from the Illustrator team embedding XMP in SVG export.

13:32:15 <danbri> Is there someone here who could offer a polite but critiquing commentary on the schemas listed in http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0021.html ?

13:32:18 <JibberJim> I thought so to, but that means trying to specify an XML DOM that's not a get(" ") is likely to not be too easy.

13:32:36 <_joshua> I still like (was it Jim's idea?) of embedding SVG in EXIF

13:33:06 <danbri> dino, thanks for the SVG update. Having script access to this would be awesome. Let's try to make sure RDFIG & co review the next drafts...

13:33:19 <dino> another thing we're looking into is accessing embedded copyright info in images.

13:33:20 <karlcow> JibberJim EXIF, is a binary format. key -> value for images. The specs are evolving :) and progress, new elements are added. http://www.exif.org/

13:33:49 <danbri> D:See also [http://www.exif.org/|Exif website].

13:33:50 <dc_rdfig> Added comment D21.

13:33:59 <karlcow> danbri, on the list of proposed schema only two are really usable now :)

13:34:13 <verbosus> danbri, about the schemas

13:34:15 <danbri> which ones? :)

13:34:19 <verbosus> TimBL is 404

13:34:22 <karlcow> Th one from Norman Walsh

13:34:27 <danbri> are we done with SVG? Any probing questions for Dean?

13:34:33 <karlcow> The one from kanzaki.

13:34:36 <danbri> ----

13:34:37 <verbosus> Gerald and Karl do not seem proper RDF schemas, actually.

13:34:48 <GregElin> what is the timeline for SVG?

13:34:53 * dino moves to lurker mode.

13:34:55 <verbosus> So the options are either nwalsh's one, or kanzaki's one.

13:34:56 <danbri> thanks Dean! :)

13:35:02 <karlcow> The problem of the kanzaki one is that youhave a lot of kanjis in it ;)

13:35:04 <JibberJim> Has to be by March for 1.2 GregElin

13:35:05 <danbri> (for coming, not lurking)

13:35:19 <verbosus> karlcow: yup. Do you know any japanese? :-)

13:35:36 <GregElin> what aare the details for 1.2 - what does it include (or where is the link)?

13:35:39 <dino> has anyone heard of DIG35

13:35:40 <dino> ?

13:35:41 <danbri> Kanzaki's done some really nice work on RDF stuff, docs etc.

13:35:50 <dino> that's the most official image metadata thing I know of

13:35:52 <danbri> I don't know much about DIG35, it rings a bell, that's all.

13:35:55 <karlcow> For mine, I was starting to make one, but I have stopped when I have discovered that other people were doing it. and so decided to try to start a common effort on it.

13:36:02 <karlcow> More effective that way.

13:36:03 <danbri> logger, pointer?

13:36:03 <danbri> See http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-36-03

13:36:14 <dino> and also specifies how to embed EXIF as XML

13:36:16 <verbosus> In kanzaki's one he wrote some descriptions in japanese.

13:36:22 <karlcow> So if we could define a common format it would be very nice.

13:36:25 <danbri> D:Exif RDFS beauty contest [http://ilrt.org/discovery/chatlogs/rdfig/2003-08-13#T13-36-03|compare and contrast].

13:36:25 <dc_rdfig> Added comment D22.

13:36:36 <_joshua> Another metadata standard?

13:36:40 <verbosus> But I reckon it could be easy to translate them and ask him to add them to his schema.

13:36:49 * dino looks for DIG35 info - but from memory it is a private consortium (like W3C)

13:36:53 <danbri> So, TimBl's 404s. Kanzaki's looks good. DIG's EXIF-in-XML needs looking at.

13:37:15 <_joshua> dig35 is http://www.i3a.org/i_dig35.html and appears to be a for-pay standard!

13:37:18 <danbri> Gerald's? Any issues there?

13:37:18 <karlcow> As I said at the start, EXIF is not enough, EXIF is one of the brick of a meta Image description format

13:37:30 <mortenf> it seems nwalsh's is a subset of kanzaki's, except for tag ids

13:37:33 <_joshua> who is i3a?

13:37:36 <GregElin> Right, karlcow.

13:37:41 <dino> I also remember a sourceforge project for DIG35 stuff

13:37:42 <karlcow> but we could come with small schemas for format like EXIF and others and combine them when needed.

13:38:04 <verbosus> Yeah mortenf. How about integrating nwalsh's descriptions into kanzaki?

13:38:07 <mortenf> yep, starting with exif sounds reasonable, then move

13:38:08 <danbri> OK, yes... so there are two reasons why DIG doesn't appeal to me. Pay for (if that's the case); also being XML but not RDF, we can't easily mix it with other image metadata.

13:38:19 <mortenf> good idea, how would ge go about that?

13:38:34 <karlcow> So I guess if we start a new format we will have to have kanzaki participating and Norman Walsh

13:38:34 <dino>http://picturemetadata.sourceforge.net/

13:38:35 <dc_rdfig> E: http://picturemetadata.sourceforge.net/ from dino

13:38:36 <danbri> So is main issue with Kanzaki's purely that of getting more english documentation?

13:38:45 <_joshua> there's hardly any material on the web about dig35

13:38:48 <danbri> He does show up here or in #foaf sometimes, btw.

13:38:54 <karlcow> Norman Walsh has already proposed to implement any format we will come with

13:39:06 <verbosus> danbri, can we validate his schema before starting to use it?

13:39:09 <dino> E| C++ library for DIG35

13:39:09 <mortenf> even if it has japanese descriptions, it still has some english in there

13:39:21 <danbri> verbosus, which sense of validate?

13:39:23 <GregElin> But does EXIF provider the means to easily carry data across cameras,etc?

13:39:25 <dino> E:| C++ library for DIG35

13:39:25 <dc_rdfig> Titled item E.

13:39:36 <danbri> Kanzaki's looks like a good start.

13:39:39 <verbosus> danbri: see if it is well-formed RDFS.

13:40:15 <karlcow> danbri: I can work with kanzaki to make an english version of its schema, and so we could discuss if people identify issues.

13:40:26 <verbosus> GregElin: that's a big problem. With the common python libraries out there I can't extract some EXIF from my Canon.

13:40:30 <danbri> An attempt to load the RDF from URI 'http://www.kanzaki.com/ns/exif' failed. (Cannot open stream.)

13:40:36 <danbri> ---tried RDF validator on it. strange.

13:40:46 <danbri> karl, that's excellent.

13:40:47 <mortenf> karlcow, that sounds great; what about the "issues" you listed before?

13:41:00 <verbosus> karlcow: good!

13:41:08 <danbri> OK, any objections to proceeding with that? Sounds like Kanzaki's version won the beauty contest...

13:41:15 <marccanter> who invented/created EXIF?

13:41:41 <karlcow> marccanter: EXIF is the result of a camera industry consortium

13:41:49 <karlcow> mostly japanese

13:41:49 <danbri> Karl, can you take an action to review Kanzaki's schema, check it validates, and add English translations where needed?

13:41:54 <marccanter> I assume they're not clued into RDF?

13:41:55 <dino> EXIF is not as portable amongst cameras as you would think

13:41:55 <danbri> (I can help w/ the translation)

13:41:58 <karlcow> Yes :) danbri

13:42:05 <dino> the Adobe PS Album team complained about this

13:42:17 <verbosus> dino: yeah, that's a big problem.

13:42:27 <JibberJim> Anything with Kanji in is normally more beautiful than English letters....

13:42:28 <verbosus> dino: that's why I suggested having EXIF people in the meeting.

13:42:29 <danbri> ACTION: Karl to review Kanzaki's schema, check it validates, and (w/ danbri) help w/ any English translations needed

13:42:29 <dc_rdfig> Label ACTION not found.

13:42:33 <dino> not everyone uses the same field for the same thing, sometimes they don't use the correct value, etc.

13:42:43 <pete> marc: JEIDA ( Japan Electronic Industry Development Association ).

13:42:48 <verbosus> dino: maybe you could point this problem to the Canon/Kodak people you know.

13:42:59 <dino> normally, each manufacture only goes as far as testing in their own photo software

13:43:08 <_joshua> someone at adobe griping about tiff and exif: http://remotesensing.org/lists/libtiff_archive/msg01769.html

13:43:09 <mortenf> hmm, perhaps we should do a (small) survey of field usage per manufacturer?

13:43:23 <karlcow> :) Interoperability problem and people not respecting specs... hmm bizarre ;)

13:43:39 <pete> here's a summary page summarizing lots of these image metadata standards: http://peccatte.karefil.com/Software/Metadata.htm (in French, though, sorry)

13:43:48 <danbri> I'd like to offer to Kanzaki that we host his version of the namespace at a www.w3.org URI, since we can provide long-lived uris... Does that seem a useful thing to do?

13:44:01 <mortenf> indeed

13:44:05 <verbosus> danbri: +1

13:44:15 <karlcow> Yes I think danbri, it's much needed +1

13:44:41 <danbri> If he prefers to self-host, that's cool, but I think people are looking for something (albeit informal) at somewhere like W3C, to stop the proliferation of overlapping / redundant schemata.

13:44:57 <dino> danbri, that would help SVG. Right now, there is a feeling that we don't need RDF to expose EXIF. So anything on the w3.org site would help.

13:45:14 <verbosus> Also, is there any kind of license on kanzaki's work?

13:45:18 <danbri> Any objections to my inviting Kanzaki's to help move a copy of his schema to w3.org-hosted namespace URI?

13:45:34 <karlcow> nope

13:45:38 <danbri> dino, that's good to know.

13:45:42 <danbri> Hearing no objections:

13:45:44 <mortenf> how'd "we" update it?

13:45:55 <marccanter> go 4 it!

13:45:56 <danbri> ACTION: danbri to invite Kanzaki's to help move a copy of his schema to w3.org-hosted namespace URI

13:45:56 <dc_rdfig> Label ACTION not found.

13:46:15 <danbri> MortenF, that's a good question. We have some precedents with www-rdf-calendar collaboration, perhaps something like that.

13:46:21 <danbri> Libby, got a pointer / quote to how that is done?

13:46:40 <mortenf> ok, i was also thinking of copyright / process

13:46:46 <libby> links : [blabla|http:///hgfdgh]

13:46:51 <karlcow> mortenf, we can proceed with a mailing-lis for discussion.

13:46:57 <libby> either way works.

13:47:02 <verbosus> mortenf: how about something like the RSS 1.0 WG?

13:47:21 <danbri> s...o...m...e...thing like that. RSS1 WG had issues (I guess mostly political).

13:47:23 <libby> see chump manual: http://usefulinc.com/chump/MANUAL.txt

13:47:30 <mortenf> anything's fine, just as long as it's not "stuck" somewhere at some point

13:47:38 <_joshua> D: [http://peccatte.karefil.com/Software/Metadata.htm|french document explaining various iamge metadata formats], lots of good links even if you do not speak french.

13:47:39 <dc_rdfig> Added comment D23.

13:47:44 <verbosus> danbri: you have more experience than us on this one, any suggestions?

13:47:44 <danbri> I would look for something consensual, lightweight, not at this stage a working group. The RDF Calendar collaboration is the closeest I've seen.

13:48:01 <_joshua> pete: good link, thank you

13:48:24 <danbri> see http://www.w3.org/2002/12/cal/ [[

13:48:25 <danbri> At the Bristol workshop, we agreed, roughly...

13:48:25 <danbri> * we announce all changes to the schema www-rdf-calendar

13:48:25 <danbri> * if anyone screams, within a week or so, we'll back out the changes (for further discussion)

13:48:27 <mortenf> iirc, the calendar phrasing was something like "no objections within a week, accepted"

13:48:28 <danbri> If the last modified dates below are more than a few months old, active developments have likely ceased. If things ever actually stabilize, we'll change this status message.

13:48:31 <danbri> ]]

13:48:33 <danbri> for how we agreed to do the rdf cal thing.

13:48:33 <mortenf> :)

13:48:33 <libby> gets some data, do soem tests, generayte a schema from data?

13:48:42 <danbri> yup. it's all in cvs so can be rolled back

13:49:12 <libby> generating schema from data is fun; or at least getting a guide to the schema form the data

13:49:15 <_joshua> what's IPTC?

13:49:21 <danbri> The big motivation, to my mind, is to get an Exif ns nailed down so we can move on to the interesting stuff: mixing Exif image metadata with other metadata about the image, the where/when/who/what of its content and context...

13:49:40 <danbri> OK, we have 10 minutes left. I'm open to suggestions re how to use that.

13:50:03 <mortenf> one more thing re exif schema: i'd like for a set of controlled textual values, instead of numeric codes

13:50:14 <_joshua> I'd like to see some project idea brainstorming, just to explore the space of what could be done

13:50:20 <danbri> In http://rdfig.xmlhack.com/ I noted Agenda fodder: SVG update; Copyright issues; Versioning; ...

13:50:32 <danbri> We've had SVG update...

13:50:34 <karlcow> IPTC = International Press Telecommunications Council

13:50:40 <_joshua> Right, I googled for it.

13:50:43 <GregElin> SVG update?

13:50:54 <karlcow> It's a press professional organisation which has created standards

13:51:00 <karlcow> for describing information

13:51:00 <verbosus> mortenf: you mean the ability to access a field by its name instead of its EXIF code?

13:51:03 <danbri> (Dean's mini-resentation earlier updated us re SVG)

13:51:26 <danbri> MortenF, I'm sympathetic to that (textual values); I wonder Kanzaki's view esp re I18N. Will ask.

13:51:31 <mortenf> verbosus: well, instead of orientation:0 i'd like orientation:top/left

13:51:38 <mortenf> good point...

13:51:41 <dino> not specific to SVG, just that we're most likely the group that will do something soonest

13:51:44 <karlcow> I have a question for the schema.

13:51:48 <_joshua> D: [http://www.iptc.org/site/standards.html|IPTC standards] - assuming it's the "JPEG File Information" bit.

13:51:49 <dc_rdfig> Added comment D24.

13:51:50 <karlcow> Which versions of EXIF?

13:52:07 <danbri> I guess someone needs an action to investigate (c)/IP issues if we're looking to host Exif-based schema on w3.org.

13:52:23 <mortenf> it seems exif version only add new fields, no changes, can anyone confirm?

13:52:27 <danbri> ACTION: danbri to investigate copyright/IP issues re hosting an Exif-based RDF schema at W3C.

13:52:27 <dc_rdfig> Label ACTION not found.

13:52:33 <verbosus> karlkow

13:52:41 <verbosus> kanzaki's mentions EXIF 2.2

13:52:44 <verbosus> ">Vocabulary to describe an Exif format picture data. All Exif 2.2 tags are defined as RDF property as well as several supporting terms."

13:52:47 <libby> danbri, useful to attach actaions to chump?

13:52:58 <danbri> Libby, yes. Could you gimme a hand doing that?

13:53:16 <karlcow> ok we will go with that version but making it clear that this is the schema for this version.

13:53:24 <danbri> Versioning... traditionally a can of worms. Would someone here have time to take a look into versioning situation and report back to www-rdf-interest?

13:53:32 <libby> BLURB:exif/rdf actions

13:53:32 <dc_rdfig> F: exif/rdf actions from libby

13:53:32 <karlcow> :) and we can define another schemas later on for legacy documents.

13:53:56 <danbri> (btw we should use www-rdf-interest as mailing list for this, currently... until traffic suggests a need for a distinct fora)

13:53:57 <mortenf> hmm, karlcow, i think we'd want a stable namespace uri, no versioning

13:53:58 <Thorisson> Does anyone know of efforts to describe geometric shapes in RDF?

13:54:08 <danbri> A purely additive namespace works for me.

13:54:17 <chrisGoad> I made a modest SVG-based start on this:

13:54:17 <chrisGoad> [http://www.mapbureau.com/rdfgeom2d1.0/revision2.html|http://www.mapbureau.com/rdfgeom2d1.0/revision2.html]

13:54:18 <mortenf> ... as long as we only add to it

13:54:26 <danbri> Thorisson, some of us (Jim,Libby, myself) have been bastardising SVG for this purpose.

13:54:32 <libby> F:<danbri> ACTION: Karl to review Kanzaki's schema, check it validates, and (w/ danbri) help w/ any English translations needed

13:54:32 <dc_rdfig> Added comment F1.

13:54:37 <danbri> To describe image overlays, regional annotations etc.

13:54:46 <libby> F:<danbri> ACTION: danbri to invite Kanzaki's to help move a copy of his schema to w3.org-hosted namespace URI

13:54:46 <dc_rdfig> Added comment F2.

13:54:50 <_joshua> It would seem to me that this has been done and redone and redone.

13:54:52 <Thorisson> danbri: do you have any pointers so I can read up on that?

13:55:00 <libby> F:<danbri> ACTION: danbri to investigate copyright/IP issues re hosting an Exif-based RDF schema at W3C.

13:55:00 <dc_rdfig> Added comment F3.

13:55:04 <_joshua> chrisGoad: were you the one that did the GML -> RDF translation?

13:55:06 <verbosus> danbri, mortenf: is there a way in RDFS to say something like <rdfs:seeAlso>new schema</>?

13:55:08 <danbri> Jim, Libby, got pointers?

13:55:13 * JibberJim still hasn't got round to looking at chrisGoad's RDF schema.

13:55:16 <danbri> yes, you could do that

13:55:16 <chrisGoad> Yes, that's me

13:55:19 <mortenf> verbosus, with OWL, yes

13:55:33 <verbosus> ok, then just one NS URI is fine.

13:55:35 <libby> danbri, not with svg, that's jim's stuff... :)

13:55:36 <danbri> OK, t-5 minutes, time to wrap up...

13:55:39 <chrisGoad> I'll chump it

13:55:41 <GregElin> Verbosus: I *like* the idea of a SEE ALSO

13:55:47 <verbosus> And then we can seeAlso the new ones.

13:55:49 <_joshua> chrisGoad: cool; i'm just starting to get into that

13:55:52 <chrisGoad> D:[http://www.mapbureau.com/rdfgeom2d1.0/revision2.html|http://www.mapbureau.com/rdfgeom2d1.0/revision2.html]

13:55:53 <dc_rdfig> Added comment D25.

13:56:02 <mortenf> OWL has a mechanism for versioning schemas

13:56:12 <libby>http://jibbering.com/svg/AnnotateImage.html

13:56:12 <dc_rdfig> G: http://jibbering.com/svg/AnnotateImage.html from libby

13:56:13 <pete> want to point to an EXIF resources page on my wiki: http://www.istori.com/cgi-bin/wiki?CoolStuff/Exif

13:56:23 <danbri> So to summarise... we've had an update from Dean re the SVG WG's ambitions to expose (all, not just exif) image metadata via a DOM-based API.

13:56:32 <libby> G:|Jim Ley's SVG image area annotation service

13:56:32 <dc_rdfig> Titled item G.

13:56:42 <danbri> ...we've had an exif-in-rdf beauty contest, looking at the different schemas currently proposed.

13:56:45 <JibberJim> G: [http://jibbering.com/rdf/example.rdf|Example RDF it produces]

13:56:45 <dc_rdfig> Added comment G1.

13:56:50 <danbri> ...from which Kanzaki's emerged the winner.

13:57:08 <danbri> ...we have actions on Karl and myself to try to progress a w3.org-hosted namespace based on that schema

13:57:23 <Thorisson> chrisGoad: Thanks!

13:57:25 <danbri> ...and I'm looking for a volunteer to investigate versioning issues.

13:57:25 <libby> D:[http://www.istori.com/cgi-bin/wiki?CoolStuff/Exif|pete's exif resources page]

13:57:26 <dc_rdfig> Added comment D26.

13:57:29 <danbri> t-3 mins.

13:57:42 <JibberJim> G: [http://jibbering.com/2002/3/svg/#|dodgy schema] Needs Work!

13:57:42 <dc_rdfig> Added comment G2.

13:57:53 <mortenf> i think a set of test files based on diff cameras would be nice, to see variation etc.

13:58:01 <danbri> Next imaging chat is in two weeks... http://esw.w3.org/topic/ImageDescription has pointer. SVG + Image Description at 10:30 AM EST (New York Time) = 1430 UTC, Wednesday August 27

13:58:14 <verbosus> mortenf: I seem to recall there is already something like that.

13:58:20 <danbri> ...hope to have some progress to report their re Exif work, but mainly focus on describing content of images.

13:58:21 <mortenf> really?

13:58:29 <libby> so that's a pretty general chat danbri - not just svg - any image description?

13:58:32 <verbosus> mortenf: let me google a bit.

13:58:36 <Bert> Is anybody writing an EXIF-to-RDF and vice-versa converter? Would be nice if that converter could then be a plug-in in the DOM that Dean proposed. And that DOM could in fact have a plug-in API, since W3C wants to work on plug-ins...

13:58:37 <mortenf> thx

13:58:39 <karlcow> Thank you danbri for being the chair on this meeting.

13:58:40 <GregElin> I hope we can pull back to more general level for Image Description chat. Really just see who is doing what.

13:58:46 <danbri> Thorrison, I'll circulate some stuff before then that I think you'll be interested in.

13:58:49 <libby> thanks danbri

13:58:51 <GregElin> Not a beauty contest -- more like a social mixer.

13:58:54 <danbri> Yes, not just SVG. we should clarify wiki on that front.

13:58:54 <verbosus> danbri: thanks!

13:59:02 <GregElin> Thank you very much, Danbri!

13:59:08 <danbri> Yeah, I was joking re beauty, didn't mean to imply the other schemas were ugly.

13:59:16 <danbri> They're all special... in their own way :)

13:59:23 <dino> Bert, vice-versa would be interesting.

13:59:25 <mortenf> there's an exif->rdf extractor at http://www.wasab.dk/morten/2003/07/sempex/

13:59:33 <verbosus> mortenf: http://www.ba.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html ?

13:59:46 <GregElin> Bert: I like the way you think. An Exif to RDF converter would be great.

13:59:46 * mortenf reads

13:59:48 <_joshua> Anyone have a test dataset of exif?

13:59:54 <_joshua> Images with encoded data?

14:00:09 <verbosus> _joshua: look at the RDFpic project.

14:00:11 <Bert> Vice-versa would be interesting, since I have a program that creates a GUI from an RDFS. I woul dbe able to use that to write EXIF :-)

14:00:15 <danbri> OK, let's try finish a meeting on time for once! Let's call this adjourned and continue in an image-centric exifish afterglow if folks still interested in chatting...

14:00:28 <libby> D:[mortenf's exif to rdf extractor|http://www.wasab.dk/morten/2003/07/sempex/]

14:00:28 <danbri> Thanks everyone for coming! I think we made some progress :)

14:00:28 <dc_rdfig> Added comment D27.

14:00:29 <danbri> cheers.

14:00:30 <mortenf> thanks, chair

14:00:36 <Thorisson> Cheers!

14:00:40 <danbri> ADJOURNED. ////////

14:00:41 <pete> thanks, dan!

14:00:43 <verbosus> good work danbri!

14:00:52 * danbri rests his wrists

14:01:06 <libby> D:[more exif information and references|http://www.ba.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html]

14:01:08 <dc_rdfig> Added comment D28.

14:01:09 <_joshua> verbosus; is there stuffi n the source file?

14:01:12 <GregElin> And thank you all for attending.

14:01:16 <marccanter> ciao now Raging Cows

14:01:16 <_joshua> er, distribution

14:01:17 <danbri> danbri has changed the topic to: post-exif imaging chat http://esw.w3.org/topic/ImageDescription, agenda: http://rdfig.xmlhack.com/ wiki at http://esw.w3.org/topic/ irc logs http://ilrt.org/discovery/chatlogs/rdfig/latest

14:01:23 <verbosus> ciao Marc!

14:01:27 <danbri> Yes, 73 people in #rdfig, is perhaps a record :)

14:01:28 <_joshua> GregElin: when do you want to get together?

14:01:39 <verbosus> Is there a list of the EXIF libraries out there?

14:01:42 <danbri> Karl, thanks for being suckered into doing more work on this :)

14:01:43 <_joshua> And, should I start organizing NYC ClueCon?

14:01:48 <GregElin> I'm free Thursday or Friday.

14:01:50 <verbosus> I'm unsatisfied with the Python ones I've found :-(

14:01:51 <karlcow> you are welcome ;)

14:02:08 <_joshua> I am tinkering with jhead right now

14:02:16 <danbri> Oh, and Happy Birthday to Dean!

14:02:32 <_joshua> verbosus: there's nothing in the rdfpic distribution

14:02:56 <dino> i have to say this is the strangest way I've ever gained a year.

14:03:05 <danbri> danbri has changed the topic to: post-meeting imaging chatter http://esw.w3.org/topic/ImageDescription, agenda: http://rdfig.xmlhack.com/ wiki at http://esw.w3.org/topic/ irc logs http://ilrt.org/discovery/chatlogs/rdfig/latest

14:03:06 <verbosus> _joshua: AFAIK that is a software to embed RDF into jpegs.

14:03:11 <danbri> dino++

14:03:18 <dino> I feel much older after this discussion.

14:03:23 <libby> heheh

14:03:29 <danbri> you escaped w/out any action items :)

14:03:39 <_joshua> verbosus: gotcha. I want to see some in-the-wild stuff

14:04:06 <_joshua> Ooh, I have an idea

14:04:28 <_joshua> BLURB: quick and dirty camera manufacturer EXIF support survey idea

14:04:28 <dc_rdfig> H: quick and dirty camera manufacturer EXIF support survey idea from _joshua

14:04:47 <_joshua> H: use http://diddly.com/random/ to fetch some random pictures

14:04:48 <dc_rdfig> Added comment H1.

14:04:53 <mortenf> verbosus, i've actually seen that doc before, but i've noticed that my relatively new camera only uses a subset of the defined fields, and imagined that others would do the same. What i'd like is a way to "join" separate but identical fields into one in the schema

14:04:53 <verbosus> _joshua: that was what mortenf was asking a while ago.

14:05:10 <_joshua> H: identify manufacturer by filename via http://diddly.com/random/about.shtml

14:05:10 <dc_rdfig> Added comment H2.

14:05:23 <verbosus> mortenf: what camera?

14:05:36 <mortenf> canon 10d

14:05:58 * danbri reviews http://rdfig.xmlhack.com/ notes

14:05:59 <verbosus> I have a Canon G3 and some EXIF libraries out there choke on its metadata.

14:06:32 <verbosus> mortenf: is it canon's fault? ;-)

14:06:42 <danbri> edd, have you ever gotten Exif out of your p800 pics? my extraction tool finds nothing...

14:06:57 <mortenf> heh, could be, i guess they don't adhere to standards

14:07:16 <pete> http://www.breezesys.com/BreezeBrowser/ is *great* Canon image-handling software

14:07:16 <dc_rdfig> I: http://www.breezesys.com/BreezeBrowser/ from pete

14:07:26 <_joshua> verbosus: can you send me a picture?

14:07:48 <mortenf> and then there are the maker note, which is all distinct, but perhaps possible to merge as well

14:07:54 <verbosus> but if the EXIF people don't enforce their own standards there's no reason for us to work with EXIF at the moment.

14:08:05 <edd> danbri: not tried

14:08:14 <verbosus> verbosus: with RDF of just with plain EXIF?

14:08:23 <verbosus> sorry, I mean to say that one to _joshua :-)

14:08:44 <danbri> edd, my tools always try, as written with rotation-metadata in mind (for my recently-lost PowershotS45, sob...)

14:08:47 <_joshua> verbosus: indeed; but may I please try? :)

14:09:45 <libby> it could be pretty interesting for them to see compliance maybe?

14:10:19 <mortenf> i'd like a table of fields versus cameras/models support

14:10:37 <mortenf> perhaps i should just start one in a wiki somewhere...

14:10:40 * dino curses all the lazy camera manufacturers that just flip exif orientation bits rather than rotate the image.

14:11:04 <mortenf> hmm, i actually like that; let me handle it myself, if needed

14:11:24 <verbosus> mortenf, libby: there should be an EXIF validator :-)

14:11:29 <mortenf> heh

14:11:36 <libby> heh

14:11:46 <libby> same issue with icalendar stuff we've been looki g at

14:11:55 <dino> mortenf, my take is that 99% of people want the image the right way up. the other 1% can deal with it :)

14:12:18 <mortenf> i guess, yeah :)

14:12:35 <dino> i have no real problem rotating, but it annoys me that I have to.

14:12:57 <dino> my curse goes double for the cameras with inbuilt orientation sensors

14:13:10 <karlcow> I wonder if there's a list of all tools supporting the EXIF information. Most of them are able to read it, only a few can write it.

14:13:11 <mortenf> danbri, would it be ok if i started an "exif support matrix" on the esw wiki, near ImageDescription?

14:13:39 <dino> those guys don't even have the excuse of takes too much memory, they could just read data off the CCD the wrong way around ;)

14:13:48 <danbri> mortenf, fine by me.

14:13:51 <karlcow> Many softwares also mungle the EXIF data in the image when the image is rotated, cropped, resizd, etc.

14:14:17 <danbri> DanC sometimes complains when people make Wiki topics that aren't "patterns", but I've never fully understood what 'counts' as appropriate...

14:14:21 <pete> note that http://www.ba.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html is a good start on various manufacturer-specific stuff

14:14:22 <karlcow> mortenf, don't forget to add the supported OS

14:14:26 <danbri> so long as the doc has reasonable self-explanation is fine by me!

14:14:30 <maxf> the question of modifying the exif data along with the picture is quite trucky

14:14:33 <maxf> tricky

14:14:33 <mortenf> os?

14:14:41 * karlcow can't use BreezeBrowser

14:14:49 <karlcow> OS = Operating System.

14:15:03 <mortenf> hmm, but i'm refering to exif generated by camera?

14:15:17 <verbosus> maxf, indeed.

14:15:22 <karlcow> oh :) sorry thought you were talking about a matrix of products :p

14:15:34 <verbosus> That's why I reckon putting the metadata in an external RDF document makes it easier to deal with it.

14:16:19 <maxf> verbosus: because it would be easier to edit?

14:16:34 <karlcow> maxf: because you will not lost them

14:16:35 <maxf> or because it would prevent software to mess with it?

14:16:35 <verbosus> Yeah.

14:16:36 <mortenf> yeah, and also i wouldn't want to download a bunch of images to find the rdf - to find the images i'm interested in...

14:16:43 <verbosus> Both, actually.

14:16:53 <maxf> agreed

14:17:05 <karlcow> HTTP trafic is good point

14:17:41 <karlcow> I wish we could do an HEAD http://www.example.org/image.jpg, and have the metadata

14:18:06 <mortenf> that would be nice, yes, but then there's uriqa :)

14:18:11 <karlcow> without transfering the image

14:18:34 <dino> ok. here's a simple question for you metadata types: when you say "image" do you include the original, the thumbnail, the medium sized version that is good for web page, etc?

14:18:58 <mortenf> we use foaf:thumbnail :)

14:19:07 <verbosus> dino: my digicam embeds the thumbnail in the same file.

14:19:08 <karlcow> hmm you mean image as a set of different representation of the same image

14:19:10 <karlcow> :)

14:19:13 <danbri> The notion of image is pretty slippery

14:19:14 <mortenf> ... to point to smaller versions, recursively

14:19:32 <danbri>http://www.tasi.ac.uk/2000/09/rdfmeta/

14:19:32 <dc_rdfig> J: http://www.tasi.ac.uk/2000/09/rdfmeta/ from danbri

14:19:41 <danbri> J:|RDF for self-describing images

14:19:41 <dc_rdfig> Titled item J.

14:19:42 <dino> verbosus, yes, but that's only one thumbnail. I usually have 3 different sizes

14:19:55 <maxf> Shame Bert has left. His RDFPic has the metadata in the picture, but the http server can send just it on request.

14:19:56 <dino> this is one reason why I don't like RDFpic

14:20:02 <danbri> J:Pretty ancient doc I wrote on RDF and PNG when at ILRT (1999/2000)

14:20:02 <dc_rdfig> Added comment J1.

14:20:04 <karlcow> dino: I would say no from the exif point of view. You have the size of the image in exif data and so it's particular to a specific version.

14:20:29 <verbosus> dino: what I upload to the web is a scaled version of the original one. So yes, i do have three sizes as well, but one is not published.

14:20:34 <dino> aha! then why do you want to preserve the EXIF when you modify the file Karl? :)

14:20:35 <mortenf> an example: http://www.wasab.dk/morten/2003/07/photos/8/

14:21:15 <karlcow> dino the problem is not preserving them :) the problem is not having them anymore.

14:21:54 <karlcow> For example when you do a rotation with some software, everything has disappeared.

14:22:09 <danbri> J:Origins of FOAF 'depicts'/'depiction' and use of Wordnet. Scenario taken from Guha's example in our [http://www.w3.org/TandS/QL/QL98/pp/enabling.html|QL'98 position paper].

14:22:09 <dc_rdfig> Added comment J2.

14:22:10 <karlcow> It was the case in old version of ZoomBrowser of Canon.

14:22:20 <dino> yeah i know, but cropping for example is a new image.

14:22:22 <danbri> Dammit, why does Guha have to have thought of everything first? ;)

14:22:50 <JibberJim> Yes, but EXIF is still useful for the new image, if it's just a cropping.

14:22:55 <verbosus> karlcow: are you saying that the world needs an EXIF-friendly image editor/photo management software?

14:23:08 <mortenf> i publish descriptions of original image, then point to thumbnail(s)

14:23:12 <JibberJim> If you've atually edited the pixels though, I guess saying it was taken by Joes Camera is not so useful.

14:23:15 <karlcow> yes cropping is a new image and some part of the information should be modified and some other should be kept.

14:23:17 <dino> my (dumb) feeling is that one "image" includes all the different sizes and a single RDF file.

14:23:28 <mortenf> ... hoping that the tools finding the images will display thumbnails first

14:23:30 <dino> of course, JPEG2000 will solve all this :)

14:23:51 <maxf> ha! JPEG2000

14:23:56 <dino> and JPEG2000 has yet another metadata format iirc.

14:23:58 <danbri> ha?

14:24:06 <maxf> just the name sounds so pass?!

14:24:13 <danbri> it sounds so futuristic! when will it be ready? :)

14:24:18 <karlcow> Dino viewed from the description side, you can have a bag of images which have the same origin and are different versions.

14:24:29 <karlcow> and so as you said the file describe all of them

14:24:42 * dino apologises for being a metadata dummy

14:25:07 <dino> they intend to rename to JPEGXP

14:25:12 <mortenf> ;)

14:25:43 <karlcow> no dino.... :) it's cool. questions and ideas are always good. :p and you are not the dumbest.

14:25:50 <karlcow> Dumb contest now

14:25:50 <verbosus> mortenf: what EXIF extraction tool do you use in your gallery script?

14:26:20 <mortenf> the one linked earlier, http://www.wasab.dk/morten/2003/07/sempex/ - Perl with Image::Info

14:26:33 <karlcow> for my gallery, I'm using iviewmediapro. which extract metadata in my html templates

14:26:49 <verbosus> karlcow: is that a command line tool?

14:27:21 <karlcow> nope verbosus

14:27:35 <karlcow> And it's why I want to escape this product :p

14:27:42 <karlcow> even if it's a good one

14:27:55 <verbosus> Same here: I want to roll my own.

14:28:23 <verbosus> For those following, BTW: http://www.iview-multimedia.com/products/mediapro/index.html

14:29:20 <verbosus> $90, Mac OS X only (Window build in development)

14:29:29 <verbosus> s/Window/Windows

14:44:47 <danbri> btw re Exif chat, did anyone dial into the audio channel that was offered?

14:44:59 <mortenf> nope

14:45:07 <danbri> I'd be interested in trying gnomemeeting, ichat etc here sometime...

14:45:26 <edd> Difficult to use with firewalls.

14:45:27 <GregElin> I did. Chatted with Pete Kaminiski and Marc Canter.

14:45:31 <danbri> my voice over ip line is down for some reason, so can't call us cheap

14:45:55 <GregElin> Are you on a Mac, Dan? I recently bought an iSight.

14:46:11 <GregElin> I can plug it in.

14:46:29 <danbri> I have a powerbook laptop + the hack for using old usb cams... but am about to dissapear into telecons again!

14:46:37 <danbri> #rdfig in multimedia would be interesting

14:46:58 <verbosus> danbri: I switched to a powerbook as well :-)

14:47:01 <danbri> foafbot is a part of that puzzle... esp now edd using the Twister/twisty framework... we could have a page showing photos of everyone here

14:47:03 <danbri> :)

14:47:04 <GregElin> Well, if people are willing to leave IRC, I can put a webchat channel together with a little multimedia.

14:47:22 <edd> danbri: Twisted. And that's rather a nice idea :)

14:47:30 <GregElin> Want to try that?

14:47:51 <danbri> I think we're quite wedded to IRC for now, due to proximity of rest of freenode...

14:47:55 <edd> Highly unlikely that people would want to move from IRC. It's a good lowest common denominator.

14:48:02 <GregElin> Tell you what...why don't later this week or early next we have a small group test in a webchat with multimedia? Next Wed?

14:48:02 <mortenf> greg, as long as you keep the barrier of entry low, i.e. no requirements for IE or so...

14:48:04 <danbri> if it was gated to irc, mebbe

14:48:11 <danbri> same issue re Jabber migration

14:48:44 <JibberJim> Soon SVG will solve it by allowing us to write IRC clients in SVG, we can then do image stuff in SVG clients, which talk SVG commands on a 2nd channel, to do shared whiteboard etc.

14:48:56 <GregElin> We could try a gateway to IRC.

14:48:58 <mortenf> next week? ;)

14:49:02 <danbri> edd: yeah it'd be a good way to demo the multi-headed foafbot...

14:49:20 <danbri> +1 re irc in svg

14:49:34 <libby> dont worget nextwed is calendar chat at 1600UTC

14:49:38 <libby> no clashing!

14:49:42 <danbri> gateway would be good, so folks could live in multimedia land or stick to their trusty irc clients

14:49:47 <libby> s/worget/forget/

14:49:59 <GregElin> well we'll just try something casual sometime then.

14:50:10 <GregElin> Oh? Wordnet?

14:50:28 <deltab> JibberJim: Jabber might be good for that

14:50:43 * danbri bbiab

14:50:52 <libby> it's ok, just I dont want ckashes. could haveti earlier, say

14:51:20 <JibberJim> Integrating anything with SVG clients at the moment means tieing us to Win32 IE, however 1.2 should allow us to write an actual IRC client within SVG itself.

14:51:52 <GregElin> JibberJim: Yikes!

14:52:02 <danbri> or web browser...

14:52:06 <GregElin> talk about discussing photos

14:52:14 <GregElin> brb

14:52:26 <deltab> you wouldn't actually need irc implemented within svg, just a connection between them

15:03:57 * verbosus fell down

15:20:33 <GregElin> back

15:23:57 <ericP> libby, want to chat about what you need from a triple store?

15:24:22 <ericP> i've been meaning to bug you about this for a couple days

15:24:30 <libby> yeah?

15:24:34 <libby> why me!?

15:24:50 <libby> I want lots of stuff, but probbaly prety mcuh the same as anyone else :)

15:25:12 <ericP> i thought you wanted to store some picture markup stuff

15:25:19 <ericP> or something like that

15:25:28 <libby> yep I do....

15:25:33 <libby> do you mean upload type stuff

15:25:34 * ericP racks racked memory and sieves for bits

15:25:40 <ericP> yeah

15:25:43 <libby> sorry, didnt mean to sound ungrateful!

15:25:57 <ericP> friggin' ingrate

15:26:24 <ericP> do you have any requirements beyond POST some RDF and be able to query to get it back?

15:26:28 <libby> heheh

15:26:43 <mattb_> provenance!

15:26:56 <ericP> ie, do you want specific URLs to access parts of it (that is, URLs that are different from a query GET url)?

15:26:57 <libby> that's basically it, except some of the queries I could do with doing relate to where the file came from

15:27:04 * mattb_ likes sesame but it's (relatively) useless without being able to say "reload from http://foo.com/bar.rdf"

15:27:10 <ericP> ahh, provenance is my pet issue lately

15:27:34 <danbri> +1 re reload()

15:27:38 <libby> yep, provenance,, basically

15:27:39 <jeen> mattb, so why didn't you tell us? :)

15:27:43 <mattb_> jeen: i did!

15:27:45 <mattb_> at www2003

15:27:49 <mattb_> and a few times here

15:27:54 <ericP> mattb, what are your provenance requirements?

15:27:58 <mattb_> i love sesame, but i'm waiting for something a bit like redland's contexts

15:28:07 * mattb_ brb, got dayjob work to do :)

15:28:10 <jeen> heh

15:28:38 <ericP> ie, do you want to do a query that joins data from different sources (for instance, POSTS) and find out which triples came from which source?

15:28:42 <jeen> it's getting there, or at least something similar. you can now do in-memory inferencing.

15:28:43 <libby> so at the moment I can query the underalyign store directly and get provence; or query the rdf and not get provence.

15:29:09 <libby> I've alos liked the annotator to the fuile name in rdf I generate, so at a pinc=h i could get it using that: http://swordfish.rdfweb.org/photos/genfiles/ilrt/026406035665294925.rdf

15:29:22 <jeen> argh

15:29:24 <ericP> libby, yeah, but i'm working on packaging up the provenance data too

15:29:24 <libby> but that's a bit aslow with mine

15:29:57 <ericP> so you have API access to the provenance but no way to serialize it?

15:30:24 <libby> yep I think so, re triples from which sources. not as good but simpler is to find any sources files that say soemthign about this picyure

15:30:39 <libby> I've got no way to query it in squish

15:31:17 <ericP> so i'm really not sure how to handle this provenance query issue.

15:31:31 <libby> me neither...

15:32:07 <libby> jena does it be getting objects back (in 1.6 anytway), but that's not so practical in my ystem at least where I get a resultset back directly from the sql database

15:32:33 <libby> oh I dunno, maybe it is

15:34:21 * mattb_ returns

15:34:27 <mattb_> it's more than just provenance, of course...

15:34:36 <ericP> algae2 does it by giving accessors to special properties like the attribution (provenance)

15:34:36 <mattb_> it's wanting to annotate the model without adding to its serialisation

15:34:37 <mattb_> iyswim

15:34:57 <mattb_> might want to attach provenance, trust metric, timestamp, that sort of program-internal data

15:34:59 <ericP> "without adding to its serialisation", i don't understand

15:35:09 <libby> without reification?

15:35:13 <mattb_> i don't want to add reified statements to the model itself

15:35:18 <mattb_> just want to annotate its database form

15:35:26 <mattb_> if i request a serialisation, the additional info is invisible in the rdf

15:35:31 <mattb_> it's only available through an API

15:35:37 <mattb_> so it's not turning RDF into quads, or somesuch

15:35:39 <ericP>http://www.w3.org/2001/12/attributions/

15:35:40 <dc_rdfig> K: http://www.w3.org/2001/12/attributions/ from ericP

15:35:56 <ericP> K: shows how ugly re-reification can get

15:35:57 <dc_rdfig> Added comment K1.

15:36:02 * mattb_ going on experience with redland

15:36:44 <ericP> i view it thus:

15:36:50 <ericP> most implementations use quads

15:37:07 <ericP> RDF data model does not suppoert quads, but instead reification

15:37:42 <ericP> a particular form of reification may be chosen to convey what all the implementations do with quads.

15:38:26 <ericP> this "standard" form of reificiation may not be the current sanctioned form of RDF reficiation.

15:38:51 <ericP> this is because of the superman problem

15:39:06 <ericP> (aka referential opacity)

15:39:33 <shellac> when did the morning star problem become the superman problem, btw?

15:40:36 <ericP> oops, i don't know the "morning star" problem. is that the house style sanctioned way to discuss referential opacity?

15:41:14 <shellac> it's what you often find in the literature

15:41:27 <shellac> but it may be old skool :-)

15:41:54 <ericP> i'm down with the old skool, my man

15:42:02 <shellac> it's about the difference between the morning star & evening star

15:42:05 * ericP desparately acts hip

15:42:17 <shellac> both are venus, btw

15:43:02 <dngor> not for chumping... http://poe.dyndns.org/~troc/tmp/know-2.text

15:43:05 <ericP> fred: the morning star is the first thing i see

15:43:22 <ericP> joe: the evening star is the last thing i see

15:43:36 <dngor> know's that bot of mine that sucks up information from IRC. I should bring it back.

15:43:48 <ericP> sue: evening star owl:sameAs morning star

15:43:52 <jeen> mattb, you're right of course. I think I forgot to turn on my brain this morning.

15:44:12 <ericP> how do you make sure fred doesn't say "the evening start is the first thing i see" ?

15:44:28 <ericP> is that the morning/evening star problem?

15:44:37 <shellac> pretty much, yes

15:45:03 <ericP> so i was thinking i would do something like this:

15:45:51 <shellac> it's actually slightly different to the superman case, since it doesn't explicitly mention beliefs

15:45:58 <ericP> use convetional RDF reification with some extra standard-ish props to describe the relationship to the provenance.

15:46:03 <shellac> but it can be recast that way

15:46:32 <ericP> define a SOAP encoding that had the same semantics as that but allowed the statements to be expressed directly rather than reified.

15:46:52 <ericP> .

15:47:10 <libby> soap things sounds interesting

15:47:17 <shellac> there was one (hackish) idea you haven't mentioned AFAICT

15:47:20 <libby> I'd avoid reification like the plague though

15:47:32 <ericP> but tim and sandro threw some rocks, namely referential opacity and parseType="quote"

15:48:33 <shellac> ericP foo:believes <ref_to_rdf_doc>

15:48:41 <shellac> or even

15:48:55 <ericP> see http://www.w3.org/2001/12/attributions/#SOAP for a way-oversimplified example of the SOAP shortcut

15:49:03 <danbri> ericp, you had a test case re RDF and I18N a few weeks back, re lang tagging and RDFCore appearing to violate what one might call princple of least suprise...

15:49:06 <danbri> got a pointer handy?

15:49:13 <shellac> ericP foo:believes <hash_ref_to_another_rdf_chunk>

15:49:33 * ericP sorts through conversations...

15:51:35 <ericP> <r:Desc r:about="n1"><title xml:lang="en">Soul Train</title><title xml:lang="en" r:parseType="Literal">Soul Train</title></r:Desc>

15:51:55 <ericP> the 2nd title mysteriously has no lang

15:52:25 <ericP> <r:Desc r:about="n1"><title xml:lang="en" r:parseType="Literal"><span xml:lant="en">Soul Train</span></title></r:Desc>

15:52:51 <ericP> but someone else may use a different spelling of span (say div, or asdf:jkl)

15:54:15 <ericP> so there's no convergence of many literals that are meant to be the same (<span>Soul Train</span> and <div>Soul Train</div>)

15:54:44 <ericP> yet the core said that "blue" and "blue" are supposed to be the same.

15:54:45 <ericP> .

15:54:51 <ericP> that may be it. not sure.

15:56:09 <ericP> shellac, do you mention the referential approach to provenance just for completeness?

15:56:54 <ericP> ie, do you feel it is sufficient and a good way to manage assertions about sets of statements?

15:57:23 <shellac> hmm - well it's broken semantically

15:57:39 <shellac> but it makes a kind of sense (to me)

15:58:04 <ericP> how is it broken vs. potentially over-constraining?

15:58:09 <shellac> it's been raised before as a way to get round the serialisation horror

15:58:50 <shellac> it's broken simply because foo:believes isn't in model & syntax

15:59:07 <shellac> but reification is, iirc

15:59:35 <ericP> right. but the reification in M&S is potentially broken

16:00:00 <ericP> i'm a bit ambivilent about it.

16:00:01 <shellac> indeed - I used 'iirc' because I thought it may have been purged

16:00:52 <ericP> for my purposes, M&S reification works

16:00:58 <libby> the document way is crufty, but I think the best way to go...

16:01:39 <shellac> I like having two (or more) rdf subtrees in an xml doc - that's quite cute

16:02:56 <shellac> but this stuff doesn't provide an impermiable barrier between reified and stated content

16:03:05 <ericP> libby, how does one report query results, multiple documents?

16:03:27 <libby> what with provenance?

16:03:33 <libby> mumble

16:03:48 <ericP> i think query results force the issue

16:04:00 <libby> i.e. how to get that information bac out again?

16:04:17 <ericP> ie, it's practical to say "i beleive X" and write X in a sepparate document.

16:04:50 <libby> so, you're saying, that _is_ practical?

16:05:04 <ericP> bit it's impractical to give fourty eleven different document fragments that combined produce the query resutls

16:05:29 <ericP> libby, well, maybe not practical, but doable

16:05:38 <libby> righ

16:05:39 <libby> t

16:05:46 <ericP> more doable than when reporting inferential joins over many sources.

16:06:34 <libby> so could you not refetch the relevant document fragments if requested? most people wont want that

16:08:00 <ericP> my windows are dirty, who do i know that knows someone who can fly?

16:08:40 <libby> I guess depends on how important trust is.

16:08:52 <ericP> go get lois's document and lex's document and apply owl:sameAs to whatever you find there

16:09:27 <ericP> the prob is you can't even say "apply owl:sameAs to the following statements" as we still don't know how to state the statements.

16:09:56 <ericP> shellac, M&W reification works for me 'cause i always report proofs.

16:10:23 <ericP> s/i/algae/

16:11:45 <ericP> algae will say that lois says "Superman can fly" and Lex says "Superman is Clark Kent" and Modus Ponens+lois+lex says "Clark Kent can fly".

16:13:00 <ericP> but if i dump my database in a reificed form and someone applies owl:sameAs substitutions to it, and i get it back and de-refify it, i learn that lois says "Clark Kent can fly"

16:13:43 <ericP> oof. my world interacting with other peopls world breaks if they think they can substitute into my data.

16:14:17 <ericP> tim argued that i use parseType="quote" rather than some soap encoding.

16:14:22 <ericP> bit of an impasse there

16:14:56 <ericP> either <SOAP><myHairBrainedScheme><RDF></></></>

16:15:33 <ericP> or <RDF><tim'sHairBrainedScheme><RDF></></></>

16:15:47 <ericP> mine is more legal, his shows a clearer migration

16:16:08 <DanC-AIM_> Z:

16:16:09 <ericP> i have to run, y'all think about that and let me know if you have an opinion

16:16:12 <dc_rdfig> Label Z not found.

16:16:13 <ericP> cheers

16:16:30 <ericP> gotta run

16:16:40 <DanC-AIM_> byebye

16:17:04 * dajobe discovers a new java RDF system

16:17:31 <dajobe> ah, jena carefully hidden underneath. nevermind

16:18:00 <libby> cheers ericp

16:19:39 <dajobe>http://scam.sourceforge.net/

16:19:40 <dc_rdfig> L: http://scam.sourceforge.net/ from dajobe

16:19:49 <dajobe> L:|SCAM content archive management system

16:19:49 <dc_rdfig> Titled item L.

16:20:12 <dajobe> L:*an archive system for Learning Objects and Learning Components. It is built upon international standards for learning technology and metadata. Such as IMS, Dublin Core, IEEE/LOM and RDF*

16:20:14 <dc_rdfig> Added comment L1.

16:20:22 <dajobe> L:new snapshot out 2003-08-05

16:20:23 <dc_rdfig> Added comment L2.

16:21:04 <darobin> gah

16:21:18 * darobin got cut off from the internet two minutes into the meeting :(

18:46:07 <ericP> libby, what RDF parser do you use?

19:14:25 <libby> arp mostly

19:17:02 <nym_> nym_ is now known as nym

20:04:20 <bitsko_> dajobe, I'm running logger.pl on #echo. works great, thx! it appears to not reconnect to the channel after getting disconnected, how do you keep it running, just loop?

20:06:51 <sethl> howdy

20:06:57 <sethl> long time no chat

20:08:12 <sethl> is it just me, or is there a disconnect in RSS between an <item> and the URL it often is about? Often, an <item> is the URL to the blog entry, but the entry itself is about another URL. Through standard RSS usage, I can't seem to easily jump between the <item> and the URL it's talking about.

20:09:06 <sethl> I was thinking about how to discover what people are talking about, and I can't seem to do it via RSS, which seems odd. I'd think that's be a feature of RSS.

20:09:28 <sethl> I think blogdex accomplishes this via full text indexing on the blog entries

20:09:42 <bitsko_> sethl, that's a very accurate read on the vagueness of that particular element in RSS (both flavours)

20:10:21 <sethl> bitsko_: no doubt, but I can accept that, for now, <item> means "the entry in the blog that this RSS represents"

20:10:26 <bitsko_> Pie/Echo/Atom, by comparison, makes the purpose of <link> clear, and doesn't itself specify using, for example, dc:source

20:11:18 <sethl> I'd love an easy way to say, in RSS, "this <item> contains comments about <uri>, <uri>, and <uri>"

20:11:23 <bitsko_> yes, <item> itself refers to the blog entry

20:11:57 <sethl> right now, my RSS reader can't tell me, the user, "what things (uri's) people are blogging about"

20:12:10 <sethl> kinda misses the mark, IMHO

20:12:11 <bitsko_> note that <item><link>'s original definition was "this <item> contains a comment about <link>"

20:12:35 <sethl> that I can agree on, and I can see it's usefullness

20:12:36 <bitsko_> but that definition changed over time with vague usage.

20:12:46 <sethl> pooey on that

20:13:12 <sethl> is p/e/a's intent to replace RSS soup?

20:13:20 <bitsko_> there is no RSS specified way to get all the remaining referenced links, unless the publisher also includes the full body content, which you can then cull the URIs from

20:13:33 <dajobe> bitsko_: it reconnects for me. There is a loop if it actually dies/exits but that's rare

20:13:50 <sethl> yeah, and often times they don't. and it seems that moveable type strips the URIs right out of the <description>

20:14:17 <bitsko_> sethl, combining the features of RSS and the weblogging APIs is the main focus of Pea, yes

20:15:25 <bitsko_> dajobe, k. I think I must have hit one of the rarities ;) do I need to configure Apache (as in .htaccess) to allow content-negotiation for the bookmarks to go to XHTML or RDF?

20:15:36 <dajobe> that's what I do

20:16:59 <bitsko_> do you have a snippet that shows what I need to do?

20:17:54 <dajobe> <Directory wherever/>

20:18:03 <dajobe> Options Indexes FollowSymLinks MultiViews

20:18:09 <dajobe> </Directory>

20:19:29 <wkearney99> is there an rdf vocabularly that describes distance units of measure?

20:19:54 <sethl> wkearney: lots of discussion about that on the rdfig mailing list

20:20:29 <wkearney99> discussion I've seen, resolution... I seem to have missed it...

20:20:35 <sethl> roger costello has been writing a lot of emails about that, might give you a starting poitn

20:20:51 <sethl> nope, I don't think there's been a resolution

20:21:30 <wkearney99> basically, I'm cobbling up an excuse for why using separate rdf:descriptions has merit.

20:21:58 <sethl> bitsko: thanks for the chat

20:22:16 <wkearney99> as in <foaf:near rdf:id="abc"> and then using a separate <rdf:Description rdf:about="#abc"> to say /how/ near.

20:23:03 <wkearney99> or, for that matter, to say any number of other 'describing' thing about the location involved.

20:23:12 <dajobe> why not use datatypes, <foaf:near rdf:datatype="&units:km">10</foaf:near>

20:24:01 <wkearney99> well, I'm thinking along the lines of <foaf:near rdf:id="aa" rdf:resource="http://www.daml.org/2001/10/html/airport-ont/iata#DCA"/>

20:24:32 <wkearney99> and then using a separate rdf:Description wrapper elsewhere to say /how near/

20:25:00 <JibberJim> did you see the geoOnion vocab?

20:25:10 <dajobe> this is multi-value property stuff. The original RDF spec said use rdf value. <foaf:near rdf:value="10" geo:units="km"/>

20:25:50 <dajobe> you could add more there to say near to what other point, but /me not geo-person

20:26:38 <wkearney99> ah, so it'd be <rdf:Description rdf:about="#abc"><foaf:near rdf:value="10" geo:units="miles"/></rdf:Description>

20:27:22 <dajobe> still doesn't say near to *what*

20:27:27 <wkearney99> where #abc is <foaf:near rdf:id="abc" rdf:resource="http://www.daml.org/2001/10/html/airport-ont/iata#DCA"/>

20:27:46 <dajobe> ugh, that's reification

20:28:23 <wkearney99> so the path here is foaf:person has a foaf:near with an ID of 'abc' and then elsewhere I'm saying the 'abc' relationship is described as one being '10 miles'

20:29:10 * wkearney99 it may be 'ugh, reification' but it's a reality I have to deal with...

20:29:20 * wkearney99 pun intended...

20:31:03 <wkearney99> is this one of those "thud, the complex question lands and nobody wants to venture a guess" situations?

20:31:36 <Cardinal> <foaf:near><air:Airport><something:range rdf:datatype="&units:km">10</><air:iataCode>DCA</></></> ?

20:32:03 <dajobe> that might work, as I bend my head to try to see the triples

20:32:04 <Cardinal> Eh. Still doesn't state what the range is to.

20:36:07 <wkearney99> ok, the riddle me this then, if the way I stated it wrong? what sort of reification weirdness is invovled?

20:36:54 <wkearney99> I made a statement and then I went on to describe that statement. is this not a valid leap to make?

20:40:38 <dajobe> I guess

20:40:45 <dajobe> using reification just scares me

20:41:32 <wkearney99> oh, don't get me wrong, I'm not ignoring the reification issue. I'm approaching this from a document-centric position. The querying back against a mass of triples would indeed present interesting reification questions.

20:43:05 <dajobe> what you need is a property that is (10km from) - multi part that is including (10 integer, units km, from property). If RDF allowed bnodes as properties (it doesn't), you could declare one and then hang those properties off it. I think.

20:43:41 <JibberJim> Have you seen http://esw.w3.org/topic/GeoOnion wkearney99?

20:43:58 <dajobe> i.e. in n3 <sourcePlace> [ rdf:value "10"; foo:units "km"; rdf:subPropertyOf foo:from ] <destPlace>

20:45:26 <wkearney99> I'm not so much worried about the measurement markup at /this/ point, as there's also the need to use MILES not kilometers.

20:46:06 * wkearney99 jibberjim: yes I've seen geoOnion.

20:46:51 <wkearney99> now, technically, I suppose saying my own foaf:Person is 'near' something is probably sort of ridiculous.

20:50:54 * chrisc rather likes the metric system...

20:51:37 <wkearney99> but within the confines of a person's own statements about themselves, saying "they're near" something is possibly usefully abstract.

20:52:00 <mortenf> foaf has based_near, for that reason

20:52:17 <chrisc> yeah, true :-)

20:52:36 * wkearney99 right, based_near, tnx.

20:53:30 <dajobe> could you paste an example or write something up about this when you're done?

20:55:51 <wkearney99> yep, it's in progress.

20:57:46 <wkearney99> just wanted to preflight the question of how to 'properly' state a distance description.

20:58:47 <mortenf> have you seen the InterpretationProperties wiki page?

20:59:40 * wkearney99 looking.... (sp) magnitude....

21:16:15 * wkearney99 notes RDF and distance has other meanings http://www.geo.unizh.ch/~imfeld/diss/node58.htm

21:50:11 <wkearney99> ok, pick this apart for me and offer your comments: http://www.ideaspace.net/users/wkearney/archives/entries/000463.html

21:50:26 <wkearney99> mail them or leave them there as I have to run out for a meeting now...

21:50:45 <wkearney99> wkearney99 is now known as wkearney|away


The IRC chat here was automatically logged without editing and contains content written by the chat participants identified by their IRC nick. No other identity is recorded.

Alternate versions: RDF Resource Description Framework Metadata and Text

Provided by Dave Beckett. Hosted by Useful Information Company.