Semantic Web Interest Group IRC Chat Logs for 2004-01-20

00:05:58 <kasei_> kasei_ is now known as kasei

00:14:18 <tav|offline> tav|offline is now known as tav

00:41:57 <Davey> Davey is now known as D[a]vey

03:59:22 * mmealling works on the business plan

05:04:49 <monkeyqi> monkeyqi is now known as monkeyiq

05:13:01 <DanC> DanC is now known as DanC_BOS

05:13:06 * DanC_BOS waves

05:14:17 <dkk> hello Dan in boston

05:14:25 <dkk> oh, that's too bad. now you're in conneticut :(

05:15:08 <DanC_BOS> CT?

05:15:53 <dkk> oh, nm. i confused you and DanCon

05:16:09 <dkk> i guess one of you is in conneticut and the other in boston or something

05:18:13 <DanC_BOS> what suggests... oh... no, Con is the first syllable of my surname, not a geographical reference.

05:18:26 <dkk> ahh, that explains a lot

05:24:55 <tav> tav is now known as tav|offline

07:05:25 <monkeyqi> monkeyqi is now known as monkeyiq

07:40:02 <dmiles_clone> dmiles_clone is now known as dmiles

09:11:18 <dmiles>http://lotus.daml.us:88/msvw/Docs/API%20Reference/API%20Overview.htm

09:11:19 <dc_rdfig> A: http://lotus.daml.us:88/msvw/Docs/API%20Reference/API%20Overview.htm from dmiles

09:11:51 <dmiles> A# The re-beginning of Microsoft Virtual Worlds

09:12:02 <dmiles> A! The re-beginning of Microsoft Virtual Worlds

09:12:11 <dmiles> wow i have a bad memeory sometimes

09:12:23 <Wack> use 'A:' ;)

09:12:27 <dmiles> A: Microsoft Virtual Worlds

09:12:27 <dc_rdfig> Added comment A1.

09:12:36 <dmiles> there is a title one as well

09:12:50 <Wack> or, to title it; A:| or something with | at least

09:13:01 <dmiles> ajh thankyouyou

09:13:10 <dmiles> A:| Microsoft Virtual Worlds

09:13:10 <dc_rdfig> Titled item A.

09:13:36 <dmiles> A1 The re-beginning of Prolog Virtual Worlds MOO (was last active in 1999)

09:13:42 <dmiles> A1: The re-beginning of Prolog Virtual Worlds MOO (was last active in 1999)

09:13:42 <dc_rdfig> Replaced comment A1.

09:14:51 <dmiles> A: The 2nd most amazing project microsoft started.. but somehow forgot about

09:14:51 <dc_rdfig> Added comment A2.

09:16:08 <dmiles> A: Complete ORBS MOO System that can allow users to share office application data real time while the Mud

09:16:08 <dc_rdfig> Added comment A3.

09:16:24 <dmiles> A3: Complete ORBS MOO System that can allow users to share office application data real time while they Mud

09:16:24 <dc_rdfig> Replaced comment A3.

09:20:00 <dmiles> A: Installer System for access will be available sometime next week

09:20:00 <dc_rdfig> Added comment A4.

09:22:08 <deelan> "Microsoft Virtual Worlds", is it an active project?

09:22:27 <dmiles> i am reviving it from dead

09:22:49 <dmiles> it was scrapped in 2000

09:23:08 <dmiles> and most people that worked on it have left

09:23:14 <deelan> ah. k

09:23:50 <dmiles> but it remains the most mature and programmable VRML/MOO/ORBS in existance

09:24:49 <dmiles> You can use any ActiveX enabled langange and add objects runtime.. java,c++,C#,vb,vbs,js,prolog,lisp,python.. etc

09:25:21 <dmiles> your robot code is instantly able to be remote controled

09:26:11 <dmiles> it was once goinh to be an NT Service.. that pugged onto IIS5.1

09:28:16 <dmiles> just got to make a lightwight IE plugin next

09:31:52 <deelan> sounds nice

09:36:58 <dmiles> regedit /i /s is install silent.. ?

12:20:34 * Arnia is away: Refectory food at Cuths... yay

12:35:01 <dmiles> any guinea pigs: http://lotus.daml.us:88/msvw/MSVWorlds.exe

12:35:35 <dmiles> i'll make a real installer later

12:35:54 <dmiles> A: any guinea pigs: http://lotus.daml.us:88/msvw/MSVWorlds.exe

12:35:54 <dc_rdfig> Added comment A5.

12:36:13 <dmiles> A5: A sorta installer at http://lotus.daml.us:88/msvw/MSVWorlds.exe

12:36:13 <dc_rdfig> Replaced comment A5.

12:39:38 <dmiles> mdupont: starting to work on PrologVirtualWorlds now.. this means i am goiong to be poucking up on our c#/j# prolog interptor

12:40:23 <dmiles> (becasue now have 3 people motivating me)

12:48:30 <dmiles> mdpont a screenshot at http://lotus.daml.us:88/msvw/Local%20Content/Worlds/Hutch/Client/HTML/HutchHelp/HelpImages/viewStandardLG.jpg

12:49:59 <dmiles> and http://lotus.daml.us:88/msvw/Local%20Content/Worlds/Hutch/Client/HTML/HutchHelp/HelpImages/view3DMaxLG.jpg is good

13:16:04 <libby> BLURB:discussion about parts of image annotation, 20th January (today) at 16 UTC, here (#rdfig)

13:16:04 <dc_rdfig> B: discussion about parts of image annotation, 20th January (today) at 16 UTC, here (#rdfig) from libby

13:18:26 <libby> B:see [http://lists.w3.org/Archives/Public/www-archive/2004Jan/0088.html annoucement], [http://lists.w3.org/Archives/Public/www-archive/2004Jan/0092.html Masahide's message]

13:18:26 <dc_rdfig> Added comment B1.

13:20:15 <libby> B:I said: *I think there will be much more discussion in the future about how best to describe parts of images in the RDF community, so tomorrow's meeting would only be a discussion with a view to setting out a proposal for this project to use.*

13:20:15 <dc_rdfig> Added comment B2.

13:23:14 <libby> B:there's a few examples of different appraoches on [http://esw.w3.org/topic/ImageDescriptionRdfExamples ImageDescriptionRdfExamples]

13:23:14 <dc_rdfig> Added comment B3.

13:33:30 <deelan_> beatiful wiki page

13:33:50 * deelan_ printing

13:34:14 <deelan_> deelan_ is now known as deelan

13:51:25 <kota> .time UTC

13:51:44 <kota> hmm...

13:53:12 <dajobe> logger can tell you, sort of

13:53:15 <dajobe> logger, ptr?

13:53:15 <dajobe> I'm logging. Sorry, searching removed.

13:53:20 <dajobe> logger, pointer?

13:53:20 <dajobe> See http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-01-20#T13-53-20

13:53:24 <dajobe> that's UTC

13:53:52 <kota> thanks :)

13:54:14 <kota> so in 2 hrs, good.

14:11:32 <D[a]vey> D[a]vey is now known as Davey

14:29:27 <libby> B:everyone welcome

14:29:28 <dc_rdfig> Added comment B4.

14:29:56 <GregElin> Greetings.

14:32:22 <verbosus> Ciao Greg.

14:40:19 <GregElin> test

14:41:18 <GregElin> .time

14:47:54 <kota> it's around 14:45 UTC

14:58:17 <teefal> you know http://bigfractaltangle.com?

15:44:19 <mortenf> hey libby, do you still have your scrollback - the links on B: are using wiki-syntax, not chump syntax...

15:44:27 <libby> oopsy

15:44:40 <mortenf> and hi :)

15:45:04 <libby> :) I've been fixing links in the foaf wiki

15:45:24 <mortenf> ah, nice

