15:01:39 RRSAgent has joined #rdfcore 15:01:48 em has changed the topic to: rdfcore 2003-03-14 teleconference 15:01:53 zakim, this is rdf 15:01:53 ok, em 15:01:57 zakim, who is here? 15:01:57 On the phone I see ??P2, PatH, Manola, EMiller, ??P10 15:01:58 On IRC I see RRSAgent, Zakim, DaveB, em, gk, bwm, AaronSw, logger 15:02:08 Zakim, ??P10 is probably ILRT 15:02:08 +ILRT?; got it 15:02:11 +GrahamKlyne 15:02:13 Zakim, ILRT has daveb, jang 15:02:13 +daveb, jang; got it 15:02:29 zakim, ??P2 is bwm 15:02:29 +bwm; got it 15:03:33 zakim, who is on the phone? 15:03:33 On the phone I see bwm, PatH, Manola, EMiller, ILRT?, GrahamKlyne 15:03:34 ILRT has daveb, jang 15:03:35 +Mike_Dean 15:03:48 mdean has joined #rdfcore 15:04:36 meeting starts 15:04:41 +EricP 15:04:44 Zakim, who's on the phone 15:04:44 I don't understand 'who's on the phone', DaveB 15:04:44 danbri has joined #rdfcore 15:04:56 zakim, EricP is temporarily DanBri 15:04:56 +DanBri; got it 15:05:04 Zakim, who is on the phone? 15:05:04 On the phone I see bwm, PatH, Manola, EMiller, ILRT?, GrahamKlyne, Mike_Dean, DanBri 15:05:07 ILRT has daveb, jang 15:05:12 roll call above correct 15:05:13 agenda 15:05:15 jang_scribe has joined #rdfcore 15:05:16 no aob 15:05:19 scribing 15:05:32 tuesday telecon, at risk 15:05:37 bwm can't make it 15:05:47 gk can't make it 15:05:49 turnout for this week's wasn'ty that great; pat can't make it next week 15:06:31 em: bwm is a mission-critical resource for this 15:06:47 next tuesday's telecon is cancelled; next telecon this time, next week 15:06:51 two hours ok for everyone? 15:07:02 (gk can't make it, travelling) 15:07:15 em: jjc making it next week? 15:07:41 bwm: ok, 120 minutes next friday 15:07:45 volunteer to scribe? 15:07:47 daveb steps up 15:08:15 moving on, minutes of last friday's telecon... 15:08:20 [pointer anyone?] 15:08:24 approved 15:08:33 [ 15:08:33 5: Minutes of 28 Feb 2003 telecon 15:08:33 See: 15:08:33 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0053.html 15:08:34 ] 15:08:40 [ 15:08:40 6: Minutes of 11 Mar 2003 telecon 15:08:40 See: 15:08:40 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0068.html 15:08:42 ] 15:08:42 minutes of tuesday's telecon? 15:09:02 also approved 15:09:06 completed actions:" 15:09:11 long list, anyone unhappy? 15:09:22 confirmed 15:09:35 item 8: daveb, xml schema 1.1 requirements 15:10:06 daveb responded immediately, that's done; 15:10:34 the second action continues; hopefully jjc can pick up daveb's comments and add his concerns 15:10:45 uris for as many datatypes as they can 15:10:50 raising the priority for this 15:10:54 webont also keen for this 15:11:17 DaveB: leave this until next week; hopefully we'll have comments by then 15:11:28 if comments complete by middle of next week we should send it then.\ 15:12:16 bwm: I'll reraise this next week, if people are keen please look at this asap 15:12:39 item 9: handling lc comments 15:13:02 http://www.w3.org/2001/sw/RDFCore/#microschedule 15:13:10 danbri: I've about a dozen left to deal with 15:13:26 expect reasonable progress by next week 15:14:45 bwm: can anyone pitch in to help danbri with this? 15:15:20 danbri:there are things where people talk about schema but there's a large semantics overlap 15:15:32 path: talk to me via email about it, I can help there 15:16:40 jang_scribe: give me a yell monday, we'll divvy the work up 15:16:57 bwm: what about other docs, are we up to date on these? 15:17:03 zakim, mute danbri 15:17:03 DanBri should now be muted 15:17:10 that is, has every comment been handled as editorial discretion or in the issues list? 15:17:21 frankm: there's one against the primer raised by eric p 15:17:33 we talked at the plenary about it, not heard officially about this yes 15:17:39 my intent is to handle it editorially 15:17:49 bwm: other docs? 15:18:05 gk: (looks at todo list...) 15:18:35 gk: I've a couple in limbo, should be ok I think 15:18:43 bwm: daveb: spotted chaals' messages? 15:18:56 saying what happened to aboutEach, aboutEachPrefix? 15:19:20 DaveB: just noticed reagle's "wrapping xml literal" too 15:19:27 I'm up to date I think 15:19:51 ACTION jang: take another trawl through -comments for dripped issues 15:20:09 gk: comments from susan lesch on concepts... 15:20:16 chaals's msg, for syntax, yet todo http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0501.html 15:20:19 I was assuming those are editorial, I'm kind of uncertain 15:20:37 bwm: if editorial, deal with them as editorial 15:20:41 reagle on rdf-wrapper, not responded (concepts?) http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0434.html 15:20:51 em: that's susan's job: she's the w3c's style guide. 15:21:45 action bwm: series editor to review susan's comments for cross-document consistence 15:22:10 gk: I've another... comments from eric P about canonicalisation, no record of it being tied in with anything else 15:22:28 it's still sitting needing a process ID or something 15:22:55 Eric P comment: http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0240.html 15:24:10 ACTION bwm (pp gk, jjc) chase eric P's message, get a process resolution for it 15:24:24 any other incoming lccs? 15:24:27 gk: another one... 15:24:41 aaron commented on the use of 404 not found http responses... 15:24:51 ... hang on, I think this fits in with the other social issue stuff 15:25:00 path: yes, think we've dealt with that. 15:25:10 bwm: please ensure aaron gets a response for this. 15:25:13 AaronSw? 15:25:15 AaronSw: still here? 15:25:28 Aaron, is this response OK: http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0412.html 15:26:01 action: gk, please chase aaron's message ensure he's ok with response 15:26:09 bwm: any other incoming comments? 15:26:12 DanC has joined #rdfcore 15:26:15 then moving on to item 10... 15:26:31 pfps issues 17, 18, 19, 20, 21, 10043, 23819329 15:26:43 acked danc\ 15:27:17 pfps was happy with frankm's response on this, said it'd work for the other docs too 15:27:43 proposal from agenda outlined by bwm... 15:27:49 objections? comments? 15:27:51 approved. 15:28:03 next, item 11. macgregor-01, macgregor-02 15:28:13 comments on section 4 of concepts, which has gone, I think 15:28:22 gk: possibly a residual issue with -01 here... 15:28:34 it asks how statements may or may not be asserted 15:28:49 I responded early on this and pfps came back and asked if that addressed all the issues. 15:29:16 macgregor msg: http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0453.html 15:30:58 bwm: did we refer anywhere to distinguishing between asserted and nonasserted forms? 15:31:19 path: it'd be in the spirit of the social meaning discussion/resolution to purge these comments too 15:31:43 gk: ok, I've raised the point against that. 15:31:51 bwm: @asserted@ only appears in section 4 of concepts 15:32:52 gk: do we close this or hang onto it unless it pops up again? 15:33:02 bwm: I'm ok with jjc's proposal to close... 15:33:49 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0040.html 15:34:10 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0040.html 15:34:16 DaveB: grepped in wds for assertion, a few times in lbase, concepts, primer, often in semantics (obviously) 15:35:09 gk: ok with jjc's proposal 15:35:20 DaveB: not hesitating, just saying there's action required. 15:35:36 proposal: to close this, with actions on editors to review for use of the term @asserted@ in light of these comments 15:35:39 any comments...? 15:35:50 [excuse @, american keyboard] 15:36:01 ok, proposed... any dissent? 15:36:12 this is wrt macgregor-01 and macgregor-02... 15:36:44 frankm: strictly speaking macgregor-02 references concepts, he agrees with my proposal to deal with this in the primer 15:37:10 back t the proposal to close: 15:37:24 no dissent, no abstentions? 15:37:29 resolved, actions arising: 15:37:56 action gk: respond wrt macgregor-01, macgregor-02 15:38:10 action: all editors, check for use of term @asserted@ and modify in the light of this comment 15:38:37 frankm: gk should include in his response the information that the other documents are being checked too 15:38:40 moving on... 15:38:52 item 12, reagle-01, reagle-02, skipping in the absence of jjc...? 15:39:02 item 13, williams-01 15:39:09 gk's proposal: 15:39:19 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0059.html 15:41:08 gk: I've put a sketch of words in proposal given, 15:41:23 main proposal is that this is addressed by the terminological approach suggested by pat 15:42:12 DaveB: this issue is @what is a node in an rdf graph?@ 15:42:59 bwm: recently decided that an rdf graph IS a set of triples, etc. 15:43:09 some of the text still refers to nodes in a graph 15:43:17 this is asking about that use of terminology 15:43:31 gk's response here is sensible, referring to danc-01 15:43:53 this is an editorial cleanup which we'll use consistently throughout. 15:43:58 proposal, then: 15:44:09 [[ 15:44:10 I propose that this issue is addressed by following the terminological 15:44:10 approach suggested by Pat in another message: 15:44:10 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Feb/0152.html 15:44:11 ]] 15:44:41 davceb: isn't that already in concepts? 15:44:56 is the response not, @yes this is the case, see these sections of concepts@ 15:45:34 DaveB: I'd like to see, @I'm going to fix these sections of concepts@ if what's there already isn't exactly what we're going to finish with 15:45:58 DaveB: this should be in concepts; if concepts is currently wrong then I'd like to see the fixed words in the proposal 15:46:24 gk: proposal is that we make editorial changes in line with pat's suggestion 15:46:48 DaveB: ONE document should give the definition, everything else points to that 15:47:07 if you need to explain more in an email then the email contents belong in concepts 15:48:36 DaveB: so your answer is, @yes, an rdf graph is a set of triples, see concepts section X@ 15:49:08 concepts doesn't mention nodes in a graph; (gk: section 6 does) 15:49:16 or parts of a triple 15:49:51 frankm: primer starts off with graphs that are pictures. 15:50:11 path: that's fine. we can say, this is a picture of an rdf graph, and the pictures have nodes in them 15:50:56 bwm: 3.2 in concepts looks a bit iffy, that's the one stuart was complaining about 15:51:53 bwm: the subject of a triple is a uri (or a bnode): that's the terminology we decided to use 15:52:04 s/uri/uriref 15:52:54 path: somewhere prominently we have a section that gives definitions, we can say, we use the term @node@ to apply to subjects and objects, this is a terminological convenience 15:53:48 DaveB: it's handy to have a general term instead of saying, @uriref or literal or typed literal or...@ 15:54:12 path: if we have a shorthand terminology it belongs in concepts with the rest of these definitions 15:54:29 DaveB: reads 6.2 @the nodes in an rdf graph consists of...@ 15:54:54 path: could add a note to the effect that the node IS the uriref 15:55:43 stuarts wording suggested @labelled with@ which has been excised 15:56:17 bwm: don't think this response is cooked 15:56:31 gk: agree, need to go round again and come back with a firmer proposal 15:56:41 agreed, moving on. 15:56:50 item 14: pfps-03 15:57:08 path: oh, that's trivial, I've taken it on as editorial 15:57:28 the lbase translations weren't accurate, he's right, but I'm putting this off until the semantics settles down 15:57:52 my comment to pfps was @this will be fixed once the rest ofthe document has been signed off@ 15:58:15 bwm: I think we need to leave it open until it's fixed, then 15:58:19 path: fine, ok. 15:58:30 item 15:L pfps-04, -05, -06, -07, -10 15:58:46 path: all of those are genuine bugs pfps found which have been corrected in the editor's draft 15:59:12 proposal: accept these comments, close the issues, refer pfps to the updated editor's draft. 15:59:32 bwm: we need someone to review these changes? 16:00:22 path: the issue is if these changes have any unexpected side-effects 16:00:37 bwm: gk, can you review these? 16:00:55 gk: yes, providing the action's clear what it is I have to review and it's not required by next week 16:01:26 pat's draft http://www.coginst.uwf.edu/~phayes/RDF_Semantics_Editors.html 16:01:33 jang_scribe: I'll do it too... 16:02:21 path: there's a chunk of missing machinery dealing with lang tags on dted literals 16:02:30 action: gk - review path's changes to semantics 16:02:38 action jang: review path's changes to semantics 16:03:02 (changes... arising out of pfps 05 06 07 10) 16:03:07 (and 04) 16:03:14 ^^^ amend action text 16:03:27 moving on, 16:03:34 item 16: pfps-08 16:03:59 path; that belongs with the others, another tweak 16:04:08 ^^^ action add pfps-08 16:04:48 path's dealing with pfps-08 was about xmlliteral 16:05:22 xmlliteral is a bit odd, an owl reasoner could decide eg:x === xmlliteral 16:05:37 then should a dt typed with eg:x behave like it was typed with xmlliteral? 16:05:41 the answer is, no. 16:05:47 pfps thinks that's a mistake, I disagree. 16:06:11 that's the outcome of that issue; the mt has no alterations to make it work like pfps thinks it should in this respect 16:06:18 the text has been changed to clarify this 16:06:50 outcome: owl has to treat xmlliteral as a special case. 16:07:22 bwm: so, then what is the closing resolution? 16:07:47 path: the behaviour described is not an error. the document has been clarified in this respect 16:08:13 so the comment is NOT accepted in spirit 16:08:43 Propose: RDFCore do not accept this comment. The semantics are as intended. The text has been clarified to make this clearer. 16:08:44 [bwm types proposal] 16:09:19 path proposes, daveb seconds, dissent? no abstentions? no 16:09:21 resolved 16:09:26 (just like the UN!) 16:10:00 action: bwm - update issue list to opint to path's response to peter onthis 16:10:04 moving on 16:10:11 item 17, qu-01, path...? 16:10:33 should the domain of rdfs:member be rdfs:Container? 16:10:54 the rdfcore decided otherwise. 16:11:28 danc commented, incidentally, that there should be an rdf:member between collections and their member 16:12:03 path: he thought we'd forgotten to say it, we respond, thanks, but nope. 16:12:59 frankm: worthwhile pointing out explicitly somewhere that one of these properties used in a triple somewhere does NOT imply that the subject is a container? 16:13:42 proposal: the use of a container membership property or rdfs:member in a triple should not be taken as a claim that the subject of the triple is a container. 16:13:58 (so this comment is rejected) 16:14:10 proposer: frankm; seconder: gk. 16:14:16 dissent? nope. abstains? nope 16:14:21 so resolved. 16:14:32 path: is there a recorded decision from earlier? 16:14:41 bwm: the term @decided@ in the agenda might have been too strong 16:14:54 [is there an xmodmap for osx?] 16:15:07 actions: path to respond; nothing else need doing 16:15:10 moving on. 16:15:17 item 18, qu-02 16:15:27 rdfs:member a functional property? 16:15:45 rdf doesn't have a functional property. This is in owl's domain. 16:15:49 ^^^ path 16:15:54 zakim, unmute danbri 16:15:55 DanBri should no longer be muted 16:16:16 danbri: there are lots of things we can't effect formally we can express in prose 16:16:59 any other opinions on this, should rdfs:member BE functional? 16:17:14 not member, rdf:_1, etc 16:18:34 frankm: this situation is akin to what we've said about collection 16:18:54 if you use parsetype collection, you get this neat form; if you write it by hand you can make other odd datastructures 16:19:07 frankm: how are you going to check it? 16:19:21 gk: I broadly agree with path; there's a way this is visible with rdf entailment 16:19:32 [[To represent a collection c, create a triple {RDF:type, c, t} where t is one of the three collection types RDF:Seq, RDF:Bag, or RDF:Alt. The remaining triples {RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ... point to each of the members rn of the collection. For a single collection resource there may be at most one triple whose predicate is any given element of Ord and the elements of Ord must be used in sequence starting with RDF:_1. For resources 16:19:33 that are instances of the RDF:Alt collection type, there must be exactly one triple whose predicate is RDF:_1 and that is the default value for the Alternatives resource (that is, there must always be at least one alternative).]] 16:19:47 this is the thing daml tries to express, so we should try to avoid addressing it. 16:19:57 path: so again, we say, thanks bu tno thanks. 16:20:53 path: we've abandoned all such syntactic constraints on graphs, right? 16:21:15 rdf:Alt is useless clutter imho 16:21:37 path: this currently isn't broken 16:22:18 so path proposaes, gk seconds... anyone against? 16:22:33 propose then, not to accept qu-02. 16:22:34 reason: 16:22:57 - it's not necessary; - it might damage behaviour of existing code (mozilla) 16:23:31 proposer: path; seconded: gk. 16:23:39 against? none. abstain? none 16:23:41 resolved. 16:23:46 actions: path to respond to qu 16:23:53 ...wrt qu-02 16:23:59 moving on 16:24:05 item 19, xmlsch-08 16:24:14 DaveB: has a proposal 16:24:38 http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0077.html 16:24:47 DaveB: why not use xsi:type? 16:25:24 DaveB: we chose not to for these reasons... 16:25:28 they express concern 16:25:42 we chose not to use xsi:type because THAT would be confusing, it's an overloading of the semantics 16:26:04 eg, there's a difference between uri(refs) and qnames 16:26:52 we accept that there are good reasons; here are a couple more 16:27:15 bwm: ... and if they've any other suggestions we'd be glad to hear them 16:27:29 +1 16:28:16 em: these guys are really trying hard to work with us, we need to be as appreciative as possible 16:28:27 general consent from path, admiration of their efforts 16:28:49 gk: is it _legal_ to have a literal with an xsi:type in an rdf graph? 16:29:10 DaveB: and xml literal? if it's properly declared, there's no restriction if it's properly declared 16:30:41 questions on the syntactic legality of xsi:types at various points in rdf/xml syntax 16:31:01 DaveB: you couldn't accidentally use it, I'll consider adding that to the response 16:31:18 but listing bad examples in our dopuments, I think, isn't the route to go down 16:31:46 DaveB: so, show why we don't use xsi:type 16:31:53 give an example 16:32:21 we chose not to use xsi:type because THAT would be confusing, it's an overloading of the semantics 16:32:21 eg, there's a difference between uri(refs) and qnames 16:32:29 ^^^ daveb's suggested resolution 16:32:44 gk: I'm not unhappy; I'm still trying to think if xsoi;type might appear in rdf/xml 16:32:54 DaveB: you can't use it that way in rdf/xml 16:34:59 bwm: do we need towait for gk to think on this more? he's got a niggle about pathological examples 16:35:28 gk: don't think it affects the outcome, i'll try to get an example gk's after 16:35:37 bwm: I think we can decide this now. 16:36:09 proposal: we accept the comment, but in responding, daveb points out the reasons why xsi:type can't be used (their reasons, plus at least one more) 16:36:33 also point at the explanation, give an example of how if someone uses xsi:type by mistake, an rdf/xml parser would pick up the error 16:36:40 DaveB: propose; gk: seconds 16:36:45 against? 0-. abstains? 0 16:36:48 done, resolved. 16:37:23 DaveB: suggeswt jumping to horrocks-01 16:37:29 item 24, horrocks-01 16:37:53 ian wants to add genuine comments to an ontology 16:38:06 that is, you add it it doesn't affect the logical entailment in any way whatsoever 16:38:16 so changing the comment in rdf changes the entailments 16:38:41 the compromise position we arrived at was, 16:38:57 if we @trivialise@ the comments by being true in every entailment 16:39:04 then inference engines can ignore them 16:39:13 so we add that as a semantic condition on rdfs:comment 16:39:29 bwm: example, maybe, of a harmful entailment? 16:39:44 path: changging a comment changes the formal entailment. 16:40:21 jang_scribe: eg, spellchecking comments will break entailed conclusions 16:40:40 An example from Pat's message: 16:40:42 path: one option suggested was, why not just get your checker to ignore comments? 16:40:43 [[ 16:40:46 eg by 16:40:46 virtue of there only being three comments in the graph, a cardinality 16:40:46 constraint applying to a superproperty of rdf:comment and an 16:40:46 assertion that rdf:comment was functional could produce an 16:40:46 inconsistency 16:40:48 ]] 16:40:53 the response was, if we ignore it, it should be ignored in the semantics 16:41:56 gk: if I read the comment you made in your message to the group (quoted above) 16:41:59 zakim, q+ to recall RDFS WG design 16:41:59 I see danbri on the speaker queue 16:42:33 path: it's true that owl can give propositions more complex and wide-ranging effects than it has in rdf 16:43:09 in principle, you could set up an owl definition that becomes inconsistent by virtue of not havoing enough comments in it! 16:43:19 q 16:43:21 q? 16:43:30 q+ to ask if the problem is with rdfs:commetn per se, or that lack of a property immune to these effects 16:43:55 lol 16:44:03 +1 16:44:28 bwm: this might hurt in owl, @well, don't do that then@ 16:44:48 there amy be subproperties of comment, for instance 16:44:51 ^^^ path 16:45:00 ian's worry is that such tricks might bite people in unexpected ways 16:45:16 danbri: 16:45:21 ack danbri 16:45:22 danbri, you wanted to recall RDFS WG design 16:45:24 zakim, ack danbri 16:45:24 I see gk on the speaker queue 16:45:35 ack danbri 16:46:05 the rdf schema design discussions ... 16:46:29 ... we anticipated things that came along with @real@ semantics like domain range, and @empty@ things, ie, more like comment 16:47:10 one of the comments I've yet to respond to was a request for better commenting machinery 16:47:25 path: the natural response might be, 16:47:42 we know this should be replaced in the future, and this is what we've currently got 16:48:14 owl has a class of annotation properties 16:48:24 danbri: my next proposal was that owl did that, not us 16:48:29 so, great. 16:48:30 q? 16:49:14 gk: is Ian's problem with the existence of rdfs:comment or the lack of a @real@ commenting mechanism? 16:49:23 path: both. he needs a commenting mechanism, but this is too loose. 16:49:40 em, sure 16:49:43 thanks 16:49:43 owl could do that for itself if it wanted to 16:49:48 q+ 16:50:04 q+ to ask whether their problem extends to any unknown properties appearing in a vocab/schema 16:50:09 gk: owl could define for itself an owl:comment with the constraint that A owl:comment b is always true? 16:50:19 ack gk 16:50:19 gk, you wanted to ask if the problem is with rdfs:commetn per se, or that lack of a property immune to these effects 16:50:22 path: yes, or it could apply additional constraints of the same ilk on rdfs:comment 16:50:25 ack em 16:50:46 em: there's already a lot of confusion about when to use what. owl:Class, rdfs:Class\ 16:50:59 there's a communication aspect that needs fl[ue]shing out here 16:51:16 I like danbri's suggestion about owl addition additional information to these particular properties\ 16:51:26 but the reduplication of these things as a slight means of constraining it 16:51:39 when trying to go out and explain this to folks seems as a problme 16:51:42 q? 16:51:55 path: I don't see that we'll always be available to avoid two versions of some things, it's inevitable 16:51:59 ack danbri 16:51:59 danbri, you wanted to ask whether their problem extends to any unknown properties appearing in a vocab/schema 16:52:08 -EMiller 16:52:10 em: in that case we should be super-cautious when playing that card 16:53:01 path: what bothers ian is that something CALLEd comment with the INTENDED PURPOSE of attaching comments should have real semantic import\ 16:53:17 danbri: so is this just a philosophical clash? 16:53:39 path: ian's made a genuine engineering comment, that teams of people collaborating over time 16:53:49 on an ontology, will NEED (absolutely) comments 16:53:57 they're critical for the management of a large effort like that 16:54:14 just like you need them in software engineering 16:54:29 without those comments getting in the way of formal machinery you're using to check the real axioms 16:54:52 it's be a mistake to dismiss this use case, since we expect that people WILL use rdf and DAML and OWL to create large-scale ontologies 16:55:11 bwm: firstly, I'm really not sure what the problem is... 16:55:22 secondly, when I think about writing comments in the small ontologies I deal with, 16:55:35 I think of them not necessarily as comments to the user of a schema, but as showing up in a UI 16:55:41 in ontology tools 16:55:53 path: that's jimh's point of view, that's why he wants them to be retained 16:56:04 to be fair to ian, we don't provide what ian needs 16:56:17 frankm: 16:56:29 pat, did you see my response on wednesday? 16:56:33 it seems to me that 16:56:40 9a) this is much like the class/instance distinction 16:56:40 I think we should seriously consider an rdfs:noop or rdfs:triviallyTrue property, ala Jeremy's c14n/signature stuff. 16:57:07 why are we precluding people from doing tricks/useful things from comments at the rdf level 16:57:16 as opposed to people building it in in a specialised language 16:57:17 and 16:57:19 From RDFS WG archives (with Guha's permission): 16:57:20 [[ 16:57:21 but to trivialize rdfs:comment is no fair, at this stage of deployment. 16:57:21 Message-ID: <35673B2B.5FCE@netscape.com> 16:57:21 Date: Sat, 23 May 1998 14:10:03 -0700 16:57:21 From: guha@netscape.com (Ramanathan Guha) 16:57:21 To: singer@almaden.ibm.com 16:57:22 CC: w3c-rdf-schema-wg@w3.org 16:57:24 Subject: Re: Open Issue #18 16:57:26 Here is one factor to consider before we decide 16:57:28 to postpone this --- pretty much everyone who 16:57:30 uses RDF Schemas will come up with some property 16:57:32 type to hold a human readable description. This 16:57:34 is just going to happen. Wouldn't it be better 16:57:36 if everyone used the same property type (even 16:57:38 if it were not 100% perfect?) 16:57:40 Guha 16:57:43 ]] 16:57:44 (sorry to interrupt Jang) 16:57:46 --http://lists.w3.org/Archives/Member/w3c-rdf-schema-wg/1998AprJun/0211.html 16:57:46 (b) we need facilities for people building large ontologies; is rdfs:comment used for that? 16:57:57 miked: rdfs:comment is used usually as a description 16:58:14 frankm: right, a software engineering discipling would need structured kinds of comments 16:58:22 dabnbri: guha's comment... 16:58:34 yes, 'comment' was poorly chosen. but the community groks it (and uses it) as designed, i.e. as description. No fair to change it now. 16:59:05 we built something useful to a lot of people, we need to stand by that 16:59:13 DanC, we're out of time. Please send by email. 16:59:17 path: this isn't getting a very sympathetic hearing. 16:59:56 path: the only option is to say @sorry@ or to do the formal trick I mentioned in the email 17:00:00 roger, danbri. 17:00:06 which means that an empty graph entails every single comment 17:00:43 gk: in proposing to reject it we must'nt be seen as being totally dismissinve of the concerns expressed here 17:00:53 path: yes, I'd come back to the gropu with words for this 17:01:07 bwm: danbri, do you have wording on this? 17:01:25 danbri, are you really out of time, it seems the discussion continues. 17:01:37 postponed until next week 17:01:42 bwm: we'll wordsmith offline 17:01:49 ah. ok. 17:02:07 action: path - produce the words of the decision for this 17:02:15 closed 17:02:17 NEXT MEETING friday! 17:02:19 rrsagent, pointer? 17:02:19 See http://www.w3.org/2003/03/14-rdfcore-irc#T17-02-19 17:02:35 -PatH 17:02:37 -Manola 17:02:39 -DanBri 17:02:40 -ILRT? 17:02:44 -Mike_Dean 17:02:57 -bwm 17:03:01 -GrahamKlyne 17:03:03 SW_RDFCore()10:00AM has ended 17:03:32 http://www.w3.org/2003/03/14-rdfcore-irc.html etc should be public soon. I changed it, waiting for ACLs to mirror. 17:05:37 http://www.w3.org/2003/03/14-rdfcore-irc.html public now. 17:05:39 danbri has left #rdfcore