Meeting notes: 3 06 2001 Attendants: Mike Jeff Ian Pat Frank Peter Jim MIA: Ora Deb Lynn Tim Dan B Dan C Stephan Dieter Announcements: Dan C. Presenting today at knowledge techologies conference Frank WWW10 request for someone from Semantic Web Initiative at W3C ... Tim potentially said yes ... (via Jim) Ralph .. will do if Tim won't Will try to push it farther. Last weeks minutes ... no changes ... considered approved. Current status of DAML+OIL release Did the CVS access work ... Ian said yes outstanding questions from Jeff need to be answered? big things: is the unambiguous be considered a property, or just abstract property? Peter: umambig. is really a short hand for whatever the appropriate thing is on the inverse relationship (functional) on the range. We dont handle data type relationships for inverse properties. Jim: instinctive problem. A question like this comes up. Two best experts in the world think hard and come up with a work around .... we need to either make it easier, or make it clear why things need to be that way. Ian: need to revamp the walkthrough and example Peter: most people will read either the walkthrough or the ref document. These both need to say what is different from the last example, and that this is the best we can do so far ... Have to be careful that we don't forget to explain the thinking behind what we're doing. Jim: Our discussion and decision making is important because the RDFCore group will need our inputs or else will end up having to rederive what we did. or will come to different decisions Jim: Someone should be involved in the RDF Core group ... Dan B has specifically requested that. We dont want to have to treat data type values as if they are abstract values. This is the same thing as with literal values. Mike: this may be more a function of the clase / property pair, not just the property. We don't want to have to reify the number 2 into a structure that has all this extra stuff Jeff: why would we have to do that if we allowed it to be an unambig. type Concrete types aren't really there as the contents of Abstract types are ... ***Data type values aren't really there in the way that abstract objects are. You can't get your hand on everything about a number, like you can for objects, you can just point to them. If you want to do more than point at them, you need to turn them into abstract objects. Ian: (??) Bad comment ... unambiguous types ... DAML+OIL.daml Unambig. seems to be becoming much less useful. Seemed to be agreements (one or two way at least). Compliment our "best practices" with a "worst practices" (and work arounds?) ... can't put names with them :) DAML FAQ is a good place to put information like worst practices ... Jeff again: in the walkthrough... needs to be updated ... note about using xml schema datatype(?) ... Jeff: can all data types be thought of as a sub class of literal? There is a many to many mapping between data types and literals When you have in literal, keep it that way until you get a type, you map the thing it can be from the literal, and the thing it can be by the type, and intersect the two (bad wording ...) Jeff: If somoene makes a range a literal. Would you be able to use the XSD syntax to say that this literal is supposed to be a float or integer. Ian: If you can do that, I suggest we change it so you can't. :) Seems that you can do that, and it's ok. Its like saying this has a data type range, and I am not sure what one just yet. Mike: Oh, there is no longer a need to tag the values. Ian: This is why we need to extend the examples. Peter: Good Idea to tag the values ... Perhaps the taking a literal and tagging it be a good example? Or Shoe size? Mike: can someone summarize the changes made to make it so you didn't have to tag everything. Jeff: A method for asserting equality and inequality. Equivalent to could be used to equality ... but that doesn't help wiht ineq. Ian: Suggest we not use equivalent to for equality and inequality ... Peter: What do we call it then? Can't use same as ... maybe equal .. but that can be dangerous. Maybe same individual and different individual. The facilities are there, but not a convenient way to do it. So we are talking here about syntactic sugar. What are the problems of different from? We can already to it... so what are the problems with doing it? By making it easy, you are encouraging it What's wrong with encouraging it? Nothing? You have been warned... Jim: if there's a clean way to do this, I have no problem doing this. Warnings are to warn for computational complexity ... if you use a large database, try not to do this too much ... New property ... sameInidividualAs ... differentIndividualFrom (ugh) Action item for Ian and Peter: Do it, and create a new version for people to look at. Jeff: minor point about compacting things Peter: don't accidentally create any semantics for gray stuff. Mike: Hold off on announcing the new release until after next week's meeting. Pay more attention to PR. Tutoring and explanation are both good things. Perhaps leave ref doc clean as it is, and add a new document with good form, bad form, etc. .... Frank volunteered .... Jim: for agenda for next week ... I've been in contact with some of the EU folks. They want to know what happens to the committee next. Some thought should go into what we want to tackle next. rules, something else, other gaps? (reification, non monatonicity). Next week, produce a list of what is important to look at ... Jim: Externally we can hide reification under rules ... Need a list of possible next steps ... perhaps Mike can collect and send them out to the list ... Mike agreed.