15:45:25 <libby> B1:see [http://lists.w3.org/Archives/Public/www-archive/2004Jan/0088.html|annoucement], [http://lists.w3.org/Archives/Public/www-archive/2004Jan/0092.html|Masahide's message]

15:45:25 <dc_rdfig> Replaced comment B1.

15:46:01 <libby> B3:there's a few examples of different approches on [http://esw.w3.org/topic/ImageDescriptionRdfExamples|ImageDescriptionRdfExamples]

15:46:02 <dc_rdfig> Replaced comment B3.

15:47:33 <kota> so we'll start in 15 min?

15:47:41 <libby> yep

15:47:59 <libby> if you want to put attendees on the chump it might save time

15:48:12 <libby> B:attending - Libby Miller

15:48:12 <dc_rdfig> Added comment B5.

15:48:58 <kota> ok, but maybe i should wash dishes (i've just done eating breakfast :p)

15:50:21 <mortenf> B:[http://purl.org/net/morten/|Morten Frederiksen] attending

15:50:21 <dc_rdfig> Added comment B6.

15:53:08 <dajobe> dajobe has changed the topic to: -n

15:53:12 <dajobe> bah!

15:53:39 <dajobe> dajobe has changed the topic to: RDF, Semantic Web and Web chat. Scratchpad http://rdfig.xmlhack.com/ logs http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/

15:54:05 <JibberJim> Hi there

15:54:16 <mortenf> hey jim

15:54:41 <JibberJim> B:[http://jibbering.com/|Jim Ley] attending

15:54:41 <dc_rdfig> Added comment B7.

15:55:41 <libby> heya jibs

15:59:34 <verbosus> .time

15:59:53 <kota> 15:59 :)

16:00:02 <dajobe> bong

16:00:13 <verbosus> kota: are you the new bot? ;-)

16:00:14 <bengee> B:Benjamin Nowack attending

16:00:14 <dc_rdfig> Added comment B8.

16:00:35 <GregElin> B: GregElin attending

16:00:35 <dc_rdfig> Added comment B9.

16:00:40 <kota> heh :P

16:00:53 <verbosus> B:Antonio Cavedoni attending

16:00:53 <dc_rdfig> Added comment B10.

16:01:03 * libby waves

16:01:15 <kota> B:kota attending

16:01:15 <dc_rdfig> Added comment B11.

16:01:19 * deelan waves too

16:02:01 <libby> so, the aim of this meeting is to have a look at the different options available for describing parts of an image, and try to pick one to use for the www photoas annotation project

16:02:23 <libby> or we could merge two together or whateer

16:02:58 <libby> anyway, there will probbaly be several more meetings like this - we'rte not looking for the definitive answer but something we can use nowish

16:03:28 <libby> there seem to me to be several issues

16:03:49 <libby> BLURB: some issues to be resolved for p[arts of image annotation for w3 photo project

16:03:50 <dc_rdfig> C: some issues to be resolved for p[arts of image annotation for w3 photo project from libby

16:04:06 <libby> C:polygons or just rectangles

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

16:04:14 <libby> C:identifying parts of images

16:04:14 <dc_rdfig> Added comment C2.

16:04:38 <libby> C:'depicts' for parts of an image - or some other property

16:04:38 <dc_rdfig> Added comment C3.

16:04:54 <libby> C:images or multimedia

16:04:54 <dc_rdfig> Added comment C4.

16:05:10 <libby> any comments about that?

16:05:44 <mortenf> i can see a practical point in restricting to polygons, but it is necessary?

16:05:52 <danbri_dna> C:Note: this intersects re privacy issues. Some of might not want our annually expanding waistlines documented in tight-fitting bezier curves

16:05:52 <dc_rdfig> Added comment C5.

16:06:04 <mortenf> ah, ok :)

16:06:07 <libby> heheh +1 danbri_dna

16:06:12 <verbosus> danbri: heh.

16:07:08 <libby> so many people are using rectangles, but it seems a shame ot restrict it since some tools can do better

16:07:22 <mortenf> anyway, i don't see more problems with this type of annotation than with the general case, and suggest we leave that discussion to another meeting

16:07:26 <verbosus> libby: do we actually need to make a distinction at all?

16:07:29 <libby> restangles are polygons right?

16:07:32 <libby> perhaps not

16:07:32 <mortenf> yep

16:07:34 <verbosus> Indeed.

16:07:47 <mortenf> i was thinking circles etc.

16:07:51 <libby> but maybe a hint to the displayer? perhaps unneceesary

16:08:05 <danbri_dna> the possibilities w/ outlines are much more fun. you can make animated sprites... But not always worth the extra hassle.

16:08:10 <libby> oh good point. a circle isn;t a polygon right?

16:08:16 <mortenf> true

16:08:31 <danbri_dna> to have worse expressiveness than html imagemaps seems a step backwards

16:08:41 <verbosus> IIRC, Jim Ley was using an SVG vocab for that.

16:08:42 <libby> well because there will e many toools using this stuff, I don;t think we shoudl restrict it unnecssarily

16:08:53 <mortenf> yeah, i'm not saying that the first ui versions should support this, but let's not rule it out

16:09:00 <verbosus> So circles, polygons or rectangles shouldn’t matter: it’s up to the implementor.

16:09:59 <JibberJim> I don't see a problem supporting more than just rectangles, simple polygons and svg path elements/polylines can be used, the tools that consume won't need to be much more intelligent.

16:10:36 <libby> what about cicles jibberjim?

16:10:51 <libby> what I like about your vocab is the mapping to svg

16:10:52 <JibberJim> We just need to agree on a name PolyLine / Polygon with list of points / SVG path element / rectangle /circle etc.

16:11:25 <mortenf> could we have pointers to existing vocabs?

16:11:28 <JibberJim> What about Masaka at the moment, he's using rectangle IIRC?

16:11:34 <libby> yeah

16:11:36 * verbosus reboots, I'll be back in a minute, sorry.

16:11:56 <libby> BLURB:existing vocabs for describing parts of images

16:11:56 <dc_rdfig> D: existing vocabs for describing parts of images from libby

16:12:46 <libby> I'm trying to get to http://esw.w3.org/topic/ImageDescriptionRdfExamples - there are two examples there, one from Jim and one from Golbeck

16:12:56 <libby> it seems to be slow though

16:12:58 <mortenf> yeah, but no ns declarations...

16:13:05 <libby> ah :)

16:13:13 <JibberJim> D: [http://jibbering.com/2002/3/svg/|Old vocab], [http://jibbering.com/discussion/image.1|newer thoughts]

16:13:13 <dc_rdfig> Added comment D1.

16:13:26 <libby> well golbeck's schema is linked from that page too

16:14:22 <libby> D:[http://www.mindswap.org/~glapizco/technical.owl|mindswap ontology]

16:14:22 <dc_rdfig> Added comment D2.

16:14:47 <libby> any thoughts?

16:14:53 <bengee> mindswap has no domain for "depicts"

16:15:10 <mortenf> jim, rectangle is not subproperty of area?

16:15:18 <mortenf> eh, subclass

16:15:27 <mortenf> eh, polygon

16:15:29 <mortenf> :)

16:15:45 <libby> depicts is in http://www.mindswap.org/~glapizco/technical.owl bengee

16:15:57 <JibberJim> imagepart is just defined as an svgOutline there?

16:16:08 <JibberJim> in golbeck's schema?

16:16:22 <JibberJim> I think we'd need to be more general on what an imagepart could be.

16:17:04 <bengee> libby: yep. but they don't mention a domain. so depicts can be used both for Image and for Region, I think..

16:17:09 <JibberJim> Rectangle is a class morten, it's a subClass

16:17:14 <libby> oh sorry, I get you

16:17:21 <libby> yes I think that's the idea

16:17:32 <libby> I'm nt positive it's the best way though

16:17:51 <mortenf> yeah, but it's not a subclass of polygon, i'd expected that?

16:18:49 <JibberJim> oh it is mortenf, it's a subclass of that too :-)

16:19:15 <JibberJim> I like depicts having a range of Area with area's having subclasses.

16:19:33 <mortenf> hmm, where does it say that?

16:19:47 <bengee> yes. that's nice. those could be rectangles for now, circles and polygons later..

16:19:52 <mortenf> and yep, agreed on area/shape/part with subclasses indicating shape

16:19:53 <JibberJim> in my mind.

16:19:58 <mortenf> ah ;)

16:20:40 <JibberJim> bengee, I definately want to support polygons right now, my tool does this, Golbeck's tool does this, if we can find Nadia and get her backing working her tool will do it too!

16:21:44 <bengee> yes. sorry. I just meant, that we don't need an xor re rectangles or polygons.

16:21:44 <libby> so the proposal for depicts is that it has range: Area, domain: Resource

16:22:04 <libby> Area can have subclases Res=ctangle, Polygon, Circle

16:22:08 <libby> Rctangle

16:22:15 <libby> Rectangle!

16:22:32 <libby> so would that entail much change to your schema Jim?

16:23:32 <libby> http://jibbering.com/discussion/image.1 looks great :)

16:23:44 <JibberJim> Nope, very little, and little from golbecks too, other than widening what can be an imagePart

16:23:58 <JibberJim> that'll be the elephants libby.

16:24:07 <GregElin> Ack...just got back. Got booted. Apologies!!

16:24:08 * libby likes elephants

16:24:11 <mortenf> so an Area would be a subclass of Image?

16:24:58 <mortenf> ... since depicts should have a domain of Image, right?

16:25:00 <JibberJim> that's a bigger question mortenf!

16:25:16 <mortenf> well, we don't want two depicts properties?

16:25:21 <libby> I'd suggest distinguishing foaf:depicts from this form of depicts here

16:25:23 <JibberJim> depicts/regionDepicts distinction is something I'm keen on.

16:25:34 <mortenf> hmm

16:25:37 * libby too - for display purposes

16:25:38 <mortenf> why?

16:26:32 <JibberJim> we don't want it, but if you have _:partBnode foaf:depicts wn:Chicken, then it's very different compared to http://a.jpeg foaf:depicts wn:Chicken

16:26:34 <mortenf> can't you tell from the type of the depiction class?

16:26:38 <libby> I'm not sure this is a good enough reason, but it's one way of distinguishing a displayable image from a non-displayable fragment

16:26:51 <bengee> what about some sort of MainArea (full img) and SubArea both of type Area, and depicts gets a domain of area?

16:27:11 <JibberJim> I think we want to be compatible with the tools who assume A depicts B - relates an IMAGE to a B so they can display the image directly.

16:27:14 <bengee> unfortunately different from foaf:depicts..

16:27:53 <libby> danbri_dna: gt any opinions on this aspect of the problem?

16:28:08 <JibberJim> we can MortenF, I guess it depends if we're gonna re-use a depicts or not, with a new depicts we can!

16:28:50 <JibberJim> I'd like to re-use depicts so Libby's tool foafnaut etc. keep working on the new data.

16:28:50 <mortenf> yeah, i can live with regionDepicts being subpropertied of some:depicts some day...

16:29:48 <GregElin> JibberJim, sorry...can you elab on "tools who assume A depicts B - relates an IMAGE to a B so they can display the image directly."?

16:29:51 <danbri_dna> I think two separate properties is much cleaner

16:29:54 <mortenf> ok, you've convinced me for now

16:30:02 <danbri_dna> an image and a description of part of an image... they're different beasts

16:30:14 <danbri_dna> putting them in same property will mean a lot of conditional code has to be written.

16:30:24 <mortenf> but a part of an image is still an image? :)

16:30:48 <danbri_dna> it can be used to create an image, but often the one is a (uri-identified) bitmap, the other is a path-described overlay

16:30:50 <GregElin> I just read through the transcript...but I'd like to make sure I'm clear on the discussion so far. Can we recap in a sec?

16:31:03 <bengee> if we had some regionOf, we could find the Image from the Region..

16:31:24 <mortenf> ok, let's go with two and move on

16:31:45 <libby> yes I think that's important bengee - but I'm pretty sure there's a property like that alreaday

16:31:59 <GregElin> Two "what" and move on?

16:32:03 <libby> it's a shame golbeck isn;t here

16:32:15 <libby> two prpertyies greg, depicts, and regiondepicts

16:32:20 <mortenf> greg, we were discussing whether to have a single "depicts" property, relating (part of) an image to a person etc.

16:32:23 <bengee> yes, the mindswap vocab has it

16:32:45 <libby> jim's uses 'hasPart'

16:32:49 <GregElin> at the level of Image?

16:32:53 <danbri_dna> jim's vocab has something like regionDepicts, i thought?

16:32:59 <mortenf> either at Image of Area

16:33:01 <JibberJim> Greg, currently we have tools which look for <http://jibbering.com/imgs/new.jpg> <foaf:depicts> <wn:Zebra> and assume that they can render the URI there as <img src="..."> if we overload depicts to talk about regions too we can't do that.

16:33:04 <mortenf> s/of/or/

16:33:27 <libby> it'd be nice to interoperate with existing stuff if possible

16:33:45 <bengee> adding a partOf to jim's vocab could solve that?

16:34:03 <GregElin> Okay. I'm not sure about that assertion, Jim. I think we might. But I don't want to backtrack conversation yet.

16:34:19 <libby> ah ok, you mean an inverse property bengee

16:34:24 <bengee> yes

16:34:27 <mortenf> looking at the two examples in http://esw.w3.org/topic/ImageDescriptionRdfExamples i think they look much the same, only different names for properties

16:34:27 <libby> I don;t think it reallyneeds one, but might be useful

16:34:56 <GregElin> Anyone here familiar with Blosxum, the blog tool?

16:35:28 <libby> I know of it Greg

16:36:18 <GregElin> I just asked Jim: is the assumption <img src=" made on the fact of the foaf:depicts or on the .jpg?

16:36:25 <libby> so what golbeck's ontology gave us is some extra stuff about videa and so on, which might come in handy later

16:36:58 <GregElin> Blosxum looks at different extensions of URL and uses that to determine what "filter" (renderer) to apply to the URL.

16:37:03 <libby> you could ask a query either way greg

16:37:12 <mortenf> i think a "hasPart" property would be nice, could be subpropertied for various media types as in the mindswap schema

16:37:19 <libby> but when modellig rdf, we would tend not to do that

16:38:01 <libby> i.e. the urls are not inspected - you could find out if it was a displayable image by finding out its type via it's rdf description

16:38:02 <mortenf> yeah, i think the queries should be by properties/classes, not extensions

16:38:27 <libby> it's sort of part of what the RDf description is for

16:38:39 <libby> of course you could do that..... :)

