#topicmaps@irc.freenode.net log for 2003-01-28

This log is automatically generated by an IRC bot from the traffic on the #topicmaps IRC channel on the irc.freenode.net IRC server. This file has the traffic for 2003-01-28. If you have questions regarding this log, please contact larsga@ontopia.net.

01:12:46 arnarl arnarl has quit None ("Using Kopete IRC Plugin")
04:08:24 GabeW GabeW has quit None ("Client Exiting")
10:26:57 arnarl arnarl has joined #topicmaps
10:27:02 arnarl hi
10:27:22 drrho Good evening (at least here)!
10:27:27 drrho * drrho is away: I'm busy
10:27:37 drrho * drrho is back (gone 00:00:09)
10:27:49 larsbot morning/evening, everyone
10:29:54 drrho I would imagine that it is a lot of work for Steve to create a new, consolidated TMCL-req document...
10:30:21 larsbot I think it will be gra/mariyo who do it
10:30:58 drrho Good.
10:37:34 gra gra has joined #topicmaps
10:37:43 gra morning
10:37:57 larsbot morning, sir :)
10:38:03 gra i need 2 minutes
10:38:06 larsbot no problem
10:39:45 larsbot gra: greetings from pepper, btw
10:41:20 gra right I'm back - please say hi to steve
10:41:46 larsbot will do
10:42:01 larsbot ok, what I thought we'd do was to go through all the open issues
10:42:06 gra yep
10:42:06 larsbot and work out our position on each of them
10:42:20 gra is there a list ?
10:42:22 larsbot we can then publish that as a document to go with the SAM
10:42:32 larsbot try here: http://www.ontopia.net/omnigator/plugins/tolog/query.jsp?codeexample=&query=issue-in%28sam+%3A+spec%2C+%24ISSUE+%3A+issue%29%2C+not%28status-of%28%24ISSUE+%3A+issue%2C+resolved+%3A+state%29%29+order+by+%24ISSUE%3F&rules=&tm=tm-standards.xtm
10:42:50 gra it'll be nice to tidy the sam up by removing all the inline comments
10:42:57 larsbot yes, exactly
10:43:13 larsbot but we still need the flags for the issues, but that will then be in a separate document
10:43:25 gra whats an Omnigator servlet error?
10:43:35 larsbot an indication that it does not work :-)
10:43:52 larsbot ok, go to: http://www.ontopia.net/omnigator/models/topicmap_complete.jsp?tm=tm-standards.xtm
10:43:58 larsbot click on "Query" up at the top right
10:44:13 gra yep
10:44:22 larsbot then cut and paste this: issue-in(sam : spec, $ISSUE : issue), not(status-of($ISSUE : issue, resolved : state)) order by $ISSUE?
10:44:31 larsbot into the search box, and press Query
10:44:40 gra ok
10:45:27 gra is that all thats left now?
10:45:31 larsbot yep, that's all
10:45:44 gra just start at the top?
10:45:48 larsbot yeah
10:45:58 larsbot so, first one: constr-single-subject-address
10:46:16 gra exception
10:46:21 larsbot uh?
10:46:55 gra ok, how can this be violated - as I see it
10:47:07 gra only a topic having 2 resource refs
10:47:23 gra is currentl detectable
10:47:42 larsbot yep. so this constraint is located in the merging section
10:47:55 larsbot it's triggered if you try to merge two topics with different subject addresses
10:47:56 gra yep - and we have a topic map exceptiondefined there
10:48:42 larsbot there are two questions here, actually:
10:48:49 larsbot 1) is this *really* an error?
10:48:56 larsbot 2) if it is an error, what is the resolution?
10:49:34 larsbot to take an example, the URI http://psi.oasis-open.org/
10:49:46 gra hmm - all other 'contradications' such as 2 topics with the same name have a resolable outcome
10:49:48 larsbot resolves to the same disk file as a URI under the PubSubj TC web space
10:49:54 gra yep
10:50:09 larsbot so these two URIs, though different, *do* address the same resource, in a very real way
10:50:35 larsbot the XMLvoc ontology analysis also indicated that there would be a need for this
10:50:46 larsbot so I'm wondering if we should lift this restriction
10:51:06 gra agreed - it would be an inappropraite constraint
10:51:31 gra especially as there is an equal problem with subject indicators
10:51:37 gra but in reverse
10:51:55 larsbot what's that?
10:52:25 gra its like, with res ref we match on the string because that implies
10:52:54 gra some unambiguous identity
10:53:07 larsbot yep?
10:53:26 gra where as subj ind refs we match on for strings but dont check for contradictions when we have more than one
10:53:28 gra becuase we cant
10:53:41 larsbot exactly, and I think the situation is the same with subject addresses
10:53:55 gra thus, we shouldnt restrict one and not the other
10:54:00 larsbot agreed
10:54:12 larsbot conclusion is that we lift the restriction, then?
10:54:20 larsbot and [subject address] becomes [subject addresses]?
10:54:23 gra so for consistency and expressiveness we dont constrain things
10:54:29 gra yep
10:54:47 larsbot excellent
10:55:00 larsbot next issue: locator-notation-support
10:55:30 larsbot tmbot: load: tm-standards.xtm
10:55:42 larsbot tmbot: show: locator-notation-support
10:55:56 larsbot we now have only one listed in the SAM: "URI"
10:56:01 larsbot the question is, do we need any more?
10:56:07 mariyo mariyo has joined #topicmaps
10:56:12 gra or should we even ditch that
10:56:22 larsbot what do you mean?
10:56:31 gra i.e. dont impose anything
10:56:36 larsbot hi mariyo: SAM editor's IRC meeting in progress :)
10:56:38 mariyo good morning!
10:56:43 gra morning
10:56:52 larsbot ah, I think I see
10:57:04 larsbot so we list the notations there are, but don't require people to support any specific set of them?
10:57:10 gra yep
10:57:18 larsbot I'm fine with that, actually
10:57:27 gra we list some of the possible ones
10:57:28 larsbot especially as what syntaxes you support will determine this, anyway
10:57:39 larsbot we do have an issue of which ones to list, though
10:57:56 gra but that list is informative rather than constraining
10:58:10 larsbot it is, but we still need to work out what should be on it :)
10:58:16 larsbot should IRIs be there? HyTime locators?
10:58:28 gra is this a new issue?
10:58:37 gra What locator notations, if any, must be supported? None
10:58:59 larsbot yeah, this is sort of a new issue, but I think we have to do it now
10:59:10 larsbot I agree the resolution is "None", as you say
10:59:43 gra i dont know what we should suggest, as many as possible would be good
10:59:53 gra to give the impression the list is extensible but also
11:00:10 gra to ensure that if people glance at it they see there mechanism
11:00:24 gra ?
11:00:40 larsbot I agree with the principle, I think
11:00:52 larsbot that means we should add HyTime locators, which is fine (HyTM needs that anyway)
11:01:06 larsbot the question is what to do with IRIs
11:01:15 gra whats the current status here?
11:01:15 larsbot they are described in: http://www.w3.org/International/iri-edit/draft-duerst-iri.html
11:01:26 larsbot see also http://www.w3.org/2001/tag/ilist#IRIEverywhere-27
11:02:49 larsbot the status is that IRIs are currently a draft
11:03:09 larsbot they seem to be incompatible with URIs only in surface syntax
11:03:19 gra lets not go there then
11:03:19 larsbot (character encoding of non-ASCII characters, basically)
11:03:39 larsbot in other words: push this down for the syntaxes to worry about?
11:03:42 gra i think the earlier idea to list lots was bad
11:03:54 larsbot there aren't lots to list, anyway :-)
11:04:16 larsbot why don't we say we list two: URIs, because XTM uses them, and HyTime locators, because HyTM uses those?
11:04:28 gra yep - sounds sensible
11:04:43 larsbot excellent. then we've resolved two issues, one with a name, and one without
11:04:44 gra what does the OASIS tc work do?
11:04:56 larsbot it doesn't deal with this stuff
11:04:59 gra ok
11:05:01 larsbot it's about what the URIs resolve to, basically
11:05:14 larsbot ready for next one?
11:05:15 gra what do they define for the notation of subj inds?
11:05:20 larsbot nothing :-)
11:05:30 gra safe then
11:05:35 larsbot yep
11:05:44 gra next issue
11:05:52 larsbot tmbot: show: names-as-subjects
11:06:09 larsbot I think your opinion is spot-on: this is bad jazz, and we don't want to go here
11:06:22 larsbot it was raised by RM<->SAM issues, but I think it's a result of trying to view the SAM as if it were the RM
11:06:35 larsbot my view: let's close it without doing anything
11:06:40 gra hmm
11:06:47 gra i have more questions though
11:07:02 gra if the TNC still exists (be it optional)
11:07:07 gra what happens?
11:07:30 larsbot see http://www.isotopicmaps.org/sam/sam-model/#sect-name-types
11:08:06 larsbot this issue is really about the name strings qua name strings, but independent of any topic
11:08:17 larsbot TNC is about using names as identifiers for topics, which is something else, really
11:08:44 larsbot the RM view is that I should be able to speak about "Graham" as a first name, and then have what I say apply to all the base names "Graham" in the TM
11:08:53 larsbot independent of their connection to a topic
11:09:21 gra ok - what the proposal - say nothing on this issue?
11:09:25 gra close it?
11:09:26 larsbot yes
11:09:58 gra ok and when I merge two topics with the same name and both names are reified with a topic what happens?
11:10:22 larsbot if the names are equal they merge, and the topics reifying them also merge
11:10:35 larsbot if they are different they are just attached to the same topic and nothing more happens
11:10:39 gra maybe we should state that explicitly in merging
11:11:05 larsbot all of this is in there explicitly, but you have to look in different places to find out
11:11:06 gra the bit about any constrcut that has a reifiing topic the reifing topcsi will be merged
11:11:26 larsbot see last bullet point of http://www.isotopicmaps.org/sam/sam-model/#sect-merge-topics
11:11:41 larsbot that should cover it, I think?
11:12:09 gra i'm not sure
11:12:16 gra thats the condition for merging
11:12:37 gra in the numbered list it should state that
11:12:59 gra if the constructs have a reifying topic those topics must be merged
11:13:15 larsbot but that's the same as what the bullet list says
11:13:39 larsbot and we'd have to repeat it for variant names and associations and occurrences and association roles
11:14:09 gra we'll it could be stated generally for all topic map objects
11:14:18 larsbot it is, in the bullet list :-)
11:14:49 gra no its not
11:14:59 larsbot I'm missing something, then
11:15:00 gra the bullet list is the condition for merging
11:15:10 gra i.e. two topics have the same name
11:15:20 larsbot yep
11:15:40 gra we merge them and find that two occurrences are the same
11:16:08 larsbot and then the two occurrences are merged into a single one
11:16:17 gra thus we 'merge' these occurrences and thus if these occurrences are reified by other topics those reifyoing topics are merged as well
11:16:23 larsbot yep
11:16:46 gra i dont see this expressed
11:17:02 larsbot ok, I'll walk through the steps and say where each is expressed
11:17:08 larsbot once I'm done you can tell me whether you're happy with it or not
11:17:29 gra ok
11:17:36 larsbot topics A and B are to be merged (for whatever reason)
11:17:46 larsbot A has the occurrence C and B has the occurrence D
11:17:56 larsbot C and D have the same type, locator, and scope
11:18:03 larsbot C is reified by E, and D is reified by F
11:18:08 gra yep
11:18:32 larsbot step 9 in the topic merge section (4.1) says to put all the occurrences into the same topic
11:18:40 gra agreed
11:18:49 larsbot definition of set in 2.1 then says that equal items must be merged
11:18:56 gra yep
11:19:15 larsbot last para of occurrence def in 3.7 says when occurrences are equal
11:19:25 larsbot conclusion: C and D must merge
11:19:38 larsbot section 4.5 tells you how to do that
11:19:45 gra 4.5 should then also state that the refication of the occurs should be merged
11:19:55 larsbot hear me out :)
11:20:02 gra ok
11:20:09 larsbot when you've done that E and F have the new occurrence in their [reified] property
11:20:18 larsbot hence, according to the rule in 4.1, they must be merged
11:20:20 larsbot done
11:20:29 gra when you've done that E and F have the new occurrence in their [reified] property
11:20:29 gra ??
11:21:07 larsbot if E reified C before the merge that means C has a [srcloc] that's equal to one of E's [subjids]
11:21:08 gra ok
11:21:15 larsbot that will still apply after the merge
11:21:26 larsbot [reified] is a computed property, so there are no identity issues there
11:22:15 gra ok - agreed :)
11:22:18 larsbot excellent :-)
11:22:35 gra i think that bit goes in advanced merging section of any tutorial
11:23:01 mariyo i would say so :)
11:23:03 gra next issue:
11:23:04 larsbot agreed
11:23:04 larsbot in fact, we should probably have something like that at some point
11:23:04 larsbot *and* there should be a test case for it
11:23:19 larsbot tmbot: show: prop-subj-address-class
11:23:26 gra yes
11:23:34 larsbot this comes from XTM, where <resourceRef> was not allowed in <instanceOf>
11:23:56 gra thats just a constraint of the syntax
11:23:58 larsbot we had an issue on whether implicit constraints like this should be mirrored in the SAM, and resolved it to "no"
11:24:01 gra we dont have to have it in the model
11:24:07 larsbot exactly
11:24:21 gra ok - so answer is yes
11:24:26 gra if we want to come back to this later
11:24:28 larsbot yep, it is
11:24:38 gra we could define a core set of TCML constriaints perhaps
11:24:43 larsbot exactly
11:24:48 gra done?
11:24:51 larsbot yep
11:25:02 larsbot then we have the same thing for scope
11:25:05 gra yep
11:25:06 larsbot I guess we resolve that the same way
11:25:25 gra yes
11:25:28 larsbot goodie :-)
11:25:38 larsbot tmbot: show: prop-subj-address-values
11:25:42 gra ok and we've already decided this one
11:25:45 larsbot this one we already did
11:25:47 larsbot yep :-)
11:26:09 larsbot tmbot: show: prop-value
11:26:24 larsbot this is the issue of what to call the [value] property of base name items
11:26:30 gra what have we got at the moment
11:26:34 larsbot it's called [value] now
11:26:50 larsbot [label] is proposed, as is [name string]
11:26:58 gra a basename has a value
11:27:06 gra it acts as a label for the topic
11:27:19 larsbot and actually we now call these topic name items...
11:27:24 gra if teh model were different I would agree that label haning off topic makes sense
11:27:38 larsbot you prefer sticking with value?
11:27:41 gra but we have baseName haning off topics and i reckon they have a value
11:27:43 gra yep
11:27:59 larsbot I guess it could also be topic name.[base name]
11:28:02 gra otherwise its like saying topic.name.name
11:28:08 larsbot yes :)
11:28:10 gra !!
11:28:37 larsbot ok, let's go for [value]
11:28:41 gra fine
11:28:57 larsbot done
11:29:07 larsbot tmbot: show: prop-variant-scope-superset
11:29:14 larsbot this was raised by Martin Bryan
11:29:26 larsbot HyTM doesn't require display/sort names to have a superset of the scope of base names
11:29:31 gra can this be solved in how we define teh mapping
11:29:42 larsbot yeah, if we just decide that's what we ant
11:29:50 larsbot personally, I feel XTM improves HyTM here, so...
11:30:06 gra its a non issue?
11:30:11 gra :)
11:30:25 larsbot yeah, I'd say so :)
11:30:31 larsbot ok, nex
11:30:32 larsbot t
11:30:43 larsbot tmbot: show: psi-identification
11:30:50 larsbot I agree with your opinion on this one: not for SAM to do
11:30:56 gra ok
11:31:06 xower xower has joined #topicmaps
11:31:13 larsbot next one
11:31:17 larsbot hi there, xower
11:31:24 xower Hi Lars.
11:31:25 larsbot SAM editor's meeting in progress here, so it's noisy :)
11:31:34 larsbot tmbot: show: psi-publishing
11:31:48 larsbot this one we actually did in Baltimore: they go on topicmaps.org
11:31:58 gra ok
11:32:03 xower SHame on you! You should be figuring out how to run Legemiddelverket's Tomcat app as a Service on Windows! :-)
11:32:11 larsbot xower: WTF? :)
11:32:11 xower * xower ducks and runs...
11:32:24 larsbot so I guess we do something like http://psi.topicmaps.org/sam/...
11:32:31 gra yep
11:32:38 larsbot then I'll create new URIs of that form
11:32:44 gra great
11:33:15 larsbot tmbot: show: psi-set-psi
11:33:28 larsbot ie: should we have a PSI for the SAM?
11:34:05 gra if we have the PSIs at topicmaps.org so we need one?
11:34:26 larsbot it's just an issue of whether the SAM should define a PSI you can use to identify it
11:34:28 gra wont the first part of those identifiers
11:34:32 gra be it?
11:34:39 gra http://psi.topicmaps.org/sam/
11:34:53 larsbot yes, we could do it that way (that's what GeoLang does now)
11:34:56 larsbot yeah, let's say that
11:35:03 gra and for versions?
11:35:09 gra http://psi.topicmaps.org/sam/1.0 etc
11:35:11 gra http://psi.topicmaps.org/sam/ latest
11:35:17 larsbot makes sense to me
11:35:22 gra ok
11:35:27 larsbot settled, then
11:35:43 larsbot tmbot: show: psi-subclassing-loops
11:35:43 gra next issue : yes
11:35:49 larsbot this one's a real bastard
11:36:06 larsbot basically, the issue is: are you allowed to do a -> b -> c -> a
11:36:08 gra yep - but if we're considering tmcl having some OWL like properties then we cant rule it out at the SAM level
11:36:23 larsbot well, the SAM defines the superclass/subclass association
11:36:36 larsbot so either the SAM allows you to do it, or it says it's not allowed
11:36:48 gra i think it should allow you to do it
11:36:54 larsbot rationale being?
11:37:37 gra it leaves the SAM open to being used in ways that we may think are painful but which for some applications are required
11:37:52 larsbot true
11:38:15 larsbot it also allows you to say that classes A and B have the same extension, but different intensions
11:38:33 larsbot interestingly, RDF allows this...
11:39:04 gra i think its too big an issue for us to remove the possibilty
11:39:19 larsbot yeah, it's also going to be hell for TMAPI implementations to detect this
11:39:46 larsbot note that this has happened already: we got a TM yesterday from someone which froze the Omnigator
11:39:54 gra yep - but they have to detect it anyway to through the exception
11:40:02 larsbot reason: it had such loops, and the recursive function doing the class hierarchy never stopped...
11:40:06 gra or just hanf
11:40:10 gra hang
11:40:14 larsbot like we did :-)
11:40:34 larsbot so we agree that the loops are allowed?
11:40:51 gra i think at this stage we dont say anything
11:40:58 gra we've defined what the relation types are
11:41:04 larsbot agreed (which implicitly means that it's allowed)
11:41:08 gra yes
11:41:18 larsbot goodie
11:41:38 larsbot tmbot: show: psi-type-instance-scope
11:41:42 gra omg!
11:41:50 gra do i not like this issue
11:41:53 larsbot yeah, I don't particularly enjoy this one, either
11:42:16 larsbot what the SAM says now is that scope applies to these two associations "in the same way as it does to any other topic characteristic"
11:42:21 gra the reason i really dont like it is becuase in the SAM types are not shown as associations
11:42:33 gra they are shown with a direct property
11:42:37 larsbot not for topcis
11:42:51 larsbot so this only applies to typing and subtyping of topics
11:42:58 gra sorry yep
11:43:16 gra but i assuem we have to answer the same question for class-instance
11:43:31 larsbot yeah, we have to do it for both, I think
11:43:36 gra no - type instance is not shown as an assoc in sam
11:43:58 gra ok - i'm wrong
11:44:02 larsbot thanks :)
11:44:05 gra i could have sworn it was
11:44:17 gra when did we change that
11:44:35 larsbot we changed it quite early; after the London meeting you and I had, I think
11:44:46 larsbot or maybe it was after Orlando
11:45:06 larsbot anyway: type-instance and supertype-subtype are both associations in the SAM
11:45:06 gra well i cant remember taking it out of the UML so probably was a while back
11:45:28 gra i have bad feelings about this from many directions
11:45:38 larsbot it's still in the UML, actually :-)
11:45:58 gra yep -i was looking at the wrong piccy
11:46:00 larsbot I'll send you feedback on the UML as soon as I can find the time, so let's ignore that now
11:46:08 larsbot bad feelings? why?
11:47:01 gra i feel we try and create a higher level abstraction that is easy to use and conveys some key features of the model
11:47:26 gra and that by hiding this away somewhat we are defeating this aim
11:47:54 larsbot you would prefer a direct property, you mean?
11:47:59 gra its almost as though there are 3 levels, rm, sam verbose and SAM
11:48:32 larsbot I'd say RM, SAM, TMAPI...
11:48:35 gra where the difference between sam and sam verbose is that verbose expands the higher level common structrues into something more basic
11:48:58 larsbot I know the feeling; it's the problem I had with this, too
11:48:59 gra yep, maybe
11:49:24 larsbot I resolved it for myself by saying that this was the only way you could have scope and reification on type relationships
11:49:28 larsbot and there *are* use cases for that
11:49:32 gra but we arent writing the TMAPI here so i think we lose a bit of impact
11:49:42 gra i agree with you
11:49:52 larsbot but I do think TMAPI represents this the right way
11:50:01 larsbot so this is something we'll just have to live with, I guess
11:50:46 gra i guess so
11:50:56 gra as for the issue?
11:51:05 larsbot as for the issue we are no wiser :-)
11:51:08 gra no
11:51:17 larsbot and I have to go play squash...
11:51:25 gra ok
11:51:26 larsbot should we schedule a new IRC meeting instead?
11:51:32 gra continue this afternoon?
11:51:36 gra yep
11:51:51 larsbot I have other meetings for the rest of this week, actually (customers)
11:52:05 larsbot and I'll be travelling sat/sun/mon/tue
11:52:07 gra same time next monday?
11:52:22 larsbot so same time next wed is the best I can do, I guess :-|
11:52:39 gra ok - i'll check and mail you if i cant do that
11:52:45 larsbot excellent
11:52:48 larsbot * larsbot notes in calendar
11:53:07 larsbot ok, then I have to get ready to leave
11:53:27 gra ok - good session i think
11:53:28 larsbot good meeting! I'll try to write up what we've decided so far and send you that
11:53:32 larsbot yep :)
11:53:32 gra ok
11:56:50 larsbot * larsbot has to leave
11:57:04 larsbot xower: I have some questions for you later... :-)
11:57:07 larsbot bye everyone
11:57:11 larsbot larsbot has quit None ("[x]chat")
12:02:08 mariyo gra: i didn't find the tmcl home page in cvs. is it there yet?
12:10:29 gra yep -
12:10:46 gra you need to get latest and ensure that the button 'get new directories' is ticked
12:12:34 gra sory its actually called 'create missing directories that exist in repository'
12:12:54 gra its -d from the cmd line
12:16:43 mariyo ok. i'll try that.
12:17:12 drrho drrho has left #topicmaps ()
12:20:46 mariyo gra: got it thanks!
12:22:14 mariyo that SAM meeting was really great. it's much better to have this written down to look at later on.
12:24:25 mariyo gra: i'll take a look at it now.
12:34:17 mariyo gra: "The constraint language will provide a formal constraint language, related operational semantics and a syntax."
12:34:43 mariyo i would like to change the sentence and remove "default" OK with you?
12:35:08 mariyo in "default syntax"
12:39:57 mariyo gra: i made some small editing corrections and will remove the default in "default syntax." do we need to agree before I commmit? thanks.
12:40:54 mariyo this looks fine and addresses what is being discussed in the sc34 list, which is good :)
14:03:31 LePooh LePooh has joined #topicmaps
14:04:34 LePooh LePooh has left #topicmaps ()
14:14:27 gra yep, please make any changes you feel necessary
14:14:33 gra and commit them
14:18:18 mariyo hi graham!
14:19:01 mariyo thanks. busy working on a paper :)
14:19:43 mariyo if you post it, please mention it on the tmcl-wg list, will you?
14:29:32 larsbot larsbot has joined #topicmaps
14:35:10 mariyo hi larsbot-san, back from your squash now. you must feel great!
14:46:05 larsbot not too bad, thanks :)
14:48:04 mariyo btw, i also seem to have access to the sam area in cvs, i went and got new directories, and well...
14:48:21 larsbot you did. I figured there was no point in blocking your access
14:53:05 mariyo no problem. just need to be careful since i am a little unfamilar with this setup and i'll make a separate module with only tmcl.
14:53:05 mariyo \
14:58:51 larsbot so long as you just work in the TMCL directory all will be fine
14:59:35 mariyo don't need more work that's for sure :)
14:59:53 larsbot exactly :)
15:36:38 mariyo oh, it's getting late.
15:37:17 mariyo bye :)
15:37:38 larsbot good night :)
15:37:47 mariyo * mariyo zzzz
15:59:37 larsbot logger shut down by larsbot
16:01:34 tmbot tmbot has joined #topicmaps
16:02:16 mariyo thanks. boy this is trouble
16:37:29 mariyo ed
17:07:51 SeeTmp SeeTmp has quit None ("Client Exiting")
17:27:20 SeeTemp SeeTemp has joined #topicmaps
17:41:27 gra gra has quit None ()
17:51:55 larsbot larsbot has quit None ("[x]chat")
18:31:30 larsbot larsbot has joined #topicmaps
19:26:10 GabeW GabeW has joined #topicmaps
19:26:44 larsbot hi there, GabeW
19:27:56 GabeW hi there larsbot
19:28:24 GabeW OH btw, whats the meaning of adding "bot" to your first name?
19:28:47 grove_ grove_ has joined #topicmaps
19:29:51 larsbot it's kind of a joke, actually
19:30:10 larsbot we were using IRC in our previous company as well
19:30:20 larsbot and a Polish programmer thought I was typing so fast I couldn't be human
19:30:37 larsbot so he claimed I was a bot, and I sort of started using larsbot instead of larsga
19:31:01 GabeW got it
19:31:08 GabeW i figured humor was involved
19:31:48 larsbot could hardly be meant in earnest :)
19:32:25 GabeW well, could be some bot that gatewayed to your uber-chat/im/email interface
19:33:11 larsbot admittedly it could
19:34:08 GabeW your ubergeek rating would have been elevated quite highly
19:34:30 larsbot I'm sure :)
19:35:24 GabeW hey, i'm going to be sending out some more good framing/motivations text later this week (probably thursday night which would be friday morning your time)
19:36:07 GabeW responding in part to many of your questions (though still not yet addressing the deliverables issue quite yet)
19:36:42 larsbot excellent. that would help a bit
19:37:00 GabeW i've been paying a lot of attention to the (apparently recurring) thread in www-tag about "what URIs identify"
19:37:45 larsbot any thoughts on it?
19:37:51 GabeW yes, many
19:38:15 GabeW some I'm even willing to discuss in a logged irc channel!
19:38:22 GabeW ;-)
19:39:31 GabeW i think generally, I'm sympathetic to the working code argument of the REST folks (something along the line of "we don't have to worry about what a URI identifies - its up to the application"), but I think TimBL's discussions are more persuasive to me
19:40:01 GabeW in other words, there are times when applications "meet" and need to agree on whether they are referring to a web page or the thing represented by the page (for example)
19:40:20 GabeW i think I'd be flamed mercilessly for that summarization
19:40:55 larsbot I think it's right, though
19:41:16 larsbot if they really do want RDF to support internet-scale data interchange...
19:41:50 GabeW bernard vatant posted about TopicMaps (and mentioned the XRI TC)
19:42:21 GabeW he made the excellent point that Topic Maps basically handles this with the publish subject indicator mechanism (ie the way the identifier is being used is explicit)
19:42:45 larsbot yep
19:42:45 GabeW I'm not sure this totally addresses the issue, though -- and besides, topic maps is not the only way URIs are used..
19:43:03 larsbot I think it points the way to the solution: when using a URI you have to be explicit about what you mean
19:43:06 GabeW I'm trying to lay low in this discussion, although I definitely have opinions
19:43:29 GabeW larsbot- you are talking about "context", right?
19:43:41 GabeW the idea that you can't determine what the URI refers to without context
19:43:58 larsbot well, context need not mean much, necessarily
19:44:00 GabeW right
19:44:19 GabeW i know - it can be the surrouding XML element, an XML attribute or whatever
19:44:25 GabeW or the application
19:44:28 GabeW yes I understand that
19:44:35 GabeW is that what you mean?
19:44:39 larsbot something like that, yes
19:44:46 GabeW ok
19:44:48 larsbot I was thinking more about RDF and TMs than XML, though
19:44:53 GabeW right right
19:44:55 GabeW sure
19:45:04 GabeW "
19:45:07 larsbot you could put the distinction TMs have into RDF as well
19:45:13 GabeW "that which has the home page of http://www.w3.org"
19:45:23 larsbot in fact, Sandro Hawke has pretty much proposed a way to do just that
19:45:24 GabeW [:homepage http://www.w3.org]
19:45:28 larsbot yeah
19:46:05 GabeW sorry for polluting topicsmaps with rdf-foo
19:46:36 larsbot no worries
19:46:48 GabeW anyway, so the XRI effort is intending to produce a context-free identifier scheme
19:47:00 GabeW thats an assumption we've uncovered
19:47:01 larsbot because it will always refer to abstract concepts, right?
19:47:13 GabeW larsbot- right
19:47:13 larsbot so there's no ambiguity
19:47:23 GabeW yes, though you could refer to a web page
19:47:33 GabeW "abstractly"
19:47:39 GabeW with an extra step of indirection
19:48:21 larsbot does that mean you're back where you started?
19:48:27 GabeW and note that identifying a computer system abstractly (for example) makes a lot of sense because it allows you to identify a logical thing devoid of network or dns name
19:48:30 GabeW larsbot- hmm?
19:48:35 GabeW "back where you started"?
19:48:41 GabeW i'm not sure we went anywhere...
19:48:47 larsbot does that mean that XRI identifiers will be as ambiguous as http ones?
19:48:50 GabeW uh
19:48:53 GabeW no
19:49:03 GabeW they'll be clearly unambiguous
19:49:22 GabeW because they won't be interpreted relative to a network protocol as http can be
19:49:40 GabeW actually thats a good philosophical point
19:49:44 larsbot but they may still identify electronic resources as opposed to abstract concepts?
19:49:53 larsbot "to *just* abstract ..."
19:50:00 GabeW we need to ground this in concrete definitions
19:50:06 GabeW thats the TAG's problem (definitions)
19:51:01 GabeW i mean to say that an XRI identifier will identify an XML document (lets say) that has data about a conceptual thing
19:51:35 GabeW actually thats wrong already
19:51:35 larsbot that's OK
19:51:36 GabeW sigh
19:51:41 larsbot :-)
19:51:49 GabeW these damn words are sooo overloaded
19:51:52 GabeW "identify"
19:52:46 larsbot there are two words you need, I think: "identify" and "resolve to"
19:52:53 GabeW right
19:52:55 GabeW exactly
19:53:03 GabeW if you have that dichotomy
19:53:37 GabeW then I think an XRI identifies a (modally non-networked) thing, and resolves to a network endpoint through which you can interact with some data about that thing
19:53:45 GabeW does that make sense?
19:54:00 larsbot yes, it does
19:54:03 GabeW phew!
19:54:17 larsbot that means it identifies a conceptual thing, but it resolves to data about it
19:54:20 GabeW its a subset of the semantics of todays web, but made less ambiguous
19:54:21 GabeW yes!
19:54:30 larsbot so it's almost like a subject identifier, but the data need not be human-readable
19:54:35 GabeW woot!
19:54:37 larsbot uh, published subject
19:54:47 larsbot the data that comes back is not for humans, but for machines
19:54:48 GabeW i think thats right
19:55:19 GabeW actually, it could be for humans, but that would be a special case
19:55:46 GabeW does this surprise you at all?
19:55:50 larsbot no, not really
19:56:01 larsbot it's pretty much in line with what you said before
19:56:02 GabeW does this make sense to be doing?
19:56:16 GabeW i haven't had to think about the XRI effort in these terms before
19:56:27 larsbot I think so, though I am uncertain why you want it to resolve to machine-readable data
19:56:32 GabeW ah
19:56:49 larsbot sounds as if having a million XRI identifiers entails a million http requests...
19:56:54 GabeW because we have all sorts of applications for doing things like sharing data (ie personal data)
19:57:20 GabeW this is probably where the w3c people and you guys have least visibility into what we are doing
19:57:46 larsbot I expect so
19:57:59 larsbot the XRI bit appears reasonably clear, but the next level is pretty much opaque
19:58:06 GabeW ok
19:58:10 GabeW thats actually not surprising
19:58:21 GabeW its not opaque to us because we have the model of XNS
19:58:33 GabeW (which will probably be refactored quite a bit)
19:58:48 GabeW thats not to say we are going to produce something that looks just like XNS
19:59:17 GabeW its just that XNS embeds a lot of the assumptions and architecture we have implicit in our heads moving forward
19:59:42 larsbot that's the stuff that needs to go into the reqs doc, I think
20:00:07 GabeW it will
20:00:26 GabeW i was hoping that we wouldn't have to go there for the requirements document
20:00:35 GabeW i mean for the requirements for the addressing stuff
20:00:47 GabeW but its clear people are totally lost as to why we are doing what we are doing
20:00:52 GabeW so there'll be something in there
20:00:57 larsbot I think so
20:01:13 GabeW we've greatly expanded the scope of our audience
20:03:30 GabeW there's been some tension having to "back up" and explain the bigger picture to folks against trying to move forward with the formalities and such of the TC
20:04:10 larsbot well, formalities and bigger picture should be largely orthogonal, no?
20:04:50 GabeW yes
20:04:53 GabeW but time is finite ;-)
20:05:11 GabeW and really, its an education for us
20:05:18 GabeW understanding where our blind spots are
20:05:28 larsbot I can imagine; that's always hard
20:05:42 GabeW several of us have been looking at (or in some cases, working on) XNS for years
20:05:58 GabeW so to step back and explain the line of thinking to a wider audience is challenging
20:06:16 GabeW especially when everyone is convinced that you can't possibly have anything to contribute
20:06:24 larsbot :-)
20:06:34 GabeW really, for me, thats the challenge
20:07:00 GabeW understanding other folks' assumptions and POV's so as not to set them off (which we've already done of course in several instances)
20:07:27 GabeW I think positioning XRI as the "context-free" URI scheme for identifying "concepts" only might be a good way to go
20:07:48 GabeW and then showing why we need this (higher layers)
20:08:26 larsbot if you could do that convincingly that would definitely help you
20:08:37 larsbot if it were aligned with published subjects as well that would also help
20:08:51 GabeW well, today's conversation, and keeping up on those TAG threads is helping a lot
20:09:03 larsbot if people can use XRI without using XNS they are likely to be more positive
20:09:06 larsbot good :)
20:09:10 GabeW yes, convergence with your conception (if only in the sense of being able to describe the simnilatiries and differences) would be very helpful
20:09:18 GabeW OH!
20:09:26 GabeW yes, I suspect that XNS will go away as a separate spec
20:09:32 larsbot what does that mean?
20:09:44 GabeW well, I think if anything, XNS will be a layer on top of XRI stuff
20:09:55 GabeW right now XNS is its own 7 layer cake ;-)
20:10:10 larsbot ah, right. "go away" was difficult to parse
20:10:15 GabeW yeah, that was ambiguous
20:10:22 GabeW the short answer: I don't know yet
20:11:22 larsbot well, that's at least clear :)
20:11:54 GabeW i don't know how much consensus there is on that - its partly outside the XRI TC scope..
20:12:52 larsbot the partly causes a lot of grief, I expect
20:13:35 GabeW well, I think there's consensus that some things are out of scope of the XRI TC
20:14:24 GabeW and we just haven't really gotten to talking about what else (beyond XRI TC) is going to be worked on in whatever timeframe
20:14:47 GabeW its not so much about disagreement as much as it is putting off stuff for now that we wouldn't get to even if we wanted to right now
20:16:04 larsbot yeah, but I guess it makes it a bit more difficult to discuss XRI
20:16:07 larsbot as we just discussed
20:16:16 larsbot tmbot: url: http://www.isotopicmaps.org/tmcl/
20:16:20 larsbot tmbot: title: TMCL
20:16:32 larsbot tmbot: comment: The TMCL work now has a home page of its own.
20:16:41 larsbot sorry about that :)
20:17:29 GabeW no problem!
20:18:02 GabeW actually, we have enough of what XNS was in scope to have a completely useful deliverable that provides significant value - its not that we're just providing a useless spec that has no value in isolation
20:18:21 GabeW actually, we have enough of "what XNS was" in scope to have a completely useful deliverable that provides significant value - its not that we're just providing a useless spec that has no value in isolation
20:18:41 GabeW so I think we can usefully talk about higher level uses of the XRI URI scheme in the requirements
20:18:55 GabeW in fact we have -- we just don't have explicit use cases to tie things together
20:20:06 larsbot I agree XRI is a complete technology in itself, with its own merits
20:20:35 GabeW my phone call hasn't rung yet
20:22:00 larsbot not sure whether that's good or bad :)
20:22:51 GabeW me neither
20:33:54 GabeW ttyl
20:34:03 larsbot yup :)
22:00:25 GabeW long call
23:59:17 mariyo mariyo has quit None ("time to call it a night. bye everyone and see you tomorrow!")