- From: Jiří Procházka <ojirio@gmail.com>
- Date: Sat, 16 Jan 2010 08:33:14 +0100
- To: Pat Hayes <phayes@ihmc.us>
- CC: Semantic Web <semantic-web@w3.org>
- Message-ID: <4B516BBA.8030301@gmail.com>
On 01/16/2010 06:53 AM, Pat Hayes wrote: > > On Jan 15, 2010, at 4:21 PM, Jiří Procházka wrote: > >> On 01/15/2010 05:36 PM, Pat Hayes wrote: >>> >>> On Jan 15, 2010, at 1:58 AM, Jiří Procházka wrote: >>> >>>> On 01/15/2010 08:06 AM, Pat Hayes wrote: >>>>> >>>>> On Jan 15, 2010, at 12:32 AM, Jiří Procházka wrote: >>>>> >>>>>> On 01/15/2010 06:29 AM, Pat Hayes wrote: >>>>>>> >>>>>>> On Jan 14, 2010, at 10:50 PM, Jiří Procházka wrote: >>>>>>> >>>>>>>> On 01/15/2010 04:17 AM, Pat Hayes wrote: >>>>>>>>> >>>>>>>>> <rant> >>>>>>>>> This brings up a broader issue. Everyone agrees its good to >>>>>>>>> keep RDF >>>>>>>>> simple. But keeping RDF simple by making it in effect into a >>>>>>>>> general-purpose construction kit, and then expecting that as a >>>>>>>>> matter of >>>>>>>>> routine people will use the constructions, isn't really being >>>>>>>>> honest >>>>>>>>> about 'simple'. OWL/RDF is a lot less simple than RDF itself >>>>>>>>> largely >>>>>>>>> because its written in what we might more honestly call >>>>>>>>> OWL-syntax-coded-in-lists-described-using-RDF, which IMO isn't >>>>>>>>> really >>>>>>>>> RDF any more. If we want to expect RDF to do this kind of thing, >>>>>>>>> then it >>>>>>>>> ought to have a whole datastructuring facility built in >>>>>>>>> explicitly, >>>>>>>>> perhaps along JSON lines, rather than prostituting the triple >>>>>>>>> store to >>>>>>>>> be a data structuring tool. >>>>>>>>> </rant> >>>>>>>> >>>>>>>> Wasn't this the whole idea of RDF? Simple language for >>>>>>>> expressing any >>>>>>>> information? Doesn't it use triples, simple relations between two >>>>>>>> objects, specifically for the reason that it is universal, and any >>>>>>>> kind >>>>>>>> of structure can be expressed by it? >>>>>>> >>>>>>> There are two notions of universal here, and we shouldn't get them >>>>>>> confused. One is a universal programming language, which can be >>>>>>> used to >>>>>>> build arbitrary data structures and define operations over them. In >>>>>>> other words, in fact, a programming language. The other sense is a >>>>>>> universal *descriptive* language, which RDF is supposed to be , but >>>>>>> isn't because it is too simple. (Thats why we need OWL, etc.; >>>>>>> though RDF >>>>>>> is closer than I used to think, see my ISWC talk.) >>>>>>> >>>>>>> My point was only that if RDF needs to *use* sequences (like, as >>>>>>> data >>>>>>> structures to encode OWL syntax, for example, or as a way of hacking >>>>>>> N-ary relations using only binary links) then this is more like >>>>>>> building >>>>>>> data structures than describing anything, and maybe it would be >>>>>>> better >>>>>>> to admit this up front and deal with it with a real datatstructuring >>>>>>> notation. It wasn't the whole idea of RDF to have it be a kind of >>>>>>> awkward version of simplified LISP. >>>>>> >>>>>> No, I am not mixing in programming languages, I am talking about >>>>>> descriptive language, though I am not a logician, so could you please >>>>>> explain what universal descriptive language needs to fulfill (or >>>>>> provide >>>>>> a link to such explanation)? I cannot imagine anything that cannot be >>>>>> described by RDF+RDFS - you say we need OWL - but OWL is defined >>>>>> using >>>>>> RDF+RDFS. >>>>> >>>>> No, its not! OWL is a different language from RDF, and its not >>>>> defined >>>>> in RDF. In fact, it couldn't be defined in RDF, since RDF is not >>>>> expressive enough. Both RDFS and OWL/RDF are semantic extensions of >>>>> RDF, >>>>> but that means that they need 'extra' semantics in addition to that >>>>> provided by RDF. In the case of OWL/RDF, it wasn't at all easy to >>>>> specify this stuff and keep it consistent with the RDF meanings. >>>> >>>> Now things clears up! >>>> I think we differ in that, that I consider every RDF vocabulary a >>>> semantic extension. You can describe things using descriptive languages >>>> like OWL or RDFS, but also using natural language. >>> >>> True, but what then is the purpose of RDF? Why don't we just use English >>> as the semantic web formalism? This seems to me to be the reductio ad >>> absurdum of your point of view. The idea of the SWeb is that semantic >>> information written in RDF can be processed by machines. And the >>> technology of RDFS, OWL, SPARQL etc. depends entirely upon genuine >>> semantic extensions (as defined in the spec itself) , not just a >>> let-it-all-hang-out idea that anything comment written anywhere can >>> count as an RDF-defined meaning postulate. >> >> Still information in RDF which is using ontology that is defined just by >> natural language (not descriptive - OWL) are worth something and up to a >> certain point can be processed by machines - an engineer has to teach >> his application the ontology. > > I agree, indeed have argued the same point. But this does depend upon > the underlying formalism having some minimal semantic coherence to build > upon. And RDF really is about as minimal as it can get, in this regard. > Apart from the oddities surrounding rdf:XMLLiteral, the only purely RDF > entailments are from a graph to its subgraph, ie the triples are all > 'anded' together, and from a triple with a URI to the similar triple > with a bnode, ie what logicians call existential generalization. And you > only need that last one when you really want to mess with bnodes, mostly > you can ignore it. And that is IT. It is hard to get much less in a > formalism than this. > >> >> Look at FOAF for example... Undoubtedly there is demand for such >> lightweight semantics. > > It relies upon the RDF (and bits of RDFS) semantics, though. Not of > course to DEFINE its meanings, but to support what little inference that > engines might need to draw; and they do: inverse functional properties > for example play a critical role in FOAF deployment. > >> If it was to be defined by some descriptive >> language... to be frank, I can't imagine that - it would probably be >> some upper ontology stuff which is subject of many disagreements. > > Agreed, we don't need that. I'm all for lightweight ontologies. But they > still use the semantics of the formalism they are written in. > >> That >> is why we shouldn't embrace one specific descriptive language as main >> RDF formalism, we should be able to choose it, therefore defining the >> level our ontologies can be reasoned about by machines. > > No, here you go off the rails. Look, RDF does not define the meanings of > FOAF, of course. But FOAF itself does use the formally defined (and very > weak) meanings of things like rdf:type and > owl:inverseFunctionalProperty; and it would actually break if these were > arbitrary or not defined with some precision. > >> Saying something >> like "DL should be good enough for everyone" might be a mistake... > > I agree. > >> >> As I understand it, you expect to teach your machine RDF, and be able to >> "understand" whole semantic web. > > NOt at all. But we do have to accept that if RDF is the lingua franca of > the sweb, then all other extensions of it have to conform to what it > provides normatively. And as I say, that is really very little. Great, then in fact we agree. Without defining something, there would be nothing to build on. What I want RDF formalism to be is nothing more than the general notion of a triple and a set of triples (graph). I had a mistaken impression that you wanted something much more, thanks for clearing that up. >> My view is I have to continuously teach >> it new formalism which are starting to get used on the web (unless they >> are defined by some formalism it already understands). >> >> I'm all for having a widely used and W3C blessed ontology for defining >> ontologies using set theory and formal logic, on top of RDF, but not as >> a part of it. I guess it's mainly a question of proper modular design >> and low barrier of entry, since I don't know of any competing logic >> theories to be honest, but I expect there are some or will be in future. > > Competing with RDF? Oh my goodness yes. There are LIBRARIES of them. What I think is important, is to communicate the choice of the RDF formalism - why it is defined as it is - to the general public, to convince them that really RDF is THE universal language for machines, that RDF really defines as little as possible and that all theirs different philosophies and logic systems are ok under RDF. This is a great challenge and what really the "RDF 2.0" effort should be about, also involving clearing up the RDF semantics, and I would also recommend making an version targeted at non-logician crowd (a quite large crowd including myself). Best, Jiri > Pat > >> >> Best, >> Jiri >> >> PS: Others: Sorry for confusion, 3 mails accidentally went off list, >> they are quoted here of course. >> >>>> In any case your >>>> description is just a imperfect surrogate of your view of the described >>>> things (depending how deep is your understanding and how good is your >>>> skill with the descriptive/natural language) which is a surrogate of >>>> the >>>> things themselves (depends what philosophy you subscribe to). >>>> If we want RDF to be universal information interchange language, we >>>> shouldn't bless one way of reasoning about things (DL) or enforce usage >>>> of some top-level ontology (which is essentially the same thing), and >>>> expect data to be semantic mess like minds of all people put >>>> together... >>>> >>>>>> Anyway you probably meant the universal descriptive language has >>>>>> to be >>>>>> able to describe anything using only it's own terms, be self-hosted >>>>>> (bootstrapped), not aided by natural language like with RDFS. >>>>> >>>>> RDFS is defined by the RDFS semantic conditions, not by natural >>>>> language >>>> >>>> And how are these semantic conditions defined? >>> >>> Using *mathematics*. And this is not a joke: although the math may be >>> written in English, the only aspects of English meaning that it relies >>> upon are those that define the meanings of terms in set theory and >>> formal logic. >>> >>>> >>>> Best, >>>> Jiri >>>> >>>> PS: You took the discussion off list, dunno if it's intentional >>> >>> No, it wasnt intentional. But whatever :-) >>> >>>> , any way >>>> is good with me. Maybe will write a blog post someday about what I >>>> learn >>>> from you. >>>> >>>> >>>>>> I don't see why it needs to be that way, in fact I see that as its >>>>>> strength - we can use it to describe things with various levels of >>>>>> detail. For example I can define simply: >>>>>> >>>>>> <NaturalNumbers> a rdfs:Class ; >>>>>> rdfs:comment "A class of natural numbers - integers which are greater >>>>>> than zero" . >>>>> >>>>> But you still need some way to actually write the numbers down, ie >>>>> some >>>>> numerical convention. There are several of them, so you need to say >>>>> which one you are using. Now you have datatyped literals. >>>>> >>>>>> >>>>>> Or I could use OWL and express formally it's relation to integers, >>>>>> but I >>>>>> don't need to. >>>>>> >>>>>>>> Why should we give preferential >>>>>>>> treatment to relations describing structure than those describing >>>>>>>> time, >>>>>>>> measures, events, organizations, people, pizzas...? >>>>>>> >>>>>>> Because they aren't *descriptions* of structure, they are structures >>>>>>> being used to describe other things. Just like triples are. >>>>>> >>>>>> I believe triples were chosen because they are the simplest of the >>>>>> structures, yet can describe any other. >>>>> >>>>> They are simplest and extremely useful, yes. But using them to >>>>> *describe* others, which are then also themselves used to describe >>>>> other >>>>> things, gets the syntax/semantic levels all mixed up. >>>>> >>>>>> >>>>>> Do you intend to define all structures possible which can be used to >>>>>> describe other things? >>>>>> >>>>>>>> This is what I always thought what RDF was supposed to be and >>>>>>>> things >>>>>>>> like containers, blank nodes, literal data types, language tags >>>>>>>> got in >>>>>>>> because of pragmatical reasons, mainly to give users some kind of >>>>>>>> direction, examples how to get started. >>>>>>> >>>>>>> Well, not really. All of these things are needed in order to >>>>>>> describe >>>>>>> things that people wanted to describe, and couldn't be described any >>>>>>> other way. If you don't have literals, how are you going to use >>>>>>> numbers >>>>>>> in a description? Without language tags, how are you going to say >>>>>>> that >>>>>>> something is written in French? Well, OK, maybe containers... >>>>>> >>>>>> <data:text/plain;charset=utf-8,Je%20ne%20comprends%20pas.> >>>>>> ex:language >>>>>> lang:French . >>>>> >>>>> Well, OK, but you essentially have the lang tags here as language >>>>> 'classes'. Whats the advantage? If these are part of the language, >>>>> then >>>>> they are just more longwinded tags. If they aren't, then what "knows" >>>>> that lang:French means French? (RDF doesn't know this, right?) >>>>> >>>>> I think we did try out a design like this with language properties. >>>>> But >>>>> you have to say what it means when the language information is >>>>> missing. >>>>> Tags in literals make it compulsory, which is good for some purposes. >>>>> >>>>>> >>>>>> I don't advocate using data URI scheme instead of literals, but it >>>>>> should be possible. >>>>>> Maybe you are right about the blank nodes though, I am not sure if >>>>>> this >>>>>> would work (meaning the URI is irrelevant): >>>>>> >>>>>> <j48fd8dj3> rdf:type ex:UnnamedNode . >>>>> >>>>> No, that confuses use and mention. The thing denoted isn't a blank >>>>> node. >>>>> >>>>>> >>>>>>>> Reality that even such thing as RDFS was made separate of the RDF >>>>>>>> itself >>>>>>>> support my view (even though I suspect one of reasons if that >>>>>>>> separation >>>>>>>> was the process of it's development). >>>>>>> >>>>>>> Yes, most the latter. I would have preferred to have one namespace, >>>>>>> but >>>>>>> this was set in stone very early on. >>>>>>> >>>>>>>> >>>>>>>> On the other hand I am not against creating community developed >>>>>>>> framework for making common uses of Semantic Web technologies >>>>>>>> easier, >>>>>>>> defining useful structures and design patterns... but build that >>>>>>>> *on >>>>>>>> top* of RDF as separate framework. >>>>>>>> >>>>>>>> I would like RDF to be as lightweight (low level) as possible - >>>>>>>> if I >>>>>>>> were to make mine RDF, there would be no containers, bnodes, >>>>>>>> literal >>>>>>>> data types, language tags, maybe even no literals - using data URI >>>>>>>> scheme. Anyway I value compatibility and adoption more than >>>>>>>> sticking to >>>>>>>> my view of the world so I use RDF as it is. >>>>>>>> >>>>>>>> Other alternative would be to have the low level core, build >>>>>>>> modules on >>>>>>>> top of it, for example like some programming languages do (Python, >>>>>>>> Java...) and call the whole thing RDF - I guess that is what would >>>>>>>> make >>>>>>>> most people happy. >>>>>>> >>>>>>> But this whole idea of 'building modules on top' is a programming >>>>>>> idea, >>>>>>> not a description language idea. It muddles up the notion of a >>>>>>> description. Which 'level' defines the semantics you should be >>>>>>> using in >>>>>>> a query? There's no way to know. >>>>>> >>>>>> You can use any level, because all levels are defined by levels under >>>>>> them, lowest of them being RDF core. >>>>> >>>>> What do you mean by one level being "defined" by another, if these are >>>>> all descriptive languages? Do you imagine RDF core ontologies being >>>>> used >>>>> to describe higher-level meanings? Because that (provably) will not >>>>> work: RDF isn't expressive enough. And if it were expressive enough, >>>>> then we wouldn't need the higher levels, except maybe as syntactic >>>>> sugar. >>>>> >>>>> Pat >>>>> >>>>>> >>>>>> Best, >>>>>> Jiri >>>>>> >>>>>> PS: Actually there is one thing which would aid bootstrapped >>>>>> nature of >>>>>> RDF: >>>>>> >>>>>> ex:contains rdf:type rdf:Property ; >>>>>> rdfs:comment "property for stating that a reified triple is part of >>>>>> graph" ; >>>>>> rdfs:range rdf:Statement . >>>>>> >>>>>>> Pat >>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> Jiri Prochazka >>>>>>>> >>>>>>>>> >>>>>>>>> Pat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Rgds, >>>>>>>>>> >>>>>>>>>> -Geoff >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> IHMC (850)434 8903 or (650)494 >>>>>>>>> 3973 >>>>>>>>> 40 South Alcaniz St. (850)202 4416 office >>>>>>>>> Pensacola (850)202 4440 fax >>>>>>>>> FL 32502 (850)291 0667 mobile >>>>>>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> IHMC (850)434 8903 or (650)494 >>>>>>> 3973 >>>>>>> 40 South Alcaniz St. (850)202 4416 office >>>>>>> Pensacola (850)202 4440 fax >>>>>>> FL 32502 (850)291 0667 mobile >>>>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------ >>>>> IHMC (850)434 8903 or (650)494 >>>>> 3973 >>>>> 40 South Alcaniz St. (850)202 4416 office >>>>> Pensacola (850)202 4440 fax >>>>> FL 32502 (850)291 0667 mobile >>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> ------------------------------------------------------------ >>> IHMC (850)434 8903 or (650)494 3973 >>> 40 South Alcaniz St. (850)202 4416 office >>> Pensacola (850)202 4440 fax >>> FL 32502 (850)291 0667 mobile >>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>> >>> >>> >>> >>> >> > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > >
Received on Saturday, 16 January 2010 07:34:04 UTC