16:38:57 <GregElin> So map the tool based on the property (foaf:depicts)?

16:39:07 <libby> but I think we need to distinguish them either by the property or by the type of the object

16:39:21 <libby> that seems to be a nice easy way of doing it gregelin

16:39:45 <libby> in terms of querying RDF it's often quicker to use a property

16:40:19 <mortenf> so we have property "hasPart" [domain: Image, range: Area], class "Area" (subclassed into Polygon etc.) and property "partDepicts"(?) [domain Area, range: Resource]?

16:41:00 <mortenf> any preferences on property names?

16:41:04 <libby> "partdepicts" sounds a bit funny :)

16:41:35 <mortenf> indeed :)

16:41:46 <mortenf> but at least it matches "hasPart"...

16:41:51 <libby> it sounds a bit like 'partlyDepicts'

16:41:54 <libby> yep true

16:42:01 <mortenf> (btw, "Area" could be "Shape" instead)

16:42:01 <bengee> or party-pics..

16:42:06 <mortenf> heh

16:42:07 <libby> heh

16:42:32 <mortenf> but region/area sounds too 2D, if later we want to expand to other media types...

16:42:45 <libby> yeah I agree

16:42:55 <JibberJim> regionDepicts hasRegion and class Region

16:43:04 <mortenf> also, dublin core uses "part"

16:43:36 <JibberJim> regionThiny hasThingy and a class Thingy - that's a bit less 2d ?

16:43:39 <mortenf> yeah, region works for still photos

16:43:43 <mortenf> ;)

16:44:11 <GregElin> segmentDepicts?

16:44:22 <bengee> what about subproperties of hasPart? one for 2D, one for timelines, ...

16:44:22 <JibberJim> although with danbri's prediliction for marking up foaf:rudeThing's hasThingy is probably not a good choice!

16:44:36 <mortenf> :)

16:44:45 <mortenf> segment could work

16:44:53 <libby> yep the subprops could mean we go with regions for now

16:44:57 <mortenf> section?

16:45:05 <JibberJim> I don't like segment - subpart or subelement or something.

16:45:21 <GregElin> or segmentationDepicts (which suggests an act of segmenting by someone/something)

16:46:21 * libby wonders if there's ana action that can see us through this impasse

16:46:44 * libby was going to suggest mortenf and jibberjim fight it out and send a message to the list with a suggestion

16:46:57 <mortenf> fine with me :)

16:47:00 <GregElin> Can the impass be summarized, please?

16:47:29 * GregElin wonders about "hasPartDepicts"

16:47:35 <mortenf> choice of property and class names for "parts" of photos

16:47:55 <libby> - how generic to make them

16:48:17 <mortenf> best suggestions so far: region, segment, section?

16:48:34 <libby> My preference would be for something quite straightforward for photos, but extensible to other media later

16:48:36 <GregElin> Um...can we get that in a form of a question?

16:48:42 <mortenf> with the first one being preferred for photos, but may not be good for other media types

16:48:55 <libby> also 'part'

16:48:58 <libby> yep

16:49:04 <GregElin> +1 on simple for photos, extend later.

16:49:36 <deltab> extent?

16:49:37 <mortenf> ok, so the schema just handles photos for now, can be extended later: then it should be region

16:50:00 <libby> yes as long as it's not restricted in the future

16:50:03 <bengee> hasPart [domain: Document, range: Part], Rectangle [subclassOf: Part], Polygon [subclassOf: Part], Sequence[...]?

16:50:05 <mortenf> hmm, extent sounds like a property?

16:50:08 <libby> but that might meannames are less crucial

16:50:34 <bengee> just thoughts.

16:50:36 <mortenf> part is not good for partDepicts...

16:50:46 <JibberJim> I like Region, we can superProperty a more generalised media one later.

16:50:54 <mortenf> yep, agreed

16:51:01 <libby> makes sense to me

16:51:06 <libby> likely to be lots more issues

16:51:07 <bengee> ok

16:51:08 <GregElin> I like that thought, Jim.

16:51:12 <libby> with multimedia

16:52:46 <libby> so, mortenf, jibberjim, can I action you to write an email about this?

16:53:17 <libby> it would be nice to have a schema and a sample document reflecting these discussions is possible

16:53:57 <mortenf> C:current consensus regarding photos indicates: class "Image", property "hasRegion" [domain: Image, range: Region], class "Region" (subclassed into Polygon, Circle etc.), property "regionDepicts" [domain: Region, range: Resource].

16:53:57 <dc_rdfig> Added comment C6.

16:54:10 <mortenf> correct me if i'm wrong...

16:54:32 <libby> I'm happy with that

16:54:43 <mortenf> yep, jim and i'll write...

16:54:44 <JibberJim> I agree

16:55:16 <mortenf> hmm, ok, jim and i will chat, i'll write... :)

16:55:23 <libby> thanks guys :))

16:55:28 <GregElin> I like that too (says the semweb newbie...)

16:56:03 <mortenf> so, how to describe a "Region"?

16:56:21 <libby> C:action jibberjim and mortenf - send a message to the w3photo mailing list - a schema and a sample document if possible

16:56:21 <dc_rdfig> Added comment C7.

16:56:37 * bengee still thinking about parts...: "component" ?

16:56:50 <Davey> Davey is now known as D[a]vey

16:56:55 <GregElin> May I suggest working with a photo from a conference?

16:57:10 <libby> good plan

16:57:12 <mortenf> bengee, i'll put down all the suggestions for region synonyms...

16:57:28 <mortenf> sure greg, will do - any suggestions?

16:57:34 <libby> C:[WWW2004 coference photos|http://rdfig.xmlhack.com/2004/01/19/2004-01-19.html#1074522663.890375]

16:57:34 <dc_rdfig> Added comment C8.

16:57:38 <bengee> ;-) ok.

16:57:43 <JibberJim> I like rectangles ( defined as 1 point and a height/width), a polyline - a list of points defining a polygon, a circle - cx,cy r at the very least.

16:58:33 <GregElin> I can get you one, mortenf.

16:58:35 <libby> you might be able to reuse some of this info: http://swordfish.rdfweb.org/discovery/2001/08/codepict/aboutevent.jsp?uri=http%3A%2F%2Fwww94.web.cern.ch%2FWWW94%2F

16:58:42 <mortenf> that'd be great

16:59:32 <GregElin> c:action GregElin and libby pick out 3-5 images to use for ontology examples.

16:59:43 <libby> need a capital C

16:59:44 <mortenf> we'll find one, and assume no problems with copyright etc.

16:59:54 <GregElin> C:action GregElin and libby pick out 3-5 images to use for ontology examples.

16:59:54 <dc_rdfig> Added comment C9.

17:00:09 <libby> there's loads about

17:00:25 <libby> most of the conference websites have links to photo archives

17:00:48 <libby> I like this one: http://swordfish.rdfweb.org/discovery/2001/08/codepict/aboutimage.jsp?uri=http://www94.web.cern.ch/WWW94/Images/ClosingPanel/Closingpanel5.gif

17:01:14 <GregElin> Yep. But I think we should just pick a specific image or two to use, kind of a 'gold' example. I like these from 1994!

17:01:23 <GregElin> but that's a gif!

17:01:39 <mortenf> i'd like one with more "stuff", not just people...

17:01:48 <GregElin> I like that image, though, libby. I think that's the one.

17:01:57 <mortenf> but for this purpose, i can see the merit

17:02:02 <libby> what sort of stuff greg?

17:02:08 <libby> sory, mortenf

17:02:28 <GregElin> mortenf, good point. We should have one image that is not all people.

17:02:40 <mortenf> image5 has a microphone, a table(?), a blackboard

17:02:42 <GregElin> A poster, a place.

17:02:44 <JibberJim> I have samples of www2002 already marked up, full of people, I'll just modify those if it's me doing it!

17:02:56 <mortenf> done!

17:02:56 <mortenf> :)

17:03:04 <libby> if you do an event search on http://swordfish.rdfweb.org/discovery/2001/08/codepict/ for http://www2003.org/ and http://www2002.org/ there are somethere (though it's more fun finding them yourself I think

17:03:10 <libby> hurrah jim!

17:03:44 <libby> that one of the panel is a panel - 2 sorts of events - the conference and the closing panel session

17:03:48 <GregElin> I guess I'd just like to add to the wiki and what not one or two great example images.

17:04:13 <mortenf> good point libby, that'd get us scratching heads later

17:04:27 <libby> - and tomorrow even....

17:04:29 * deelan finds all the images with a graffito depicted.

17:04:33 <deelan> nice!

17:04:38 <libby> you still can;t make it tomorrow mortenf?

17:04:42 <libby> :)

17:04:45 * libby loves graffiti

17:04:48 <mortenf> no...

17:04:51 * deelan too

17:04:52 <GregElin> See..I like this: http://swordfish.rdfweb.org/discovery/2001/08/codepict/aboutimage.jsp?uri=http://www.ilrt.bris.ac.uk/~edxps/www2003budapestweb/images/IM004581.jpg

17:05:13 <libby> heh yeah, that's one of my colleagues

17:05:19 <GregElin> I'm curious who that is, where he is, and why it is interesting for him to be next to diving suit.

17:05:38 <libby> it was just in the street!

17:06:01 <deelan> libby, annotate this: http://www.deelan.com/reflex/2003/08/amsterdam/P8160052.jpg

17:06:07 <GregElin> See! See! How would I know that? Maybe it was panel! (lol)

17:06:14 <libby> heheh

17:06:17 <libby> ok

17:06:27 <mortenf> jim, do you suggest a single property for all region descriptions, or should we go with "polygon", "circle" and "ellipse" from SVG?

17:06:38 <libby> ooj, cool deelan

17:06:44 <libby> ooh I mean.

17:06:49 <libby> have you got a thumbnail for that?

17:07:26 <GregElin> I think it is a great example of the usefulness of the project...here's an image that in a way is so generic, it needs an explanation of why it is a part of the collection. Is it extra special? Is it just at a lunch? Is there and inside joke (drowning in a sea of information...)?

17:07:27 <deelan> very little: http://www.deelan.com/reflex/2003/08/amsterdam/tn-P8160052.png

17:07:32 <mortenf> or use "path" instead?

17:07:42 <libby> GregElin: http://www.ilrt.bris.ac.uk/~edxps/www2003budapestweb/pages/IM004580.html

17:08:11 * GregElin Wants to discuss rectangle, polygon, circle a bit more if others do.

17:08:19 <mortenf> me too...

17:08:35 * mortenf wonders if jim is still around

17:09:44 <GregElin> Just love it, libby. This is a great example. two images...related...possibility of some relevant story (or not), in a place I've never been (Budapest) so I might want to see where on a map. The diving sculpture must have some story of why it is on the street. Great example.

17:10:05 <libby> :)

17:10:08 <libby> excellent

17:10:17 <libby> I don;t know anything about why it's there though

17:10:28 <libby> although we had just been to the restaurant 'fatal'

17:10:32 <GregElin> And the sculpture even has interesting things to discuss...like that horn in left hand. or is it a bell?

17:11:08 <GregElin> Gawd...great. Now a story emerges...we were at a panel. We went to the restaurant 'fatal'

17:11:15 <libby> oh, btw, there are some copyright restrictions on the WWW1 photois - although I think just aknowledgements

17:11:23 <GregElin> We saw this statue. We don't know about. Maybe somebody else does...

17:11:31 <libby> and charles ate brains

17:11:41 <GregElin> And that's Charles?

17:11:57 <libby> no

17:12:18 <libby> Kieren

17:12:38 <GregElin> Looks like Jim left. Should we get him back to chat about shapes?

17:12:46 <JibberJim> I think a single property and make clients understand the rdf:Type - I think that's important.

17:12:56 <GregElin> Jim!

17:12:58 <libby> charles is here, eating brains at fatal: http://www.ilrt.bris.ac.uk/~edxps/www2003budapestweb/pages/IM004569.html (long hair and beard)

17:13:06 <mortenf> ok, so "path" from SVG?

17:13:53 <JibberJim> I think it depends what golbeck etc. use.

17:14:02 <mortenf> golbeck has "svgOutline", does that seem ok (could be svgPath)?

17:14:10 <JibberJim> path isn't essential.

17:14:34 <JibberJim> yeah I don't know what that is!

17:14:37 <mortenf> ok, but it conveys some meaning, although outline does as well

17:14:46 <bengee> re diving:

17:14:48 <JibberJim> I've got a feeling it's an actual lump of SVG (elements and everything)

17:14:49 <bengee> Harry Houdini (born Ehrich Weiss in Budapest, Hungary in 1874) was inventor of a "diver's suit" that permits divers, in case of danger, to quickly divest themselves of the suit while submerged and to safely escape and reach the surface of the water.

17:14:51 <GregElin> Jim, I think I am curious about what one, what this project, means by "client"

17:14:59 <mortenf> ah, i see

17:15:20 <mortenf> would a "real" SVG path be too minimal (e.g. no colors etc.)?

17:15:28 <JibberJim> this project means by client - is tools that consume the data.

17:15:38 <GregElin> ta-da...the power of the web. Thanks, bengee.

17:15:45 <bengee> ;-)

17:16:13 <JibberJim> I can't see how overlaying an actual SVG image adds much semantic information, it doesn't define a region (we can't do things like calculate the %age of the photo that is within that space.

17:16:23 <GregElin> by data do you mean rdf data, or any type of data including pixel data?

17:16:45 <mortenf> also, using just the path would leave coloring etc. up to the client and possibly prevent attacks

17:17:18 <GregElin> I like the word "outline" and the word "regionoutline"

17:18:41 <mortenf> i say we use a simple literal property, containing an svg path

17:18:43 <GregElin> I think there is something special about rectangles. All polygons fit inside a rectangle.

17:19:06 <mortenf> everything fits inside a rectangle, if big enough ;)

17:19:35 <GregElin> So I'm wondering about if there is an important relationship between a path and a rectangle relative to clients and other applications.

17:20:12 <mortenf> hmm, yeah, i guess one should be able to quickly calculate a bounding box (rectangle) from a path

17:20:33 <mortenf> "outline" sounds good to me

17:21:18 <mortenf> we could even later add "box" or "boundingBox" as a subproperty of that

17:21:22 <GregElin> Or put another way...should the client creating/defining the region be responsible for identifying the default/alternative rectangle for the path, or is it the client's application renderding (consuming) the data be reponsible for parsing path?

17:22:04 <GregElin> I like "boundingBox", mortenf. And I like the idea that the creating client should/must include a boundingbox.

17:22:07 <mortenf> i think the client should do what it can, not restrict itself to rectangles if not necessary

17:22:11 <D[a]vey> D[a]vey is now known as Davey

17:22:14 <mortenf> yep, sounds good

17:22:30 <mortenf> not sure about must/should, though...

17:22:37 <mortenf> at least should...

17:22:56 <libby> D:[http://kanzaki.com/works/2004/imgdsc/0106.html#img-annot|Masahide's notes on image annoattion]

17:22:57 <dc_rdfig> Added comment D3.

17:23:04 <GregElin> This gives developers the ability to trust there is a boundingBox there and makes the path/polygon more extensible for clients with advance features.

17:23:15 <mortenf> yep

17:23:44 <deltab> what's the box going to be used for without regard to the path?

17:24:07 <mortenf> for simple clients not able to do svg?

17:25:16 <kota> http://kanzaki.com/works/2004/imgdsc/0106.html#img-annot $B?@:j@h@8$,=q$+$l$?%I%-%e%a%s%H$r(Blibby$B$,=P$7$F$^$7$?(B

17:25:16 <dc_rdfig> E: http://kanzaki.com/works/2004/imgdsc/0106.html#img-annot from kota

17:25:22 <kota> oops

17:25:28 <kota> excuse :(

17:25:35 <libby> what's up?

17:26:44 <kota> i'm translating this meeting into japanese on another channel, and i missselected the channel :(

17:26:57 <GregElin> Sorry...lost connection.

17:27:03 <GregElin> I missed a bit mortenf.

17:27:39 <mortenf> no, you're ok. anyway, i think it should be "should" for including a boundingBox, also to make developers realize that we can never expect anything to be present...

17:28:01 <GregElin> right mortenf, for simple clients. And as a transitional strategy.

17:28:02 <mortenf> jim, do you have any input on this?

17:28:12 <mortenf> yeah, good point

17:28:38 <bengee> consuming apps could still give onfo about depictedPersons and stuff, even if they can't render the outlines..

17:28:44 <bengee> info

17:28:48 <mortenf> true

17:29:24 <JibberJim> I'm not keen on enforcing creators to do anything.

17:29:25 <GregElin> Also, one can more easily make comparisons between rectangles than between different paths.

17:30:14 <bengee> would there be a single syntax for rectangles and polygons then?

17:30:29 <GregElin> Jim, that's a pretty broad statement, if taken to the extreme.

17:31:16 <mortenf> jim, i agree, hence the should instead of must

17:31:17 <deelan> bbl

17:31:23 <GregElin> I like Kanzaki's example, easy to read. I'd suggest the image:Rectangle be image:boundingBox additionally/instead.

17:31:27 <JibberJim> We can add a rectangle and a polyline representation of the same region

17:31:58 <mortenf> yep, that seems to be the most friendly way of doing it

17:32:21 <JibberJim> I'm also anti the SVG-Path, it's a lot more complicated than a polyline, and no tools produce anything more complicated than a polyline.

17:32:23 <GregElin> I like the idea of having both representations, kind of like the "alt tag" in image tags.

17:32:44 <JibberJim> all it really gives us is torus's and things rather than simple shapes.

17:32:49 <mortenf> hmm, but svg-path is a superset of polyline?

17:33:01 <mortenf> and it includes circles...

17:33:19 <GregElin> proposed consensus then? by convention (or something stronger one day) always include boundingBox (rectangle) in addition to polyline?

17:33:27 <bengee> is there an example for a polyline somewhere?

17:33:40 <JibberJim> svg-path includes circles? not really - it can approximate a circle as 2 arcs.

17:33:48 <mortenf> greg, yep, sounds good to me (except i'd go for path instead of polyline)

17:33:55 <mortenf> jim, yes

17:34:12 <JibberJim> - http://jibbering.com/rdf/example.rdf bengee

17:34:18 <GregElin> I'm okay with path or polyline. I wonder what is common OpenGIS?

17:34:25 <mortenf> but if we have a subclass of region named circle, i'd rather not describe it as a polyline

17:34:32 <GregElin> We haven't discussed the notion of a 'point' though.

17:34:40 <JibberJim> I'd go for both mortenf, but I expect more people will be using polyline (an imagemap can consume that too)

17:35:13 <bengee> ah, thanx. polyline owl:sameAs polypath then.

17:35:15 <GregElin> that's good, JibberJim, to be compatible with imagemap.

17:36:06 <GregElin> should we also sameAs boundingBox and Rectangle?

17:36:08 <mortenf> but imagemap can do more than that?

17:36:54 <GregElin> That creates a nice backward compatibility, if we need to worry about that at this point.

17:38:23 <mortenf> i think we should have more than polyline, but if we can't go for svg-path (one-property-fits-all), then we should have two (or more) for each region type

17:38:38 <mortenf> erh, one for each region type...

17:38:52 <GregElin> One each of ???

17:39:11 <GregElin> rather, one of ?? for each region type?

17:39:12 <mortenf> we would subclass region to circle, polygon, rectangle etc.

17:39:32 <mortenf> ... properties describing the region

17:40:46 <mortenf> a rectangle can be described by a polyline, but a circle can't, so for circles we'd need another property

17:41:21 <GregElin> I think I want to try and avoid a battle between all these different possibilities by suggesting people can subclass etc as they want and should include boundingBox as a default "universal"

17:42:08 <mortenf> agree, but if two clients (one creating, one consuming) can both do circles, they should be able to take advantage of that

17:43:06 <GregElin> Absolutely!

17:43:13 <GregElin> +1

17:46:03 <mortenf> jim, do you suggest going with two properties then (in addition to boundingBox), one polyline syntax for polygons, one for circles/ellipses?

17:47:04 <JibberJim> A consuming application should easily be able to go from a polyline to a bounding box, with this in mind, why should we clutter the RDF with redundant information?

17:47:20 <JibberJim> morten, I think we should have lots of regions, at least rect/circle/polyline/path

17:47:31 <mortenf> agree

17:47:42 <GregElin> me, too.

17:47:43 <mortenf> but i'm still holding on to a real circle here

17:48:10 <GregElin> (Or more likely, an oval...more in the photographic tradition.)

17:48:20 <mortenf> yeah, that as well

17:48:38 <bengee> why not consequently use svg? too complicated for simple shapes?

17:50:05 <mortenf> yeah, somewhat, a "path" can include bezier curves

17:52:15 <mortenf> so, again, a single property (path) for all types of regions, or minimal for each type (polyline syntax for polygons), path for the rest (possibly a subset of path for circles/ellipses)?

17:52:26 <GregElin> All good things in good time, including bezier curves. But I think things like bezier curves is what slows down adoption of SVG standard...narrows the players that develop tools/hack around.

17:52:36 <mortenf> indeed

17:52:46 <deltab> I think bezier curves are limited to the region within the control points and endpoints

17:53:33 <mortenf> true, that can be an advantage

17:53:53 <mortenf> (although it can make an outline look strange)

17:54:05 <deltab> the convex hull, it's called

17:54:23 <mortenf> well, larger than the convex hull, but yes

17:55:49 <mortenf> hmm, i guess we won't get this closed now, should we end the meeting and leave it up to the write-up by jim and myself?

17:56:02 <mortenf> (and further discussion, of course)

17:56:14 <JibberJim> no creation tools will be using bezier curves.

17:56:23 <mortenf> agree

17:56:26 <bengee> don't no much about svg, but I would try to support the basic shapes from http://www.w3.org/TR/SVG/shapes.html

17:56:50 <bengee> without "line"..

17:56:54 <GregElin> I like that, bengee...supporting basic shapes.

17:57:47 <mortenf> agree, but as it says: "Mathematically, these shape elements are equivalent to a 'path' element that would construct the same shape."

17:57:59 <mortenf> of course, bezier is not a basic shape...

17:58:34 <deltab> it's basic enough for many graphics systems

17:58:40 <mortenf> ok, so we have a property for each region type, named the same, and a boundingBox?

17:59:00 <bengee> ah, ok. just thought it might be easier for a tool developer to start with simple rectangles..

17:59:01 <GregElin> +1!

17:59:16 <GregElin> the boundingBox = the simple rectangle.

17:59:18 <mortenf> that also make owl more fun...

18:00:03 <mortenf> region types: circle, ellipse, polygon. more (still excluding boundingBox)?

18:00:07 <JibberJim> I'm anti the bounding box - why have to add it in the RDF?

18:00:33 <mortenf> to ease the pain for some simple tool makers?

18:00:46 <mortenf> but i see your point, if we don't do path, it's not really necessary

18:01:31 <mortenf> except that it provides a way to assert something less precise on purpose

18:02:29 <GregElin> I like less precise on purpose.

18:03:12 <mortenf> but still, it's only a "should", so can't be relied on (either)

18:03:15 <bengee> is there already an rdf schema for svg shapes perhaps?

18:03:34 <mortenf> i think jim's is the closest one?

18:04:06 <GregElin> Okay...consider this situation. Take a photo X. Created RDF by two tools: T1 and T2.

18:04:28 <JibberJim> It's machine generatable though from polyline/circle etc. (I can supply source code) I'd be more interested in having the area of a Region in there, but that is far from simple.

18:04:43 <mortenf> that's the exact same thing?

18:05:12 <GregElin> T1 is SVG and uses bezier curves. T2 uses polypath. The two overlap...in more than one place.

18:05:53 <GregElin> How do you "decide" if T1 and T2 are addressing the same part?

18:06:57 * libby has to go - I made an rdf datasource thing as a temporary place for project data - any comments would be great: http://sw1.ilrt.org/discovery/2004/01/w3photo/

18:07:21 <GregElin> To make a judgement, I have to parse both...then have some rules to define overlap. My rules are likely to be unique to me.

18:07:23 <libby> I hope it's the sort of thing you were after

18:07:31 <libby> bye!

18:07:33 <bengee> bye libby.

18:07:34 <GregElin> later libby!

18:08:15 <GregElin> Most likely, I make a first pass at comparison by calculating T1 and T2's implied bounding box.

18:08:37 <GregElin> Plus I have to have the code to parse these different shapes in these different standards.

18:09:24 <mortenf> what's the use case for finding overlap?

18:09:25 <GregElin> But the reality is this: most are rectangular and will be that way for sometime b/c of cultural momentum.

18:11:17 <GregElin> T1 and T2's meta data of photo X has content from Person1 and Person2. Person1 and Person2 may not call the annotated region the same thing. Tomata/tomato, man/hombre, Bruce/Dad.

18:11:44 <JibberJim> Hey, sorry about that my CGI:IRC died, had to come to coffee shop

18:12:08 <mortenf> strange, i didn't see you leave the channel...

18:12:15 <JibberJim> I was never on the channel!

18:12:35 <dajobe> is the meeting over?

18:12:43 <mortenf> weird

18:12:47 <mortenf> almost, dajobe

18:12:58 <GregElin> Without being able to use the overlap as possible x-reference...to rely only on the respective ontologies behind T1 and T2 means a mapping must be done. The overlap use case enables the possibility of using the regions to help cross-reference and map different ontologies.

18:12:59 <JibberJim> you can un +n again dajobe

18:13:10 <mortenf> ah, i see :)

18:13:41 <JibberJim> You can never work out that T1 and T2 address the same part Greg, and I'm not sure of the use cases when you want to.

18:14:24 <GregElin> Can you Jim, if T1 was done in 2004 in USA and T2 was done in 2006 in China?

18:14:45 <JibberJim> Then they can't be the same parts of an image.

18:14:51 <bengee> I guess such stuff could only be done if one region is completely inside another one..

18:15:11 <bengee> and even thenn.. dunno

18:15:15 <JibberJim> Are you sure you're not asking how we identify the same Person is depicted in T1/T2 ? That's a solved issue, we use IFPs

18:15:16 <GregElin> Sorry, Jim. I missread your post. I read "you can always".

18:15:57 <GregElin> You are right, Jim. You can't be certain...but I think there are some very good guesses the computer could make.

18:16:30 <JibberJim> sure, but that's outside the model, and implementation specific.

18:16:37 <bengee> so, what were the options again? having a single prop for an area's description or having multiple.

18:17:03 <bengee> with polyline being able to be used instead of rectangles?

18:17:19 <bengee> proble: circles and ellipses?

18:17:26 <mortenf> yeah, but a rectangle is just a simple polyline

18:17:32 <JibberJim> We've definately got to be able to use polyline bengee, there's no point doing less than we were doing in 1999...

18:17:45 <GregElin> The implementation is easier, outside the model, if rectangles are predefined.

18:18:00 <JibberJim> It's not for me, it's significantly harder

18:18:07 <bengee> jim: sure, I fully agree. just wanted to summarize a little

18:18:44 <GregElin> It's a celcius v farenheight translation...it can be done...but it is more work than converting meters to feet.

18:19:14 <JibberJim> virtually nothing in a photo is rectangular, I don't think saying "this part of a photo depicts something when it's a rectangle" I'd rather say "this part of a photo contains a depiction of something"

18:20:01 <bengee> I have no problem with polyline only, if the syntax for basic shapes (i.e. rectangles) is not too complicated.

18:20:35 <JibberJim> I want basic shapes aswell as polyline - if it is a rectangle, or a circle or whatever then that contains more information than just a polyline.

18:20:41 <GregElin> Me, too, jim.

18:21:08 <mortenf> how so, more for a rectangle than polyline?

18:21:22 <GregElin> But a browser can't display a polypath in an <img src> tag.

18:21:47 <JibberJim> A browser can't display a rectangle in an img-src either Greg.

18:22:07 <JibberJim> However I can generate a jpg with the cutout region using Image Magick on the server for example

18:22:36 <GregElin> So given the polypath (or whatever), to display that which is depicted, I'm going to have to either (a) calculate the boundingBox and crop it or (b) fill in the absent pixels from the implied bounding box.

18:22:55 <JibberJim> What are you going to do when it's a rectangle?

18:24:11 <GregElin> Does Image Magick output a rectangle? Or is there more coding that has to be done to create the rectangle from the cutout region?

18:24:17 <JibberJim> ie http://jibbering.com/rdf/outlines/mailto-jim-jibbering.com-0.jpg can be displayed in a <img src> and is generated from a polyline.

18:25:19 <GregElin> PHP and Java both have "copy rectangle from image" as part of the default functions. I'm not sure either will produce a new jpg from an irregular polygon.

18:25:45 <JibberJim> yes, but you don't need to use the irregular polygon, just calculate the bounding box and use that!

18:26:22 * bengee just found out that "polyline" and "path" are different. that's why he didn't understand jim's rdf with Ms an Ls

18:26:56 <JibberJim> yeah, that RDF is using paths, I've since decided polylines are easier - those paths can be converted to polylines with a simple regexp.

18:27:09 <JibberJim> sorry to confuse.

18:27:29 <bengee> np, I'm new to svg..

18:29:22 <bengee> so a polyline rectangle would be easy to do.

18:29:46 <bengee> or a translation between the two of them..

18:30:00 <JibberJim> How do you mean? calculating a bounding box for simple polylines (an outline of something) is not that hard no.

18:35:23 <bengee> that's great. but nevertheless you'd vote for a svg:rectangle as well, if I got you right?

18:35:30 <JibberJim> Oh yeah

18:36:03 <JibberJim> but I would not suggest marking up a bounding box in addition to a polyline, the polyline is the information, the bounding box isn't.

18:36:10 <bengee> ok, mindlab is using svg rectangles as well, but use a quite verbose syntax.

18:36:35 <bengee> so I would basically vote for jim#s approach then.

18:37:11 <bengee> supporting both rectangles and polylines (paths?)

18:37:41 <JibberJim> There's lots of stuff we could add to the RDF that is useful to tools, for example the area of the region, but a boundingBox of a polyline and a Rect are different things and I don't think they should be confused.

18:39:09 <bengee> I would agree on that.

18:39:56 <bengee> APIs could auto-create boundingBoxes from polylines, if wanted?

18:40:13 <JibberJim> Yeah, the code is pretty simple.

18:41:11 <bengee> maybe we keep it with that for 2day?

18:41:17 <bengee> greg is gone..

18:44:36 <JibberJim> I'd support a something:boundingBox that could be added to a region, but I would want it to mean something different than a rectangle depicting something if you see what I mean.

18:45:10 <JibberJim> and definately no should/must on including it.

18:49:28 <bengee> I see. than boundingBox should be some "facet" or "meta" thing, but not be able to "overwrite" the original Region.

18:50:05 <JibberJim> Yeah, the bounding box is metadata about the depiction region, and not the depiction region itself.

18:50:22 <JibberJim> I'd like to find out if I'm unique in this view, it's a shame golbeck's not here.

18:51:00 <bengee> otherwise the region description would be ambiguous. yes. now I finally understand.

18:51:04 * mortenf is back

18:51:16 <mortenf> i don't disagree on the boundingBox being a property of the region

18:51:53 <JibberJim> and I don't think metadata about the region has any place being required (even should)

18:52:30 <mortenf> agree again, as i said, it should be a "should" not a "must"

18:52:39 <mortenf> why not should?

18:52:43 <bengee> or a "may"?

18:53:00 <mortenf> anyhow, we can do without, if we don't do path...

18:53:05 <JibberJim> because I don't like adding triples to my files whcih do nothing.

18:53:19 <mortenf> but you don't mind area???

18:53:27 <JibberJim> especially when they cost considerable cycles to compute. No I don't want to add Area either!

18:53:41 <JibberJim> not as should, you can if you want.

18:54:06 <JibberJim> basically if I want to query on AREA, I'll add in the generation of those triples to my store.

18:55:04 <mortenf> ok, then i think we can agree on polyline, circle and ellipse?

18:55:11 <mortenf> there's no need for rect, right?

18:55:11 <JibberJim> rectangle

18:55:19 <mortenf> why?

18:55:32 <JibberJim> There is, a rectangle has more meaning that a circle - it's the same as in SVG, SVG doesn't need anything but PATH

18:55:51 <mortenf> not sure i follow?

18:55:56 <JibberJim> but accessibility wise and semantically a rect is more meaningful.

18:56:06 <mortenf> but it's just a polygon...

18:56:20 <bengee> if we drop rectangle, people will probably complain. I would include it.

18:56:42 * JibberJim has to go, I'll be back once I've moved to my next source of free bandwidht.

18:56:54 <mortenf> what's the difference between a rectangle and a polygon with 4 points?

18:57:10 <mortenf> (one that is a rectangle, that is)

18:57:14 <bengee> none, I guess

18:57:54 <bengee> but don't you think that we should support it anyway?

18:58:16 <bengee> maybe just for reasons of perception?

18:58:49 <mortenf> i don't see why one should have to look for two properties, when one can do

18:59:07 <mortenf> as it is, we've already got three where one would do...

19:00:09 <bengee> agree. but imagine a tool builder who would be fine with rects and doesn't want to parse polyline values in order to find out if it has 4 points only?

19:00:39 <bengee> dunno if this is a real argument..

19:02:23 <mortenf> i see your point, but when the tool has to find the outline, it has to make separate queries for each type (at least for rdql)

19:03:25 <bengee> that's true, a single prop would defintely be better in this case.

19:05:15 <bengee> so, which opinions do we have now?

19:05:39 <bengee> greg would like a boundingBox.

19:06:12 <bengee> jim wants both rectangle and polyline

19:06:24 <bengee> and maybe circle?

19:06:25 <mortenf> hmm, yeah, but i think greg might agree that it's not necessary when we don't do path

19:06:32 <mortenf> jim's fine with circle etc.

19:06:59 <mortenf> i'd like path, but can live with separate properties, don't want rect

19:07:54 <bengee> I can agree to anything that I can implement. that could both be polyline for rectangles or explicit rectangles

19:07:54 <mortenf> anyway, i think we should call it off now, and let jim and i post a mail with the options, leave the decision to later

19:08:08 <bengee> ok.

19:08:23 <mortenf> so, the two of us agree that the meeting is over? :)

19:08:41 <bengee> agreed.

19:09:33 <bengee> and noone voting against ;-)

19:09:48 <mortenf> C:ACTION jim and morten also list options for describing a region, whether by SVG-path or polyline/circle/ellipse, and whether to include rect.

19:09:48 <dc_rdfig> Added comment C10.

19:09:49 <mortenf> :)

19:10:23 <mortenf> C10:ACTION jim and morten also list options for describing a region, whether by SVG-path or polyline/circle/ellipse, and whether to include rect and an optional bounding box.

19:10:23 <dc_rdfig> Replaced comment C10.

19:10:34 <mortenf> adjourned!

19:11:11 <mortenf> the meeting is now over, thanks for listening. now back to your regularly scheduled semweb hacking...

19:19:51 <Davey> Davey is now known as D[a]vey

19:26:08 <mortenf> hey jim, where are you at now?

19:28:19 <JibberJim> My old office

19:28:28 <JibberJim> they've not changed the locks or alarm code :-)

19:28:33 <mortenf> heh

19:28:56 <mortenf> don't forget to punch in!

19:38:22 <JibberJim> hey cool, the office has a new mini-pci card wireless card for my laptop...

19:57:50 <D[a]vey> D[a]vey is now known as Davey

20:58:32 <Davey> Davey is now known as D[a]vey

21:01:48 <GNUMonkey> GNUMonkey is now known as mdupont

21:22:02 <mortenf> re bounding box being a property of the region's representation by points etc., we'd need to represent the representation by a class to be able to attach a bounding box

21:23:11 <mortenf> i'm not sure the set of points describing a polygon is that separate from the region itself

21:23:55 <JibberJim> I'm concerned a little that bounding box calculations will not be 100% precise.

21:24:09 <mortenf> how so?

21:24:57 <JibberJim> Well, they're not that precise, remember by SVG polylines go subPixel.

21:25:38 <mortenf> hmm, i'm no expert in svg, but i'm talking regular math here, i think?

21:26:00 <JibberJim> yeah, but people generating the rect will expect INT's won't they?

21:26:11 <mortenf> who says? :)

21:26:11 <JibberJim> As we're doing it so they can easily chop out a rectangle.

21:26:57 <mortenf> i proposed it for clients that didn't have full svg support (it was in the "path" context), and who cares if it's off by a pixel?

21:27:47 <JibberJim> I suppose it matters little, okay we can have boundingBox on a region.

21:27:59 <JibberJim> as far as I'm concerned at any rate

21:28:18 <mortenf> but as i said, i don't see the need if we don't do path - it's easily calculated otherwise

21:28:39 <JibberJim> I agree, but some tools may have it for free, and can offer it up aswell.

21:28:45 <mortenf> true

21:28:53 <mortenf> so, which syntax?

21:29:09 <JibberJim> the circle people for example, it's very cheap to generate then, so we should agree a syntax, but I don't think SHOULD is necessary.

21:29:21 <mortenf> for polygons, circles etc. (let's wait a sec with rectangle)

21:29:26 <mortenf> "should" for?

21:29:37 <JibberJim> the bounding box

21:29:42 <mortenf> ok, "MAY"?

21:29:45 <JibberJim> YEP

21:29:48 <mortenf> :)

21:30:14 <JibberJim> What's masaka doing in his latest stuff?

21:31:30 <mortenf> polyline/polygon points

21:31:41 <JibberJim> do we just go with the points property suggested by image.1 ? it sorta works?

21:32:01 <JibberJim> or do we have seperate ones for circles/polygons?

21:32:18 <mortenf> yep, agree on syntax, but should be separate properties

21:32:33 <JibberJim> Why?

21:32:56 <mortenf> how would you represent an ellipse?

21:33:14 <JibberJim> an img:Ellipse and ...

21:34:09 <JibberJim> I'm not anti seperate properties, like to see the motivation behind them though.

21:34:34 <mortenf> sure, i just think it'd be confusin having to parse the contents of the property to see if you could handle it

21:34:53 <mortenf> also, doesn't extend well (re ellipse)

21:35:12 <JibberJim> what's the imagemap syntax?

21:35:16 <mortenf> erh

21:35:59 <JibberJim> because I've got the feeling that for points/rect/circle it'll map straight into that.

21:37:35 <mortenf> well, almost it seems

21:37:47 <mortenf> they've got commas everywhere

21:37:54 <mortenf> and no ellipse

21:38:16 <mortenf> i'd think svg compat would be better?

21:39:19 <JibberJim> the polyline is!

21:39:33 <JibberJim> who's gonna be doing SVG other than me anyway :-(

21:39:55 <mortenf> think of the future, not the past...

21:40:22 <mortenf> it is? don't you have spaces between points?

21:40:27 <JibberJim> either

21:40:35 <mortenf> oh

21:40:46 <mortenf> but svg has spaces, right?

21:40:48 <JibberJim> I think, I'll just check

21:42:18 <JibberJim> Yep, SVG is either comma or wsp, it's not bothered

21:42:27 <mortenf> oh, ok, good

21:43:27 <mortenf> so what do we do for ellipse (and general extensibility)?

21:44:00 <JibberJim> we can have other properties then, they'll be in a seperate class.

21:44:20 <JibberJim> as long as we educate us tool developers to expect unknown classes we'll be okay!

21:44:40 <mortenf> so you suggest using the rdf:type to interpret the points property?

21:45:07 <JibberJim> Yes.

21:45:30 <JibberJim> which should be xslt'able shouldn't it in a "normal" serialisation?

21:45:42 <mortenf> hmm, i'm wondering if there'd be a conflict with a subclassed rectangle off of polygon

21:45:53 <mortenf> oh sure

21:46:12 <JibberJim> polyline you mean?

21:46:21 <mortenf> well, perhaps?

21:46:33 <mortenf> why do you insist on polyline as opposed to polygon?

21:46:46 <JibberJim> because of the syntax of points I guess :-)

21:47:06 <JibberJim> (the need to be closed for SVG compatibility that you mention)

21:47:29 <mortenf> yeah, for polypoints?

21:47:45 <mortenf> imagemaps do auto-close

21:48:16 <JibberJim> we need path aswell, annotating donuts will be possible then.

21:48:25 <mortenf> don't start :)

21:48:42 <mortenf> we were almost there...

21:49:02 <JibberJim> If we call it Polygon we lose SVG compatibility (xslt'able SVG compatibility) but we gain some neatness.

21:49:12 <mortenf> why?

21:49:45 <JibberJim> because we won't have the extra last point doubled up.

21:49:58 <mortenf> but it's not needed for polygons?

21:50:31 <JibberJim> oh yeah right sorrym, if you use the polygon element rather than polyline one...

21:50:49 <mortenf> ok, so we can use polygon?

21:51:48 <mortenf> there's no (other) difference in syntax between polylines and polygons, right?

21:52:27 <JibberJim> nope, we can use Polygon.

21:53:16 <mortenf> ok, i guess we're done then?

21:53:42 <JibberJim> yep, I think so.

21:54:15 <mortenf> let me append my writing and show it to you, then i'll send it off

21:54:27 * JibberJim in need of food!

21:56:20 <mortenf> hmm, i guess we didn't solve the ellipse problem...

21:57:01 <JibberJim> a new property for those, it's more complicated

21:57:08 <JibberJim> a new property for the img:Path

21:57:33 <JibberJim> and new properties for the img:Composite (which is an rdf:Bag of other img parts...)

21:57:39 <mortenf> ouch

21:58:12 <mortenf> hmm, no better name for "points", since it can include radius for circle?

21:58:16 <JibberJim> well consider the panel - they're a collection of all the panel members we've chopped out.

21:58:30 <JibberJim> coords?

21:58:59 <mortenf> yeah, i guess

21:59:07 <mortenf> coords it is, for now at least

21:59:41 <JibberJim> it's just for the suggestion, I'd like to see Masaka's and Jen's input on this, both have done lots on it,

21:59:59 <mortenf> indeed

22:00:21 <mortenf> i think the wording should be "soft" enough to not look like it's a done deal

22:01:10 <JibberJim> yep.

22:14:26 <JibberJim> I'm off mortenf, I agree with whatever you send, or I'll moan on list if not :-)

22:14:36 <mortenf> cool :)

22:15:13 <JibberJim> bye

23:36:43 <mortenf> hi golbeck

23:37:28 <mortenf> i'd ask for comments on the action jim and i have been assigned, but it's almost done and i'm off to bed, i hope we can continue discussion on the list

23:40:19 <golbeck> hi, mortenf

23:41:42 <mortenf> ... but as you can probably tell, we've largely skipped multimedia for now...

23:41:58 <mortenf> erh, "we" as in the ones at the meeting :)

23:42:46 <golbeck> i would like to have been in on the discussion today, but we had an all day, and for some reason, internet disconnected meeting at MINDSWAP

23:43:11 <mortenf> ah