Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Sat, 2011-06-18 at 23:05 -0500, Pat Hayes wrote: Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. I don't think that analogy holds. I don't think this is any sort of meta-language confusion. I agree that (for many applications) documents are more semantically distant from dogs than female dogs are from male dogs, but I see that as merely a difference of degree -- and one that is application dependent -- and not of kind. Semantically, they are all just relations, and some of these relations are important to some applications, and others to others: :x ex:isPrimarySubjectOf :d . :y ex:isSecondarySubjectOf :d . :m ex:isOppositeSexOf :f . To my mind, those all look pretty similar in nature. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. I don't think that's true. But I think my comments will get a bit deeper into semantic web architectural issues than will interest most LOD readers, so I've moved my explanation to the AWWSW list instead: http://lists.w3.org/Archives/Public/public-awwsw/2011Jun/0006.html [ . . . ] So far, http-range-14 is the only viable suggestion I have seen for how to do this. If anyone has a better one, let us discuss it. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. I agree with both of these sentiments though. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 20 Jun 2011, at 02:48, Melvin Carvalho wrote: On 19 June 2011 20:42, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 20:15, Danny Ayers wrote: Only personal Henry, but have you tried the Myers-Briggs thing - I think you used to be classic INTP/INTF - but once you got WebID in your sails it's very different. These things don't really allow for change. Is there a page where I can find this out in one click? Looks like those pages ask all kinds of questions that require detailed and complicated answers. I am surprised anyone ever answers those things. It's certainly more complex than the Object/Document distinction ;-) Myers Briggs is based on the Jungian analysis of mythology and personality types, with a few additions. Myths being public dreams, and dreams being private myths. I think Jung based a lot of his thinking on the iChing which he mentions a lot and for the most famous german translation of which he even wrote an introduction. As it happens the iChing does require of you just one click. It asks the universe to answer what change you are undergoing. http://wengu.tartarie.com/wg/wengu.php?no=0l=Yijing So as opposed to personality analysis which is fixed apparently, this is easy to use - though quite complex and open to interpretation. The personality types are the lens from which we interpret the inner and outer universal symbols. e.g. Intuitively / Analytically / Senses / Feeling. But the symbols themselves are often the more fascinating parts. yes, the inner/outer distinction also comes from the iChing. The upper trigram represents the outer, the lower trigram represents the inner. Btw, these trigrams even appear in the UTF-8 symbols. An interesting parallel here is the relation to Jung's archetypes of the unconscious and WebID. Both in your dreams, and in mythology, you have symbols where are metaphors that reference some universal concept. WebID is of course a reference to the self ( foaf : Person ). Perhaps to the self that is only as much as the strength of his links to others. As many of the myths we live with today are 100s of years out of date, and people are searching for something new, perhaps WebID can become a modern symbol, to determine or even evangelize the new personality type of society, post information revolution :) I see it more as a tool that by tying in people into the network will grow the network of semantic web supporters and evangelisers. Perhaps it can become mythical. The URL should be by now :-) Henry Only slightly off-topic, very relevant here, need to pin down WebID in a sense my dogs can understand. Ok. So you need to give each of your dogs and cats a webid enabled RDFID chip that can publish webids to other animals with similarly equipped chips when they sniff them. From the frequence and length of sniffs you can work out the quality of the relationships. On coming home for food, this data could be uploaded automatically to your web server to their foaf file. These relationships could then be used to allow their pals access to parts of your house. For example good friends of your dog, could get a free meal once a week. You could also use that to tie up friendship with their owners, by the master-of-pet relationships, and give them special ability to tag their pet photos. Masters of my dogs friends could be potential friends. If you get these pieces working right you could set up a business with a strong viral potential, perhaps the strongest on the net. Here to make my point: The Myers-Briggs thing is intuitively rubbish. But with only one or two posts in the ground, it does seem you can extrapolate. On 19 June 2011 19:52, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 19:44, Danny Ayers wrote: I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. I confess to talking bollocks when I should be coding. yeah, me too. Though now you folks managed to get me interested in this problem! (sigh) Henry Social Web Architect http://bblfish.net/ -- http://danny.ayers.name Social Web Architect http://bblfish.net/ Social Web Architect http://bblfish.net/
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/20/11 8:31 AM, Henry Story wrote: Perhaps it can become mythical. The URL should be by now:-) The URI :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/20/11 10:39 AM, Henry Story wrote: On 20 Jun 2011, at 10:51, Kingsley Idehen wrote: On 6/20/11 8:31 AM, Henry Story wrote: Perhaps it can become mythical. The URL should be by now:-) The URI :-) Perhaps we should write it URi to get a bit of Apple magic. Pronounced your-eye, Neat and implicit ! it does indeed have this you--i tension, which French philosopher of technology Bernard Stiegler, elaborating on work by Gilbert Simondon from the 1960ies (especially his book L'Individuation psychique et collective to appear in translation this summer in English I am told) takes as fundamental to our understanding of the self. There is no individual first and social after or on the side, or vice versa. Individuation is a process of integration of the social via history passed down through oral traditions initially (by memorisation of poems such as the Iliad), through alphabetic writing - the most important technological transformation brought on by the ancient greeks; ancient greece where kids had to go to school to learn to read and write, so they could learn the laws of the city written on the walls of Athens for all to see - and then in the 20th century through radio, and television. This learning one's societies past and learning who one is, is the same process that then allows one to distinguish oneself from the social and within it. Individuation cannot happen without the social background, just as the social can flourish only to the extent that it gives the individual a place to distinguish himself within it. Societies themselves are individualised by how they distinguish themselves from others... Yep! So your WebID indeed identifies you, but within the space of your social and conceptual relations. Amen! WebID is a very powerful demonstration of what makes Linked Data so powerful. It solves real problems that can't be fixed objectively (distributed fashion without central control) in the Information Space dimension. Kingsley Henry -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen Social Web Architect http://bblfish.net/ -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/20/11 1:48 AM, Melvin Carvalho wrote: Myers Briggs is based on the Jungian analysis of mythology and personality types, with a few additions. Myths being public dreams, and dreams being private myths. The personality types are the lens from which we interpret the inner and outer universal symbols. e.g. Intuitively / Analytically / Senses / Feeling. But the symbols themselves are often the more fascinating parts. An interesting parallel here is the relation to Jung's archetypes of the unconscious and WebID. Both in your dreams, and in mythology, you have symbols where are metaphors that reference some universal concept. WebID is of course a reference to the self ( foaf : Person ). As many of the myths we live with today are 100s of years out of date, and people are searching for something new, perhaps WebID can become a modern symbol, to determine or even evangelize the new personality type of society, post information revolution:) Nicely stated! I knew it would only take a little Star Wars mythology, dimensionality, and WebID to smoke you out :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 20 June 2011 10:51, Kingsley Idehen kide...@openlinksw.com wrote: On 6/20/11 8:31 AM, Henry Story wrote: Perhaps it can become mythical. The URL should be by now:-) The URI :-) The mythical URI, perfect. -- http://danny.ayers.name
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 June 2011 20:42, Henry Story henry.st...@bblfish.net wrote: Ok. So you need to give each of your dogs and cats a webid enabled RDFID chip To inject a little reality: Sashapooch has got an embedded RFID (not yet RDFID!) tag, not sure but I think it became Italian law. Basilhound being a bit older, before this stuff came in, has a (sloppy) tattoo on his tummy, something like LOLU51. I assume the chip in Sasha has a similar string in it. But the idea is great - in the same way QR codes are most useful when they include a URL, putting one in the RFID tag of animals makes a lot of sense. Simple use case: when the critter wanders off, you can easily contact the owner. I know the RFID chips are now really cheap commodities, what I don't know about is the scanners - are they yet affordable enough that you could say include one in a mobile phone? Cheers, Danny. -- http://danny.ayers.name
Re: Fwd: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Point taken, I forget where I am sometimes, will try harder. My apologies. On 19 June 2011 21:06, Nathan nat...@webr3.org wrote: Danny Ayers wrote: I feel very guilty being in threads like this. Shit fuck smarter people than me. Just minor, and I can hardly talk as I swear most often in different settings, but I am a little surprised to see this language around here. I quite like having an arena where these words don't arise in the general conversation. Ack you know what I'm saying - nothing personal, but I'd personally appreciate not seeing them too frequently around here :) Best! -- http://danny.ayers.name
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/20/11 14:01 , Danny Ayers wrote: On 19 June 2011 20:42, Henry Storyhenry.st...@bblfish.net wrote: Ok. So you need to give each of your dogs and cats a webid enabled RDFID chip To inject a little reality: Sashapooch has got an embedded RFID (not yet RDFID!) tag, not sure but I think it became Italian law. Basilhound being a bit older, before this stuff came in, has a (sloppy) tattoo on his tummy, something like LOLU51. I assume the chip in Sasha has a similar string in it. But the idea is great - in the same way QR codes are most useful when they include a URL, putting one in the RFID tag of animals makes a lot of sense. Simple use case: when the critter wanders off, you can easily contact the owner. I know the RFID chips are now really cheap commodities, what I don't know about is the scanners - are they yet affordable enough that you could say include one in a mobile phone? Danny, At least one of my phones (the Nexus S) has one, though not very useful yet; It does react to Dutch public transport chip cards and my Finnish passport with Unknown tag type. Yrjänä Cheers, Danny. -- Mr. Yrjana Rankka| gh...@openlinksw.com Developer, Virtuoso Team | http://www.openlinksw.com | Making Technology Work For You
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Point taken Pat but I have been in the same ring as you for many years, but to progress the Web can't we just take our hands off the wheel, let it go where it wants. (Not that I have any influence, and realistically you neither Pat). I'm now just back from a sabbatical, but right now would probably be a good time to take one. If these big companies do engage on the microdata front, it's great. I'm sure it's been said before, why don't we get pornographers working hard on their metadata on visuals, because they work for Google/Bing whatever. The motivation right now might not be towards Tim's day one goals of sharing some stuff between departments at CERN, but that's irrelevant in the longer term. Getting the the Web as an infrastructure for data seems like a significant step in human evolution. And it's a no-brainer. But getting from where we are to there is tricky. Honestly, I don't care. It'll happen, my remaining lifespan or about 50 on top, there will be another, big, revolution. Society is already so different, just with little mobile phones. /gak I'm no going to speculate, we're heading for a major change. Cheers, Danny. On 19 June 2011 06:05, Pat Hayes pha...@ihmc.us wrote: Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. So far, http-range-14 is the only viable suggestion I have seen for how to do this. If anyone has a better one, let us discuss it. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. Pat On Jun 18, 2011, at 1:51 PM, Danny Ayers wrote: On 17 June 2011 02:46, David Booth da...@dbooth.org wrote: I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. Thanks David, a nice summary of the most important point IMHO. Ok, I've been trying to rationalize the case where there is a failure to make the distinction, but that's very much secondary to the fact that nothing really gets broken. Cheers, Danny. http://danny.ayers.name 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 -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 06:05, Pat Hayes wrote: Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. The way to do this is to build applications where this thing matters. So for example in the social web we could build a slightly more evolved like protocol/ontology, which would be decentralised for one, but would also allow one to distinguish documents, from other parts of documents and things. So one could then say that one wishes to bring people's attention to a well written article on a rape, rather than having to like the rape. Or that one wishes to bring people's attention to the content of an article without having to like the style the article is written in. If such applications take hold, and there is a way the logic of using these applications is made to work where these distinctions become useful and visible to the end user, then there will be millions of vocal supporters of this distinction - which we know exists, which programmers know exists, which pretty much everyone knows exists, but which people new to the semweb web, like the early questioners of the viability of the mouse and the endless debates about that animal, will question because they can't feel in their bones the reality of this thing. So far, http-range-14 is the only viable suggestion I have seen for how to do this. Well hash uris are of course a lot easier to understand. http-range-14 is clearly a solution which is good to know about but that will have an adoption problem. If anyone has a better one, let us discuss it. I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. One could argue much more fruitfully on DocumentObject ontologies, and it would be interesting to see where that leads one. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. Well these are logical necessities you are speaking of. So it will come out in the wash. Just like 2+2=4, those who wish to ignore it will loose out in a number of transactions. So the fun thing is that we can find completely coherent ontologies that don't brake the semweb and that would allow Richard Cyganiak to write http://richard.cyganiak.de/ a foaf:Document; dofoaf:name Richard Cyganiak; dc:title: Richard Cyganiak's homepage; dofoaf:knows http://bblfish.net/ . It looks like here that the document has been confused with the object, but in fact the relations are designed so that they indirectly refer to something else. Now it is not clear that this is easier or less confusing to write than pure foaf. But it does make it look like what Danny wants to have is happening, namely that the document refers to the thing too - assuming a document only refers to one thing. But that is already the main problem. Even an image never refers to one thing only. Take a simple image of the eiffel tower: there can be cars in it, there can be birds, mice, rats (ratatouille), and many other creatures jumping around on people's heads. The higher the resolution the more things that picture can be said to refer to. So to know which is the
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 7:43 AM, Danny Ayers wrote: Point taken Pat but I have been in the same ring as you for many years, but to progress the Web can't we just take our hands off the wheel, let it go where it wants. (Not that I have any influence, and realistically you neither Pat). I'm now just back from a sabbatical, but right now would probably be a good time to take one. If these big companies do engage on the microdata front, it's great. I'm sure it's been said before, why don't we get pornographers working hard on their metadata on visuals, because they work for Google/Bing whatever. The motivation right now might not be towards Tim's day one goals of sharing some stuff between departments at CERN, but that's irrelevant in the longer term. Getting the the Web as an infrastructure for data seems like a significant step in human evolution. And it's a no-brainer. But getting from where we are to there is tricky. Honestly, I don't care. It'll happen, my remaining lifespan or about 50 on top, there will be another, big, revolution. Society is already so different, just with little mobile phones. /gak I'm no going to speculate, we're heading for a major change. Danny, Do you agree with HTTP-range-14 finding or not? My gripe with HTTP-range-14 is all about aesthetic matters re. language and anecdote choices, not the core concept it attempts to articulate. If you clearly state your gripe in similar terms there could be a chance of yourself and Pat actually realizing that you are in agreement. Personally, I've always assumed you clearly groked why Name and Address disambiguation is vital re. Web's data space dimension. I am suspecting that you are saying: we should find ways to co-exist with initiatives (e.g. schema.org) that haven't addressed these matters, just yet etc.. Note: many are grappling with how to construct viable business models from Linked Data, thus in some cases you will have services that look like they don't care about Name and Address disambiguation on the outside, courtesy of their publicly accessible resources, while in reality they understand these matters very well and have put them you use for a while. Remember, a URI doesn't have to be public :-) I think the debate will ultimately be more about getting these big players to share their more powerful URIs with the public via services and apps from communities like this that make the opportunity costs of these big players palpable :-) Kingsley Cheers, Danny. On 19 June 2011 06:05, Pat Hayespha...@ihmc.us wrote: Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. So far, http-range-14 is the only viable suggestion I have seen for how to do this. If anyone has a better one, let us discuss it. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. Pat On Jun 18, 2011, at 1:51 PM, Danny Ayers wrote: On 17 June 2011 02:46, David Boothda...@dbooth.org wrote: I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not*
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Hi Hugh, By the way, as is well-known I think, a lot of people use and therefore must be happy with URIs that are not Range-14 compliant, such as http://www.w3.org/2000/01/rdf-schema . Your general point that there is non-compliant data out there that people are still able to make use of is probably right, but that specific example is compliant - those are all (even the ontology URI) hash-URIs. Dave
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 13:05, Hugh Glaser wrote: A step too far? Hi. I've sort of been waiting for someone to say: I have a system that consumes RDF from the world out there (eg dbpedia), and it would break and be unfixable if the sources didn't do 303 or #. Plenty of people saying they can't express what they want without it. And plenty of people saying they can't write some code that they might not be able to understand some RDF they receive properly. But no actual examples in the wild (at least as far as I can tell in a lot of messages). This might be for quite a few reasons, such as: 1) There are no such consuming systems; 2) The existing consuming systems would not break. Number (1) would be too embarrassing, and is wrong because I have some, so I'll think about number (2). As you point out there are some consuming systems but they are not very distributed: you know ahead of time what you will find there, and so you can adapt your parsing for the few special cases. At that level the XML crowd/JSON crowd are right - rdf does not give you much. In fact it makes it easier to do things wrong. So we should be supporting more RESTful XML that can be GRDDLed with X-SPARQL. The semweb gives you a lot more when things get even more distributed, such as when everyone starts having foaf files on billions of computers. At that point nobody will want to tweak their app for the specific data at one site. Also one will want to be careful of the difference between documents and things, for the same reason I pointed out with the like button in Facebook. So for the moment the errors don't appear, because we are few consumers and few producers, and we can work around mistakes manually on a case by case basis. To get a real linked data application you need: 1- data that is produced in a completely decentralised way 2- data that is linked between those decentralised nodes 3- data that is consumed, and where the consumption has real world effects Number 3 is the recursive feedback piece that will make 1 and 2 come to a point of stability, or meta-stability, as we are dealing with self organising systems here. This can be done with the social web. We need systems where you publishing data means that I can do something, learn something about you, and so on... but without you ever knowing ahead of time what software or services we are using. (( The Twitters and other Web2.0 folks have made their life easy by centralising data publishing and consumption as much as possible. For systems like there is no real communication problem: there is a central dictator and he says what the meaning of the terms go. As things evolve that part even escapes him - the way office document formats escaped M$ - because of the huge number of people and software dependent on the initial meaning produced.)) If I write things out wrong, your software should be able to let me know about it. Just as if we organise to meet but we give each other the wrong address, we will end up missing the meeting. If this were not so then giving out addresses and organising meetings would be a very different exercise. There seem to be some axes in the discussion: publish / consume long/medium term / shorter term ideal / pragmatic Interestingly, we don't seem to have a strong theory / practice axis, which is great. yes, my point has been we need to work on small vocabularies, widely distributed, widely used, to kick start the rest of the system As a publisher, I/we have had to work pretty hard to conform to really quite complex requirements for publishing RDF as Linked Data; not just Range-14, but voiD, sitemaps and various bits and pieces that Kingsley always tells me to do in the RDF. As a consumer, it has been pretty simple: Well guv, thanks for the URI, here's some RDF. It has always been something of a source of angst (if not actual pain) to me that none of the extra work I put into publishing RDF is ever used by me or anyone else, as far as I know. In fact, some of the sites I consume actually don't do things properly - I might have had to change my consuming systems to cope with this, but I don't, because they already cope fine. Why is it not a problem? One obvious reason is that the consuming application is actually looking for specific knowledge about things. And as pointed out above they are not that distributed, and the consequences of things going wrong on a lot of the open data stack is not that big yet. I don't have a consuming system that is considering both lexical and animal subjects, and so confusion does not arise. Also you are probably not putting up reasoners yet. In fact, it is the predicates that tend to distinguish satisfactorily for me (as has been pointed out by some people). Thus, if I get a triple that says the URI that would resolve to my Facebook page foaf:knows the URI that would resolve to your Facebook page, I (my system)
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 12:05 PM, Hugh Glaser wrote: A step too far? Hi. I've sort of been waiting for someone to say: I have a system that consumes RDF from the world out there (eg dbpedia), and it would break and be unfixable if the sources didn't do 303 or #. Plenty of people saying they can't express what they want without it. And plenty of people saying they can't write some code that they might not be able to understand some RDF they receive properly. But no actual examples in the wild (at least as far as I can tell in a lot of messages). This might be for quite a few reasons, such as: 1) There are no such consuming systems; 2) The existing consuming systems would not break. Number (1) would be too embarrassing, and is wrong because I have some, so I'll think about number (2). There seem to be some axes in the discussion: publish / consume long/medium term / shorter term ideal / pragmatic Interestingly, we don't seem to have a strong theory / practice axis, which is great. As a publisher, I/we have had to work pretty hard to conform to really quite complex requirements for publishing RDF as Linked Data; not just Range-14, but voiD, sitemaps and various bits and pieces that Kingsley always tells me to do in the RDF. As a consumer, it has been pretty simple: Well guv, thanks for the URI, here's some RDF. It has always been something of a source of angst (if not actual pain) to me that none of the extra work I put into publishing RDF is ever used by me or anyone else, as far as I know. Er. we use it :-) The problem with this whole Linked Data thing is that its truly Ninja tech. The killer conductor of value is the LINK. This lethal weapon applies to all dimensions of the Web: 1. Information Space 2. Data Space 3. Knowledge Space. Trouble is, where do we find strong anecdotes for a cross dimensional lethal weapon? I try to use Stars Wars and the FORCE at times, but even that doesn't quite nail what we are dealing with here. Thus, we could take another approach i.e., embrace and extend what we know is anomalous since the AWWW architecture (FORCE) actually lets us do this anyway. In fact, some of the sites I consume actually don't do things properly - I might have had to change my consuming systems to cope with this, but I don't, because they already cope fine. Exactly! You are using the FORCE :-) Why is it not a problem? One obvious reason is that the consuming application is actually looking for specific knowledge about things. I don't have a consuming system that is considering both lexical and animal subjects, and so confusion does not arise. You have a Data Space dimension app. The Information Space dimension doesn't interfere with your world view. This is key in many ways. For instance, imagine if your app was of the Information Space dimension instead, the effect would be very close to what we see today re. those that see Name and Address disambiguation as impractical overkill since nothing breaks in the world they experience. In fact, it is the predicates that tend to distinguish satisfactorily for me (as has been pointed out by some people). Yep! The Data Space realm lets you Describe anything with clarity, and even when unclear, agents can ultimately agree to disagree without obliteration. Thus, if I get a triple that says the URI that would resolve to my Facebook page foaf:knows the URI that would resolve to your Facebook page, I (my system) will happily interpret that as one person (or whatever) foaf:knows the other. I certainly don't want to go and resolve these to find out to what the URIs actually resolve. And if I did, what would I do about it? Ignore it? As you would in code generally, encounter an exception, and decide if you avoid making it a critical fault :-) In fact, as has also been mentioned, you can define domains, ranges and restrictions for as long as you like, but it is quite possible and likely that the users of URIs will continue blissfully unaware of any of this, in exactly the same way that they continue unaware that there might be something ambiguous about the URIs they are using. Yes, when they operate in the Information Space dimension. By the way, as is well-known I think, a lot of people use and therefore must be happy with URIs that are not Range-14 compliant, such as http://www.w3.org/2000/01/rdf-schema . In the Information Space dimension, yes. In that dimension it doesn't matter. When we help people publish, it really is tough to engage them long enough to care about the complex issues, and they often get it wrong - I am engaged with quite a few people who are now publishing serious amounts of interesting RDF where I have contacted them to try to help. The status of the conversations is that they have fixed what they can, and are now thinking (for a long time) about how they might configure their systems to do it properly - but they may never get there. I will still want to use their
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 14:04, Kingsley Idehen wrote: Er. we use it :-) The problem with this whole Linked Data thing is that its truly Ninja tech. The killer conductor of value is the LINK. This lethal weapon applies to all dimensions of the Web: 1. Information Space 2. Data Space 3. Knowledge Space. Trouble is, where do we find strong anecdotes for a cross dimensional lethal weapon? I try to use Stars Wars and the FORCE at times, but even that doesn't quite nail what we are dealing with here. Thus, we could take another approach i.e., embrace and extend what we know is anomalous since the AWWW architecture (FORCE) actually lets us do this anyway. That's a fun way of describing things. But we have to be careful not to hype things too much, or we risk being tied into the 1980 AI hype space, and then nobody will listen anymore. Perhaps a more scientific way to express this is within the language of self-organising systems. There is a lot of research there which is relevant to us. http://en.wikipedia.org/wiki/Self_organising_systems I am a bit new to this area. Any books I must read? Henry Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Thanks Henry. Just to be clear on one point: On 19 Jun 2011, at 12:44, Henry Story wrote: snip / When we help people publish, it really is tough to engage them long enough to care about the complex issues, and they often get it wrong - I am engaged with quite a few people who are now publishing serious amounts of interesting RDF where I have contacted them to try to help. The status of the conversations is that they have fixed what they can, and are now thinking (for a long time) about how they might configure their systems to do it properly - but they may never get there. I will still want to use their RDF. yes, in these case by case scenarios it is easy for you to write special case filters. And we could do the same thing with HTML whenever we browse the web too. But the web had an application: the browser that lead to feedback effects that increased the coherence of the system. snip / But I don't write special case filters - if I did it would not consider it Semantic Web. I simply follow my nose to use the URI (or in fact usually via an owl:sameas in a sameas store), and they work. It all works because my code that consumes the retrieved RDF to build the data enrichment by inference (things like the communities of practice), and things like my fresnel lenses, restrict any ambiguity by looking for the predicates, etc. they care about. RDF can be a long way short of what we want it to be without having to treat it as special cases.
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 12 Jun 2011, at 14:40, Danny Ayers wrote: [snip] Aside from containing a different bunch of bits because of the encoding, sasha-photo.jpg could be a lossy-compressed version of sasha-photo.gif, containing less pixel information yet sharing many characteristics. All ok so far..? If so, from this we can determine that a representation of a resource need not be complete in terms of the information it contains to fulfill the RDF statement and the HTTP contract. A photo and a graph work in essentially the same way. They both set restrictions on possible worlds of which they are true. A photo restricts the number of possible worlds to those that are visually equivalent to the picture taken. A graph is true of all the possible worlds where those relations holds - which is usually infinitely large. In either case the meaning of a graph or document is a set of possible worlds. A set is an object - one can speak of it - but a very different kind of object from what you may think of as what appears in the picture. As such there is indeed a fundamental logical difference between a document and objects in the world. And that also explains why a photo is not clearly about one thing or another - though of course given that it is a restriction on the way things can be, it limits the things the document could be about. As stated in a previous mail, the same photo can be about the eiffel tower, a sunset, a beautiful view of Paris, a vacation experience, a friend that appears in the picture, a murder that was commited at that moment,... The photo remains the same in all those descriptions, and it can be tagged in all those ways, which is why it is good to have names for each of those things that are different from the photo. Each of those should have definite descriptions to help identify the referents from the description. Henry Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 13:04, Kingsley Idehen wrote: On 6/19/11 12:05 PM, Hugh Glaser wrote: A step too far? Hi. I've sort of been waiting for someone to say: I have a system that consumes RDF from the world out there (eg dbpedia), and it would break and be unfixable if the sources didn't do 303 or #. Plenty of people saying they can't express what they want without it. And plenty of people saying they can't write some code that they might not be able to understand some RDF they receive properly. But no actual examples in the wild (at least as far as I can tell in a lot of messages). This might be for quite a few reasons, such as: 1) There are no such consuming systems; 2) The existing consuming systems would not break. Number (1) would be too embarrassing, and is wrong because I have some, so I'll think about number (2). There seem to be some axes in the discussion: publish / consume long/medium term / shorter term ideal / pragmatic Interestingly, we don't seem to have a strong theory / practice axis, which is great. As a publisher, I/we have had to work pretty hard to conform to really quite complex requirements for publishing RDF as Linked Data; not just Range-14, but voiD, sitemaps and various bits and pieces that Kingsley always tells me to do in the RDF. As a consumer, it has been pretty simple: Well guv, thanks for the URI, here's some RDF. It has always been something of a source of angst (if not actual pain) to me that none of the extra work I put into publishing RDF is ever used by me or anyone else, as far as I know. Er. we use it :-) Er, I'm not sure you do :-) You certainly consume it, and a very nice job you do to. But the use is more than generic browsers - it suggest to me that something useful might happen as a result of the consumption (perhaps I learn that I can ask Jim to introduce me to Mary, as he knows her better than anyone else I know). These things are usually called applications, or possibly services. They tend to be reasonably domain-specific, as generic things tend not to be easy to sue, or even fit for purpose for end users. Sorry if I have missed stuff. The problem with this whole Linked Data thing is that its truly Ninja tech. The killer conductor of value is the LINK. This lethal weapon applies to all dimensions of the Web: 1. Information Space 2. Data Space 3. Knowledge Space. Trouble is, where do we find strong anecdotes for a cross dimensional lethal weapon? I try to use Stars Wars and the FORCE at times, but even that doesn't quite nail what we are dealing with here. Thus, we could take another approach i.e., embrace and extend what we know is anomalous since the AWWW architecture (FORCE) actually lets us do this anyway. In fact, some of the sites I consume actually don't do things properly - I might have had to change my consuming systems to cope with this, but I don't, because they already cope fine. Exactly! You are using the FORCE :-) Why is it not a problem? One obvious reason is that the consuming application is actually looking for specific knowledge about things. I don't have a consuming system that is considering both lexical and animal subjects, and so confusion does not arise. You have a Data Space dimension app. The Information Space dimension doesn't interfere with your world view. This is key in many ways. For instance, imagine if your app was of the Information Space dimension instead, the effect would be very close to what we see today re. those that see Name and Address disambiguation as impractical overkill since nothing breaks in the world they experience. In fact, it is the predicates that tend to distinguish satisfactorily for me (as has been pointed out by some people). Yep! The Data Space realm lets you Describe anything with clarity, and even when unclear, agents can ultimately agree to disagree without obliteration. Thus, if I get a triple that says the URI that would resolve to my Facebook page foaf:knows the URI that would resolve to your Facebook page, I (my system) will happily interpret that as one person (or whatever) foaf:knows the other. I certainly don't want to go and resolve these to find out to what the URIs actually resolve. And if I did, what would I do about it? Ignore it? As you would in code generally, encounter an exception, and decide if you avoid making it a critical fault :-) In fact, as has also been mentioned, you can define domains, ranges and restrictions for as long as you like, but it is quite possible and likely that the users of URIs will continue blissfully unaware of any of this, in exactly the same way that they continue unaware that there might be something ambiguous about the URIs they are using. Yes, when they operate in the Information Space dimension. By the way, as is well-known I think, a lot of people use and therefore must be happy with URIs
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some Could it be exactly the other way around? that documents and things described in it are easy to distinguis EXACTLY becouse one is about the other, no one can possibly mess them up/except for idiotic computer algorithms from the 70s that limits themselves to simbolic AI techniques. Otherwise you seem to say that its more difficult to distinguish between a dog and a bitch than it is to distinguish between a dog and a stream of bytes in return to an HTTP request, and that seems a bit funny? look if someone points me at a facebook URL i know its about a person and not about the damn page (which has 2000 ways to change every time that url is resolved anyway. certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. i mean we can go on and tell oursellf we cant possibly write applications that know or understand what facebook URL is about. but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) Gio
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Nathan wrote: Henry Story wrote: On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Sorry, I'm missing something - from what I can see, each document has a number of items, potentially in a hierarchy, and each item is either anonymous, or has an @itemid. Where's the confusion between Document and Primary Subject? Or do you mean from the Schema.org side, where each Type and Property has a dereferencable URI, which currently happens to also eb used for the document describing the Type/Property?
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Absolutely, Pat. Well said. This is really important. Can we please stop the madness of confusing things with documents about them and do what we want to do cleanly and in an efficient way. Tim On 2011-06 -19, at 00:05, Pat Hayes wrote: Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. So far, http-range-14 is the only viable suggestion I have seen for how to do this. If anyone has a better one, let us discuss it. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. Pat
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Henry Gio Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 18:58, Nathan wrote: Nathan wrote: Henry Story wrote: On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Sorry, I'm missing something - from what I can see, each document has a number of items, potentially in a hierarchy, and each item is either anonymous, or has an @itemid. Where's the confusion between Document and Primary Subject? Or do you mean from the Schema.org side, where each Type and Property has a dereferencable URI, which currently happens to also eb used for the document describing the Type/Property? Well I can't really tell because I don't know what the semantics of those annotations are, or how they function. Without those it is difficult to tell if they have made a mistake. If there is no way of translating what they are doing into a system that does not make the confusion, then one could explore what the cost of that will be to them. If the confusion is strong then there will be limitations in what they can express that way. It will then be a matter of working out what those limitations are and then offering services that allow one to go further than what they are proposing. At the very least the good thing is that they are not bringing the confusion into the RDF space, since they are using their own syntax and ontologies. There may also be an higher way to fix this so that they could return a 20x (x-some new number) which points to the document URL (but returns the representation immediately, a kind of efficient HTTP-range-14 version) So there are a lot of options. Currently their objects are tied to an html document. What are the json crowd going to think? In any case there is a problem of translation that has to be dealt with first. Henry Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 June 2011 12:37, Henry Story henry.st...@bblfish.net wrote: [snip pat] The way to do this is to build applications where this thing matters. So for example in the social web we could build a slightly more evolved like protocol/ontology, which would be decentralised for one, but would also allow one to distinguish documents, from other parts of documents and things. So one could then say that one wishes to bring people's attention to a well written article on a rape, rather than having to like the rape. Or that one wishes to bring people's attention to the content of an article without having to like the style the article is written in. I would have come down on you like a ton of bricks for that Henry, if it wasn't for seeing to-and-fro on Facebook about some Nazi-inspired club (Slimelight, for the record). On FB there is no way to express your sentiments. Like/blow to smithereens. If such applications take hold, and there is a way the logic of using these applications is made to work where these distinctions become useful and visible to the end user, then there will be millions of vocal supporters of this distinction - which we know exists, which programmers know exists, which pretty much everyone knows exists, but which people new to the semweb web, like the early questioners of the viability of the mouse and the endless debates about that animal, will question because they can't feel in their bones the reality of this thing. So far, http-range-14 is the only viable suggestion I have seen for how to do this. Well hash uris are of course a lot easier to understand. http-range-14 is clearly a solution which is good to know about but that will have an adoption problem. I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. I confess to talking bollocks when I should be coding. Cheers, Danny. -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 Jun 2011, at 19:44, Danny Ayers wrote: I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. I confess to talking bollocks when I should be coding. yeah, me too. Though now you folks managed to get me interested in this problem! (sigh) Henry Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
I thought forever that if we see iniquities we are duty-bound to stand in the way. But that don't seem to change anything. Let the crap rain forth, if you really need to make sense of it the blokes on this list will do it. Activity is GOOD, no matter how idiotic. Decisions made on very different premises than anyone around here would promote. Sorry, I'm of the opinion that the Web approach is the winner. Alas it also seems lowest common denominator. Cheers, Danny. On 19 June 2011 19:36, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 18:58, Nathan wrote: Nathan wrote: Henry Story wrote: On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Sorry, I'm missing something - from what I can see, each document has a number of items, potentially in a hierarchy, and each item is either anonymous, or has an @itemid. Where's the confusion between Document and Primary Subject? Or do you mean from the Schema.org side, where each Type and Property has a dereferencable URI, which currently happens to also eb used for the document describing the Type/Property? Well I can't really tell because I don't know what the semantics of those annotations are, or how they function. Without those it is difficult to tell if they have made a mistake. If there is no way of translating what they are doing into a system that does not make the confusion, then one could explore what the cost of that will be to them. If the confusion is strong then there will be limitations in what they can express that way. It will then be a matter of working out what those limitations are and then offering services that allow one to go further than what they are proposing. At the very least the good thing is that they are not bringing the confusion into the RDF space, since they are using their own syntax and ontologies. There may also be an higher way to fix this so that they could return a 20x (x-some new number) which points to the document URL (but returns the representation immediately, a kind of efficient HTTP-range-14 version) So there are a lot of options. Currently their objects are tied to an html document. What are the json crowd going to think? In any case there is a problem of translation that has to be dealt with first. Henry Social Web Architect http://bblfish.net/ -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Only personal Henry, but have you tried the Myers-Briggs thing - I think you used to be classic INTP/INTF - but once you got WebID in your sails it's very different. These things don't really allow for change. Only slightly off-topic, very relevant here, need to pin down WebID in a sense my dogs can understand. The Myers-Briggs thing is intuitively rubbish. But with only one or two posts in the ground, it does seem you can extrapolate. On 19 June 2011 19:52, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 19:44, Danny Ayers wrote: I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. I confess to talking bollocks when I should be coding. yeah, me too. Though now you folks managed to get me interested in this problem! (sigh) Henry Social Web Architect http://bblfish.net/ -- http://danny.ayers.name
Re: Fwd: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Danny Ayers wrote: I feel very guilty being in threads like this. Shit fuck smarter people than me. Just minor, and I can hardly talk as I swear most often in different settings, but I am a little surprised to see this language around here. I quite like having an arena where these words don't arise in the general conversation. Ack you know what I'm saying - nothing personal, but I'd personally appreciate not seeing them too frequently around here :) Best!
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 1:39 PM, Henry Story wrote: On 19 Jun 2011, at 14:04, Kingsley Idehen wrote: Er. we use it :-) The problem with this whole Linked Data thing is that its truly Ninja tech. The killer conductor of value is the LINK. This lethal weapon applies to all dimensions of the Web: 1. Information Space 2. Data Space 3. Knowledge Space. Trouble is, where do we find strong anecdotes for a cross dimensional lethal weapon? I try to use Stars Wars and the FORCE at times, but even that doesn't quite nail what we are dealing with here. Thus, we could take another approach i.e., embrace and extend what we know is anomalous since the AWWW architecture (FORCE) actually lets us do this anyway. That's a fun way of describing things. Fun is one mechanism for stimulating attention an route to unveiling new insights and innovations :-) But we have to be careful not to hype things too much, or we risk being tied into the 1980 AI hype space, and then nobody will listen anymore. I certainly don't have that in mind. The only tweak I would make is: s/Ninja/Jedi, since Star Wars and its underlying mythology remains a great source of anecdotal material to me when I try to explain what's happening across the WWW's many dimensions. Perhaps a more scientific way to express this is within the language of self-organising systems. Every audience might not be scientifically inclined, at least not in an obvious way. Thus, as you can see, there isn't one way. We have to find and accommodate a plethora of narratives and associated anecdotes. There is a lot of research there which is relevant to us. http://en.wikipedia.org/wiki/Self_organising_systems Nice find, that is certainly representative of what's happening. Kingsley I am a bit new to this area. Any books I must read? Henry Social Web Architect http://bblfish.net/ -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 2:26 PM, Hugh Glaser wrote: On 19 Jun 2011, at 13:04, Kingsley Idehen wrote: On 6/19/11 12:05 PM, Hugh Glaser wrote: A step too far? Hi. I've sort of been waiting for someone to say: I have a system that consumes RDF from the world out there (eg dbpedia), and it would break and be unfixable if the sources didn't do 303 or #. Plenty of people saying they can't express what they want without it. And plenty of people saying they can't write some code that they might not be able to understand some RDF they receive properly. But no actual examples in the wild (at least as far as I can tell in a lot of messages). This might be for quite a few reasons, such as: 1) There are no such consuming systems; 2) The existing consuming systems would not break. Number (1) would be too embarrassing, and is wrong because I have some, so I'll think about number (2). There seem to be some axes in the discussion: publish / consume long/medium term / shorter term ideal / pragmatic Interestingly, we don't seem to have a strong theory / practice axis, which is great. As a publisher, I/we have had to work pretty hard to conform to really quite complex requirements for publishing RDF as Linked Data; not just Range-14, but voiD, sitemaps and various bits and pieces that Kingsley always tells me to do in the RDF. As a consumer, it has been pretty simple: Well guv, thanks for the URI, here's some RDF. It has always been something of a source of angst (if not actual pain) to me that none of the extra work I put into publishing RDF is ever used by me or anyone else, as far as I know. Er. we use it :-) Er, I'm not sure you do :-) You certainly consume it, and a very nice job you do to. But the use is more than generic browsers - it suggest to me that something useful might happen as a result of the consumption (perhaps I learn that I can ask Jim to introduce me to Mary, as he knows her better than anyone else I know). Yes, and this is coming. Basically, as part of the WebID (powerful Linked Data and FOAF exploitation) Henry, I, and others are working on use of our respective efforts for semantically enhanced friending. We not only handle friending we also handle notifications such that from a single blog post, address book entry, calendar item creation of change etc., notices get progagated, but all of this is driven by a WebID (a personal URI). In addition to all of this, we have WebID based ACLs for powerful resource sharing etc.. We (at OpenLink) have even extended S/MIME with WebID which makes a world of difference re. helping folks regain control of their in-boxes and basically fixing email. These things are usually called applications, or possibly services. Yes, that's the key to the matter. Make apps that make a difference via the standards we promote. Put differently, promote our beliefs via apps that illuminate standards that be believe in and promote. They tend to be reasonably domain-specific, as generic things tend not to be easy to sue, or even fit for purpose for end users. Sorry if I have missed stuff. Address Books, Calendars, Blogs, Discussion Forums, Comments, Pingbacks, In-boxes Drop-boxes, Photo Albums, and Galleries etc.. all benefit immensely from Linked Data, we just need more applications as a few have existed in isolation for a while :-) Re. apps., one of the real problems with Linked Data is that the LINK is the key too everything. That said, when dealing with Apps., most think about UI first, and that's where matters can get confusing real fast i.e., some attempts at visualization utterly compromise Linked Data's essence. Likewise, slapping UI on to Linked Data with illuminating its essence in mind also introduces its own set of problems. [SNIP] -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 5:56 PM, Nathan wrote: Henry Story wrote: On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Sorry, I'm missing something - from what I can see, each document has a number of items, potentially in a hierarchy, and each item is either anonymous, or has an @itemid. Where's the confusion between Document and Primary Subject? Put differently, are they conflating things i.e., leaving the beholder to make the distinction outside AWWW. Yes, they are, but purely because this effort is Information Space dimension based :-) Time for a video [1]. Links: 1. http://www.youtube.com/watch?v=JkxieS-6WuA -- imaging the 10th dimension -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/19/11 6:36 PM, Henry Story wrote: On 19 Jun 2011, at 18:58, Nathan wrote: Nathan wrote: Henry Story wrote: On 19 Jun 2011, at 18:27, Giovanni Tummarello wrote: but dont be surprised as less and less people will be willing to listen as more and more applications (Eg.. all the stuff based on schema.org) pop up never knowing there was this problem... (not in general. of course there is in general, but for their specific use cases) The question is if schema.org makes the confusion, or if the schemas published there use a DocumentObject ontology where the distinctions are clear but the rule is that object relationships are in fact going via the primary topic of the document. I have not looked at the schema, but it seems that before arguing that they are inconsistent one should see if there is not a consistent interpretation of what they are doing. Sorry, I'm missing something - from what I can see, each document has a number of items, potentially in a hierarchy, and each item is either anonymous, or has an @itemid. Where's the confusion between Document and Primary Subject? Or do you mean from the Schema.org side, where each Type and Property has a dereferencable URI, which currently happens to also eb used for the document describing the Type/Property? Well I can't really tell because I don't know what the semantics of those annotations are, or how they function. Without those it is difficult to tell if they have made a mistake. If there is no way of translating what they are doing into a system that does not make the confusion, then one could explore what the cost of that will be to them. If the confusion is strong then there will be limitations in what they can express that way. It will then be a matter of working out what those limitations are and then offering services that allow one to go further than what they are proposing. At the very least the good thing is that they are not bringing the confusion into the RDF space, since they are using their own syntax and ontologies. There may also be an higher way to fix this so that they could return a 20x (x-some new number) which points to the document URL (but returns the representation immediately, a kind of efficient HTTP-range-14 version) So there are a lot of options. Currently their objects are tied to an html document. What are the json crowd going to think? Microdata as espoused by schema.org, via actual Microdata spec, includes a rules for making JSON representations. Irrespective, the conflation of entity Name and representation Address ultimately remains. But again, in the Information Space realm these ambiguities are the norm. Thus, it ultimately boils down to bridge vocabularies and ontologies to solve this problem re. Data Space dimension exploitation. Personally, I just don't loose sleep over schema.org, its a great contribution that ultimately simplifies comprehension of the Data Space dimension. Remember, we humans don't do well with prevention, we prefer cure (via pills ideally) that are immediately available once calamities manifest :-) In any case there is a problem of translation that has to be dealt with first. Yes-ish. Kingsley Henry Social Web Architect http://bblfish.net/ -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Self-star Systems (was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...] )
+1 to Netlogo! Regards, Dave On Jun 19, 2011, at 18:52, John Erickson wrote: Henry Story asked... Perhaps a more scientific way to express this is within the language of self-organising systems. There is a lot of research there which is relevant to us. http://en.wikipedia.org/wiki/Self_organising_systems I am a bit new to this area. Any books I must read? I responded to Henry personally with the following, which Henry suggested I send to the list... snip Caution: The study of self-organizing systems will keep you up all night with its coolness! ;) You asked for some book recommendations; these are a few on my shelf. I think the only required reading is Out of Control, which will blow you mind, and the rest will just complement that ;) 1. Kevin Kelly, Out of Control 2. Mikhail Prokopenko (ed), Advances in Applied Self-Organizing Systems 3. Ozalp Babaoglu, et.al., Self-star Properties in Complex Information Systems 4. Yaneer Bar-Yam, Dynamics of Complex Systems 5. Martin A. Nowak, Evolutionary Dynamics: Exploring the Equations of Life An example chapter from Nowak: Evolutionary Graph Theory ;) BTW, if you haven't already, install NetLego http://ccl.northwestern.edu/netlogo/ immediately. Serious work going on there, but very accessible! /snip -- John S. Erickson, Ph.D. http://bitwacker.com olyerick...@gmail.com Twitter: @olyerickson Skype: @olyerickson
Re: WebID and pets -- was: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 19 June 2011 20:42, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 20:15, Danny Ayers wrote: Only personal Henry, but have you tried the Myers-Briggs thing - I think you used to be classic INTP/INTF - but once you got WebID in your sails it's very different. These things don't really allow for change. Is there a page where I can find this out in one click? Looks like those pages ask all kinds of questions that require detailed and complicated answers. I am surprised anyone ever answers those things. It's certainly more complex than the Object/Document distinction ;-) Myers Briggs is based on the Jungian analysis of mythology and personality types, with a few additions. Myths being public dreams, and dreams being private myths. The personality types are the lens from which we interpret the inner and outer universal symbols. e.g. Intuitively / Analytically / Senses / Feeling. But the symbols themselves are often the more fascinating parts. An interesting parallel here is the relation to Jung's archetypes of the unconscious and WebID. Both in your dreams, and in mythology, you have symbols where are metaphors that reference some universal concept. WebID is of course a reference to the self ( foaf : Person ). As many of the myths we live with today are 100s of years out of date, and people are searching for something new, perhaps WebID can become a modern symbol, to determine or even evangelize the new personality type of society, post information revolution :) Only slightly off-topic, very relevant here, need to pin down WebID in a sense my dogs can understand. Ok. So you need to give each of your dogs and cats a webid enabled RDFID chip that can publish webids to other animals with similarly equipped chips when they sniff them. From the frequence and length of sniffs you can work out the quality of the relationships. On coming home for food, this data could be uploaded automatically to your web server to their foaf file. These relationships could then be used to allow their pals access to parts of your house. For example good friends of your dog, could get a free meal once a week. You could also use that to tie up friendship with their owners, by the master-of-pet relationships, and give them special ability to tag their pet photos. Masters of my dogs friends could be potential friends. If you get these pieces working right you could set up a business with a strong viral potential, perhaps the strongest on the net. Here to make my point: The Myers-Briggs thing is intuitively rubbish. But with only one or two posts in the ground, it does seem you can extrapolate. On 19 June 2011 19:52, Henry Story henry.st...@bblfish.net wrote: On 19 Jun 2011, at 19:44, Danny Ayers wrote: I am of the view that this has been discussed to death, and that any mailing list that discusses this is short of real things to do. I confess to talking bollocks when I should be coding. yeah, me too. Though now you folks managed to get me interested in this problem! (sigh) Henry Social Web Architect http://bblfish.net/ -- http://danny.ayers.name Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 16 June 2011 22:39, Pat Hayes pha...@ihmc.us wrote: Not only do I not follow your reasoning, I don't even know what it is you are saying. The document is a valid *representation* of the car, yes of course. That's all that's necessary to square this circle. But as valid as the car itself? So you think a car is a representation of itself? Or are you drawing a contrast between the 'named car resource' and the car itself? ??? All HTTP delivers is representations of named resources. (I very much do think a car is a representation of itself in HTTP terms, in the same way a document is, but it isn't necessary here). Maybe it would be best if we just dropped this now. I gather that you were offering me a way to make semantic sense of something, but Im not getting any sense at all out of this discussion, I am afraid. I'll be delighted to drop it, I thought we were getting stuck in a tar pit but your statement above is the er, oil, that gets us out. Cheers, Danny. -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 17 June 2011 02:46, David Booth da...@dbooth.org wrote: I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. Thanks David, a nice summary of the most important point IMHO. Ok, I've been trying to rationalize the case where there is a failure to make the distinction, but that's very much secondary to the fact that nothing really gets broken. Cheers, Danny. http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Really (sorry to keep raining on the parade, but) it is not as simple as this. Look, it is indeed easy to not bother distinguishing male from female dogs. One simply talks of dogs without mentioning gender, and there is a lot that can be said about dogs without getting into that second topic. But confusing web pages, or documents more generally, with the things the documents are about, now that does matter a lot more, simply because it is virtually impossible to say *anything* about documents-or-things without immediately being clear which of them - documents or things - one is talking about. And there is a good reason why this particular confusion is so destructive. Unlike the dogs-vs-bitches case, the difference between the document and its topic, the thing, is that one is ABOUT the other. This is not simply a matter of ignoring some potentially relevant information (the gender of the dog) because one is temporarily not concerned with it: it is two different ways of using the very names that are the fabric of the descriptive representations themselves. It confuses language with language use, confuses language with meta-language. It is like saying giraffe has seven letters rather than giraffe has seven letters. Maybe this does not break Web architecture, but it certainly breaks **semantic** architecture. It completely destroys any semantic coherence we might, in some perhaps impossibly optimistic vision of the future, manage to create within the semantic web. So yes indeed, the Web will go on happily confusing things with documents, partly because the Web really has no actual contact with things at all: it is entirely constructed from documents (in a wide sense). But the SEMANTIC Web will wither and die, or perhaps be still-born, if it cannot find some way to keep use and mention separate and coherent. So far, http-range-14 is the only viable suggestion I have seen for how to do this. If anyone has a better one, let us discuss it. But just blandly assuming that it will all come out in the wash is a bad idea. It won't. Pat On Jun 18, 2011, at 1:51 PM, Danny Ayers wrote: On 17 June 2011 02:46, David Booth da...@dbooth.org wrote: I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. Thanks David, a nice summary of the most important point IMHO. Ok, I've been trying to rationalize the case where there is a failure to make the distinction, but that's very much secondary to the fact that nothing really gets broken. Cheers, Danny. http://danny.ayers.name 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 17/06/11 01:46, David Booth wrote: I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. We've been encouraging people to do so. Most do not have the time to invest in complexity that they percieve no benefit from adding. We need to reward people for good semantics by making sure there's tools and apps which add value for their business and activities. -- Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248 / Lead Developer, EPrints Project, http://eprints.org/ / Web Projects Manager, ECS, University of Southampton, http://www.ecs.soton.ac.uk/ / Webmaster, Web Science Trust, http://www.webscience.org/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/17/11 1:46 AM, David Booth wrote: I agree with TimBL that it is*good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does*not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. Instead of *break* what about compromising or undermining flexibility implicit in AWWW? This is tantamount to obscuring the WWW potential relative to its broad user constituency. Re. schema.org, I don't regard their effort as breaking, compromising, or undermining AWWW. I simply believe they are taking baby steps that are 100% defined by their current business models. Rightly or wrongly so, they have to protect their business models. In a sense, the same applies to academia and its model where grant funding is vital to research projects. What is dangerous though, is encouraging people to misuse and misunderstand AWWW. Names and Addresses are distinct items. AWWW essence depends on preserving this vital distinction. When there are more applications (+1 to Henry's comment about focusing on Linked Data apps and viral patterns) this lower level matter will vapourize. Although not present (I am too young) I am certain similar arguments arose during the early days of silicon based computing between OS developers and programming language developers. I certainly know these conversations did arise when Spreadsheets vendors tackled Cell Reference functionality. There are many useful cases in plain sight that many overlook re. power of URIs as data conductors, integrators, and access mechanisms. I think (based on my experience with this community and industry at large) that there is too much focus on reinventing too many parts of the consumption stack, from scratch. The key is to be useful but introduce usefulness unobtrusively if you really seek uptake. Naturally, this requires understanding of what already exists (i.e., domain and subject matter knowledge) and functionality areas addressed by existing solutions. Sorry, but if all you do is program, you cannot really understand the reality of end-users. I like to make reference to Apple as a great anecdote because they've risen from near demise to the vanguard of modern computing by exploiting the InterWeb from the inside out, they don't see the Web as simply being about HTML. They understand that its a linked information space and future data space. They utilize this insight internally in a manner that just manifests as being useful to its ever growing customer base. Remember, there's a lot of old NeXTStep still underlying what Apple does. Also remember, the WWW was built on an NeXT machine with a lot of inspiration from how its innards worked. Believe it or not, we are still playing catch up (circa. 20011) with NeXTStep and Unix in general re. really smart and useful Linked Data apps :-) Embrace history and the future gets clearer and much more exciting. We have an unbelievable opportunity within grasp. We can embrace and extend (in a good way) what we may perceive as imperfections by others (e.g. schema.org). As Pat stated in an earlier post, these imperfections present opportunities that might even span decades before the behemoths out there hit their respective opportunity cost thresholds. Once said thresholds are hit they will respond accordingly via product fixes and/or enterprise acquisitions etc.. Contrary to popular belief, I will state once again that HTTP 303 is the poster child for ingenuity inherent in the HTTP protocol and the AWWW. Yes, we could also up the semantic smarts on clients and let a retrieved resource disambiguate Names and Addresses, but that only adds a burden to a target audience that's already challenged re: 1. recognizing linked data structures via directed graphs 2. recognizing that linked data structures have always been about links and that HTTP URIs are a powerful vehicle for expanding this concept to InterWeb scales 3. recognizing that de-reference (indirection) and address-of operations are achievable via URIs and cost-effectively so via HTTP URIs due to WWW ubiquity 4. understanding that RDF is *an option* for linked data structures at InterWeb scales, you can use other syntaxes without losing access to really useful stuff like RDFS and OWL semantics (which also suffers from over emphasis on RDF at expense of core syntax agnostic concepts). Links: 1. http://en.wikipedia.org/wiki/Spreadsheet#Cells 2. http://en.wikipedia.org/wiki/Spreadsheet#Named_cells . -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Danny Ayers wrote: On 16 June 2011 02:26, Pat Hayes pha...@ihmc.us wrote: If you agree with Danny that a description can be a substitute for the thing it describes, then I am waiting to hear how one of you will re-write classical model theory to accommodate this classical use/mention error. You might want to start by reading Korzybski's 'General Semantics'. IANAL, but I have heard of the use/mention thing, quite often. I don't honestly know whether classical model theory needs a rewrite, but I'm sure it doesn't on the basis of this thread. I also don't know enough to know whether it's applicable - from your reaction, I suspect not. As a publisher of information on the Web, I'm pretty much free to say what I like (cf. Tim's Design Notes). Fish are bicycles. But that isn't very useful. But if I say Sasha is some kind of weird Collie-German Shepherd cross, that has direct relevance to Sasha herself. More, the arcs in my description between Sasha and her parents have direct correspondence with the arcs between Sasha and her parents. There is information common to the reality and the description (at least in human terms). The description may, when you stand back, be very different in its nature to the reality, but if you wish to make use of the information, such common aspects are valuable. We've already established that HTTP doesn't deal with any kind of one true representation. Data about Sasha's parentage isn't Sasha, but it's closer than a non-committal 303 or rdfs:seeAlso. There's nothing around HTTP that says it can't be given the same name, and it's a darn sight more useful than a wave-over-there redirect or a random fish/bike association. I can't see anything it breaks either. You could use the same name for both if each name was always coupled to a universe, specified by the predicate, and you cut out type information from data, such that: x-sasha :animalname sasha ; :created 2011 . was read as: Animal(x-sasha) :animalname sasha . Document(x-sasha) :created 2011 . the ability to do this could be pushed on to ontologies, with domain and range and restrictions specifying universes and boundaries - but it's a big change. really, different names for different things is quite simple to stick to, and considering most (virtually all) documents on the web have several different elements and identifiable things, the one page one subject thing isn't worth spending too much time focusing on as a generic use case, as any solution based on it won't apply to the web at large which is very diverse and packed full of lots of potentially identifiable things. best, nathan
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Alan Ruttenberg wrote: Pat's knows something about the history of what's known to work and what isn't. You ignore that history at the peril of your ideas simply not working. well said, although I think we could bracket yourself in that category too :)
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 17 Jun 2011, at 22:42, Nathan wrote: You could use the same name for both if each name was always coupled to a universe, specified by the predicate, and you cut out type information from data, such that: x-sasha :animalname sasha ; :created 2011 . was read as: Animal(x-sasha) :animalname sasha . Document(x-sasha) :created 2011 . the ability to do this could be pushed on to ontologies, with domain and range and restrictions specifying universes and boundaries - but it's a big change. No its quite simple in fact, as I pointed out in a couple of e-mails in this thread. You just need to be careful when creating relations that certain relations are in fact inferred relations between primary topics. really, different names for different things is quite simple to stick to, yes, but there are a lot of people who say it is too complicated. I don't find it so, but perhaps it is for their use cases. I say that we describe the option they like, find out what the limitations are they will fall have, and document it. Then next time we can refer others to that discovery. So limitations to look for would be limitations as to the complexity of the data created. The other limitations is that even on simple blog pages there are at least three or four things on the page. and considering most (virtually all) documents on the web have several different elements and identifiable things, indeed. the one page one subject thing isn't worth spending too much time focusing on as a generic use case, as any solution based on it won't apply to the web at large which is very diverse and packed full of lots of potentially identifiable things. agree. But it is one of those things that newbies feel the urge to do, and will keep on wanting to do. So perhaps for them one should have special simple ontologies or guides for how to build these ObjectDocument ontologies. In any case this seems to be the type of thing the microformats people were (are?) doing. Henry best, nathan Social Web Architect http://bblfish.net/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Henry Story wrote: On 17 Jun 2011, at 22:42, Nathan wrote: You could use the same name for both if each name was always coupled to a universe, specified by the predicate, and you cut out type information from data, such that: x-sasha :animalname sasha ; :created 2011 . was read as: Animal(x-sasha) :animalname sasha . Document(x-sasha) :created 2011 . the ability to do this could be pushed on to ontologies, with domain and range and restrictions specifying universes and boundaries - but it's a big change. No its quite simple in fact, as I pointed out in a couple of e-mails in this thread. You just need to be careful when creating relations that certain relations are in fact inferred relations between primary topics. I'd agree, but anything that involves being careful is pretty much doomed to failure on the web :p really, different names for different things is quite simple to stick to, yes, but there are a lot of people who say it is too complicated. I don't find it so, but perhaps it is for their use cases. I say that we describe the option they like, find out what the limitations are they will fall have, and document it. Then next time we can refer others to that discovery. So limitations to look for would be limitations as to the complexity of the data created. The other limitations is that even on simple blog pages there are at least three or four things on the page. there's also a primary limitation of the programming languages developers are using, if they've got locked in stone classes and objects, or even just structures, then the dynamics of RDF can be pretty hard to both understand mentally, and use practically. and considering most (virtually all) documents on the web have several different elements and identifiable things, indeed. the one page one subject thing isn't worth spending too much time focusing on as a generic use case, as any solution based on it won't apply to the web at large which is very diverse and packed full of lots of potentially identifiable things. agree. But it is one of those things that newbies feel the urge to do, and will keep on wanting to do. So perhaps for them one should have special simple ontologies or guides for how to build these ObjectDocument ontologies. In any case this seems to be the type of thing the microformats people were (are?) doing. hmm.. microformats seems to be pretty focussed on describing multiple items on one page, however the singularity is present in that they focussed on being described using a single Class Blueprint style, one class, a predetermined set of properties belonging to the class, and a simple chained heirarchy - this stems from most OO based languages. With a bit of trickery you can use RDF and OWL the same way, it just means you have different views over the data, where you can see Human(x) with a set of properties, or Male(x) with another set, or Administrator(x) with yet another set. This is less about the data published and more about how it's consumed viewed and processed though. Quite sure something can be done with that, where the simple version of the data uses a basic schema.org like ontology, and advanced usage is more RDF like using multiple ontologies. The views thing would be a way to merge the two approaches.. Best, Nathan
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Wed, Jun 15, 2011 at 6:24 AM, Richard Cyganiak rich...@cyganiak.dewrote: On 15 Jun 2011, at 01:07, Alan Ruttenberg wrote: Google won't scrap schema.org because your thought experiment proved that it's not “semantically clear.” Richard, that wasn't the point. You mocked the idea that semantically clear could be defined. I responded with an attempt. I have no interest in theoretical discussions that are detached from application. I assume you mean you are not interested in discussions of theory that are detached from application. In any case this is a non-sequitor. The definition is offered because some, including myself, think that there are important classes of applications for which it is an essential ingredient of success (like some of the ones I need to build), and because you implied that defining what we meant was not feasible. I think that we are beyond the point where that kind of extremely idealised account is useful for evaluating web technologies. We will agree to disagree then. Perhaps in another thread you will say what *will* be useful for evaluating web technologies. Adoption trends, ergonomics, fit with the existing technology ecosystem, existence of migration paths, marketability, potential of network effects. Does what the technology *accomplishes* fit in there somewhere? Looking at the above, one might conclude that a successful Ponzi scheme of some sort would score well. Regards, Alan
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 16 Jun 2011, at 07:05, Alan Ruttenberg wrote: I think that we are beyond the point where that kind of extremely idealised account is useful for evaluating web technologies. We will agree to disagree then. Perhaps in another thread you will say what *will* be useful for evaluating web technologies. Adoption trends, ergonomics, fit with the existing technology ecosystem, existence of migration paths, marketability, potential of network effects. Does what the technology *accomplishes* fit in there somewhere? Web technologies are never about accomplishing anything new; they are about taking something that already works on a small and local scale, and making it work across the internet with its loosely coordinated actors. Looking at the above, one might conclude that a successful Ponzi scheme of some sort would score well. :-) If you want to look at it that way, standards, like anything that exhibits network effects, are a bit like a ponzi scheme: once you're inside, you benefit from getting others in your vicinity on board. The difference is that “late adopters” in a ponzi scheme are the suckers who lose their investment; while late adopters of a standard get the largest benefit at the smallest cost. Best, Richard
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 15, 2011, at 7:36 PM, Danny Ayers wrote: On 15 June 2011 18:30, Pat Hayes pha...@ihmc.us wrote: Boy, that is a humdinger of a non-sequiteur. Given that HTTP has flexibility, it is OK to identify a description of a thing with the actual thing? To me that sounds like saying, given that movies are projected, it is OK to say that fish are bicycles. Not that I think I did a non-sequiteur, it is totally ok to say that fish are bicycles, if that's what you want to say. [snip] OK, thanks. Here is your argument, as far as I can understand it. 1. HTTP representations may be partial or incomplete. (Agreed.) 2. HTTP reps can have many different media types, and this is OK. (Agreed, though I cant see what relevance this has to anything.) 3. A description is a kind of representation. (Agreed, and there was no need to get into the 'isomorphism' trap. We in KRep have been calling descriptions representations for decades now.) 4. Therefore, a HTTP URI can simultaneously be understood as referring to a document and a car. Whaaat? How in Gods name can you derive this conclusion from those premises? my wording could be better, but I stand by it... a document describing the car, through HTTP, can be an equally valid representation of the named car resource as the car itself (as long as it's qualified by media type) Not only do I not follow your reasoning, I don't even know what it is you are saying. The document is a valid *representation* of the car, yes of course. But as valid as the car itself? So you think a car is a representation of itself? Or are you drawing a contrast between the 'named car resource' and the car itself? ??? Maybe it would be best if we just dropped this now. I gather that you were offering me a way to make semantic sense of something, but Im not getting any sense at all out of this discussion, I am afraid. Pat Cheers, Danny. -- http://danny.ayers.name 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 15, 2011, at 8:27 PM, Danny Ayers wrote: On 16 June 2011 02:26, Pat Hayes pha...@ihmc.us wrote: If you agree with Danny that a description can be a substitute for the thing it describes, then I am waiting to hear how one of you will re-write classical model theory to accommodate this classical use/mention error. You might want to start by reading Korzybski's 'General Semantics'. IANAL, but I have heard of the use/mention thing, quite often. I don't honestly know whether classical model theory needs a rewrite, but I'm sure it doesn't on the basis of this thread. I also don't know enough to know whether it's applicable - from your reaction, I suspect not. As a publisher of information on the Web, I'm pretty much free to say what I like (cf. Tim's Design Notes). Fish are bicycles. But that isn't very useful. But if I say Sasha is some kind of weird Collie-German Shepherd cross, that has direct relevance to Sasha herself. True. More, the arcs in my description between Sasha and her parents Sasha and her parents are not themselves in your description. I presume you mean, the arcs between the terms you use, in your description, to refer to Sasha and her parents. have direct correspondence with the arcs between Sasha and her parents. Sasha and her parents don't have arcs between them (unless you are indulging in some cruel treatment of animals.) I presume you mean to refer to certain relationships which hold between Sasha and her parents. In this simple case (explicitly named relationships, explicit referring names) there is a kind of structural correspondence between the description and the reality, indeed. But as soon as you make the descriptive language even slightly more expressive, this breaks down. (Try adding negation or disjunction of even blank nodes.) And as soon as you admit that reality is more complex than any description of it, it breaks down. So its not a very good foundation to build a semantic theory upon. There is information common to the reality and the description (at least in human terms). No. The reality is what it is; the information is held in the description (the one with the arcs and the names in it.) The information is ABOUT Sash and her parents (and the relationship of parenthood and various categories of doggitude, and so forth.) The description may, when you stand back, be very different in its nature to the reality, You betcha. but if you wish to make use of the information, such common aspects are valuable. What common aspects? If you mean to refer to the fact that a description with arcs and names can be TRUE OF some aspect of reality, you are talking about classical model-theoretic semantics, which is based on the idea of reference (AKA denotation) at its root; it is the interpretation mapping from names to the things they are interpreted to refer to (eg between Sasha and Sasha.) But the truth-in-an-interpretation relationship is not similarity or isomorphism, and it certainly does not warrant identifying the name with the thing named. Quite the contrary, it relies upon keeping this distinction clear. As Korzybski famously said, the map is not the territory. We've already established that HTTP doesn't deal with any kind of one true representation. Data about Sasha's parentage isn't Sasha, but it's closer than a non-committal 303 or rdfs:seeAlso. Closer? In what metric? I would say it is about as different as anything can get. There's nothing around HTTP that says it can't be given the same name, and it's a darn sight more useful than a wave-over-there redirect or a random fish/bike association. I can't see anything it breaks either. OF COURSE it breaks things. It might be true to say that Sasha is a Collie-German Shepherd cross, but Sasha's description or web page certainly isn't. It might be true to say that the description is written in RDF, but Sasha isn't. Pat Cheers, Danny. -- http://danny.ayers.name 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 15, 2011, at 10:04 PM, Jason Borro wrote: Apologies if my keyboard sneered at you, though comparing an application problem to 1% of hr14 at web scale hardly trivializes it; certainly it does the opposite. Good luck preserving your mental model if you require webmasters to spell Korzybski. I'd prefer they actually read him, though I won't hold my breath. Sorry to bother you by using a very long foreign name. Pat On 6/15/2011 6:26 PM, Pat Hayes wrote: On Jun 15, 2011, at 1:35 PM, Jason Borro wrote: I agree with your sentiments Danny, fwiw. The current scheme is a burden on publishers for the sake of a handful of applications that wish to refer to these information resources themselves, making them unable to talk about Web pages using the Web description language RDF. What about minting a new URI at http://information.resourcifier.net/encodedURI; or similar for talking about such things? The service could even add value by tracking last update times, content types, encodings, etc. Jason p.s. Don't bother criticizing the half baked idea, I thought about it for 10 seconds. The point is 100 alternatives could have been hashed out in the time spent discussing and implementing http-range-14. I confess to finding this kind of sneering remark rather annoying. If you think it is this trivial to work out some 'alternative', why don't you come up with a few actual ideas and see what happens when they get a little peer review? Your idea, above, hardly makes first base, as Im sure you already realized when you added the p.s. So why not try inventing one that has a snowballs chance in hell of actually working? Im sure that the world would be delighted if you could solve this trivial problem in 5 ways, let alone a hundred. If you agree with Danny that a description can be a substitute for the thing it describes, then I am waiting to hear how one of you will re-write classical model theory to accommodate this classical use/mention error. You might want to start by reading Korzybski's 'General Semantics'. Pat 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 16, 2011, at 4:38 AM, Richard Cyganiak wrote: On 16 Jun 2011, at 07:05, Alan Ruttenberg wrote: I think that we are beyond the point where that kind of extremely idealised account is useful for evaluating web technologies. We will agree to disagree then. Perhaps in another thread you will say what *will* be useful for evaluating web technologies. Adoption trends, ergonomics, fit with the existing technology ecosystem, existence of migration paths, marketability, potential of network effects. Does what the technology *accomplishes* fit in there somewhere? Web technologies are never about accomplishing anything new; they are about taking something that already works on a small and local scale, and making it work across the internet with its loosely coordinated actors. Looking at the above, one might conclude that a successful Ponzi scheme of some sort would score well. :-) If you want to look at it that way, standards, like anything that exhibits network effects, are a bit like a ponzi scheme: once you're inside, you benefit from getting others in your vicinity on board. The difference is that “late adopters” in a ponzi scheme are the suckers who lose their investment; while late adopters of a standard get the largest benefit at the smallest cost. LOL Pat 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Thu, 2011-06-16 at 16:38 -0500, Pat Hayes wrote: On Jun 15, 2011, at 8:27 PM, Danny Ayers wrote: [ . . . ] There's nothing around HTTP that says it can't be given the same name, and it's a darn sight more useful than a wave-over-there redirect or a random fish/bike association. I can't see anything it breaks either. OF COURSE it breaks things. It might be true to say that Sasha is a Collie-German Shepherd cross, but Sasha's description or web page certainly isn't. It might be true to say that the description is written in RDF, but Sasha isn't. Let's go further and clarify exactly what breaks: Using the same URI both for Sasha and Sasha's web page breaks *some* applications and not others. Applications that need to distinguish between dogs and web pages will find the URI ambiguous; applications that do not will be perfectly happy. This state of affairs is a universal fact of life that is true of *all* possible distinctions that may be made, regardless of whether the distinction is between web pages and dogs, or between different kinds of dogs, or between different kinds of proteins or anything else. Except in the absurdly reductionist sense that *every* URI is ambiguous (because finer distinctions can always be made), whether a URI is ambiguous or unambiguous is *not* a fundamental property of the URI: ambiguity is relative to the *application* that is using that URI. Given this fact of life, I maintain that permitting the same URI to denote both a web page and a dog does *not* break the architecture of the web. I agree with TimBL that this is a design choice about the architecture of the web, and a clean, extensible architecture is needed. I agree with TimBL that 303 (and hash URIs) are useful for those who *choose* to distinguish between the web page and something else. I agree with TimBL that the httpRange-14 rule is very useful, even if it was not ideally stated, and should *not* be abandoned. However, the major flaw lies not in the httpRange-14 rule itself, but in the associated assumption that a URI cannot sensibly denote both an information resource and a dog: http://www.w3.org/TR/webarch/#def-information-resource This assumption is fatally flawed because: (a) it attempts to make an IR/non-IR distinction that can never be nailed down precisely (as several people have pointed out); and (b) it unnecessarily elevates one particular axis of ambiguity over all others. It is analogous to a rule that says all URIs for dogs MUST distinguish between male dogs and female dogs: the only applications that break without this rule are the ones that *need* to distinguish between male dogs and female dogs. All other applications will continue to work just fine without it. And that is exactly the way it should be for *any* axis of ambiguity. I agree with TimBL that it is *good* to distinguish between web pages and dogs -- and we should encourage folks to do so -- because doing so *does* help applications that need this distinction. But the failure to make this distinction does *not* break the web architecture any more than a failure to distinguish between male dogs and female dogs. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 13 June 2011 07:52, Pat Hayes pha...@ihmc.us wrote: OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.) Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, thereby excluding a whole lot of things, such as dogs, from being the referent in such cases. Even with information resources there's a lot of flexibility in what HTTP can legitimately respond with, there needn't be bitwise identity across representations of an identified resource. Given this, I'm proposing a description can be considered a good-enough substitute for an identified thing. Bearing in mind it's entirely up to the publisher if they wish to conflate things, and up to the consumer to try and make sense of it. As a last attempt - this is a tar pit! - doing my best to take on board your (and other's) comments, I've wrapped up my claims in a blog post: http://dannyayers.com/2011/06/15/httpRange-14-Reflux Cheers, Danny. -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
I agree with your sentiments Danny, fwiw. The current scheme is a burden on publishers for the sake of a handful of applications that wish to refer to these information resources themselves, making them unable to talk about Web pages using the Web description language RDF. What about minting a new URI at http://information.resourcifier.net/encodedURI; or similar for talking about such things? The service could even add value by tracking last update times, content types, encodings, etc. Jason p.s. Don't bother criticizing the half baked idea, I thought about it for 10 seconds. The point is 100 alternatives could have been hashed out in the time spent discussing and implementing http-range-14. Kudos to google et al for ignoring it. On 6/15/2011 9:27 AM, Danny Ayers wrote: On 13 June 2011 07:52, Pat Hayespha...@ihmc.us wrote: OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.) Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, thereby excluding a whole lot of things, such as dogs, from being the referent in such cases. Even with information resources there's a lot of flexibility in what HTTP can legitimately respond with, there needn't be bitwise identity across representations of an identified resource. Given this, I'm proposing a description can be considered a good-enough substitute for an identified thing. Bearing in mind it's entirely up to the publisher if they wish to conflate things, and up to the consumer to try and make sense of it. As a last attempt - this is a tar pit! - doing my best to take on board your (and other's) comments, I've wrapped up my claims in a blog post: http://dannyayers.com/2011/06/15/httpRange-14-Reflux Cheers, Danny.
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
* [2011-06-14 08:55:09 -0700] Pat Hayes pha...@ihmc.us écrit: ] Well, you have got me confused. Are you saying here that it does ] in fact make sense to say that a description of the eiffel tower ] is 356M tall? I'm just saying that things like this will be published because the publisher is confused, or mistaken or doesn't think that making the distinction is important or convenient and consumers of the data have to deal with it. We should encourage the publishers to do a better job but some of them will balk and sometimes, like with the schema.org that started this thread, big, important publishers with a lot of influence will balk. If we're lucky we can convince them to fix it, otherwise writers of software that consumes the data and tries to reason with it have to work out a way to be robust in the face of this kind of ambiguity. That's all. -w -- William Waitesmailto:w...@styx.org http://river.styx.org/ww/sip:w...@styx.org F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/15/11 4:27 PM, Danny Ayers wrote: On 13 June 2011 07:52, Pat Hayespha...@ihmc.us wrote: OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.) Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, thereby excluding a whole lot of things, such as dogs, from being the referent in such cases. Even with information resources there's a lot of flexibility in what HTTP can legitimately respond with, there needn't be bitwise identity across representations of an identified resource. Given this, I'm proposing a description can be considered a good-enough substitute for an identified thing. Bearing in mind it's entirely up to the publisher if they wish to conflate things, and up to the consumer to try and make sense of it. As a last attempt - this is a tar pit! - doing my best to take on board your (and other's) comments, I've wrapped up my claims in a blog post: http://dannyayers.com/2011/06/15/httpRange-14-Reflux Cheers, Danny. Danny, This is part of the problem: TBL's argument: the HTTP URIs (without #) should be understood as referring to documents, not cars. It assumes that the audience doesn't have a clue, so the description has to be so condescending albeit inadvertent. How about: TBL's argument: the HTTP URIs (without #) should be understood as referring to an Address. A Data Source Name. What data publisher provides to user agents for accessing specific data in a given format, courtesy of content negotiation or lack thereof etc.. The confusion is a self inflicted one courtesy of narrative style and tone, methinks. URIs abstract Names and Addresses. This whole thing isn't unlike DNS. Points of presence on TCP/IP networks have NIC addresses and cnames, courtesy of DNS. Spreadsheets have offered cell addresses and cell names since forever. Programmers have worked with de-reference (indirection) and address-of operators forever. Most of the time when they encounter the: ... is a document, not cars ... style narrative, its throws them for a loop! As you know, a Document == Data Container that's projected to users via user agents (typically browsers) using a specific presentation oriented metaphor. Using 303 to deliver indirection is an accurate reflection of the required heuristic for implementing de-reference (indirection) via HTTP URI based Names. Otherwise, use a # terminated URI and get similar (but ultimately limited) effects without an actual 303. Web users started off using Addresses as Names for Resources (Web Docs). Now we're introducing a new abstraction where Name and Address are Distinct (i.e., we have Named Objects and Object Representation Addresses, interwoven), thus we need to find a variety of ways to explain and demonstrate this new abstraction generally known as Linked Data. One size never fits all, and http-range-14 is certainly not going to be the narrative that breaks that age-old mold :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 15, 2011, at 1:35 PM, Jason Borro wrote: I agree with your sentiments Danny, fwiw. The current scheme is a burden on publishers for the sake of a handful of applications that wish to refer to these information resources themselves, making them unable to talk about Web pages using the Web description language RDF. What about minting a new URI at http://information.resourcifier.net/encodedURI; or similar for talking about such things? The service could even add value by tracking last update times, content types, encodings, etc. Jason p.s. Don't bother criticizing the half baked idea, I thought about it for 10 seconds. The point is 100 alternatives could have been hashed out in the time spent discussing and implementing http-range-14. I confess to finding this kind of sneering remark rather annoying. If you think it is this trivial to work out some 'alternative', why don't you come up with a few actual ideas and see what happens when they get a little peer review? Your idea, above, hardly makes first base, as Im sure you already realized when you added the p.s. So why not try inventing one that has a snowballs chance in hell of actually working? Im sure that the world would be delighted if you could solve this trivial problem in 5 ways, let alone a hundred. If you agree with Danny that a description can be a substitute for the thing it describes, then I am waiting to hear how one of you will re-write classical model theory to accommodate this classical use/mention error. You might want to start by reading Korzybski's 'General Semantics'. Pat Kudos to google et al for ignoring it. On 6/15/2011 9:27 AM, Danny Ayers wrote: On 13 June 2011 07:52, Pat Hayespha...@ihmc.us wrote: OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.) Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, thereby excluding a whole lot of things, such as dogs, from being the referent in such cases. Even with information resources there's a lot of flexibility in what HTTP can legitimately respond with, there needn't be bitwise identity across representations of an identified resource. Given this, I'm proposing a description can be considered a good-enough substitute for an identified thing. Bearing in mind it's entirely up to the publisher if they wish to conflate things, and up to the consumer to try and make sense of it. As a last attempt - this is a tar pit! - doing my best to take on board your (and other's) comments, I've wrapped up my claims in a blog post: http://dannyayers.com/2011/06/15/httpRange-14-Reflux Cheers, Danny. 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 15 June 2011 18:30, Pat Hayes pha...@ihmc.us wrote: Boy, that is a humdinger of a non-sequiteur. Given that HTTP has flexibility, it is OK to identify a description of a thing with the actual thing? To me that sounds like saying, given that movies are projected, it is OK to say that fish are bicycles. Not that I think I did a non-sequiteur, it is totally ok to say that fish are bicycles, if that's what you want to say. [snip] OK, thanks. Here is your argument, as far as I can understand it. 1. HTTP representations may be partial or incomplete. (Agreed.) 2. HTTP reps can have many different media types, and this is OK. (Agreed, though I cant see what relevance this has to anything.) 3. A description is a kind of representation. (Agreed, and there was no need to get into the 'isomorphism' trap. We in KRep have been calling descriptions representations for decades now.) 4. Therefore, a HTTP URI can simultaneously be understood as referring to a document and a car. Whaaat? How in Gods name can you derive this conclusion from those premises? my wording could be better, but I stand by it... a document describing the car, through HTTP, can be an equally valid representation of the named car resource as the car itself (as long as it's qualified by media type) Cheers, Danny. -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 16 June 2011 02:26, Pat Hayes pha...@ihmc.us wrote: If you agree with Danny that a description can be a substitute for the thing it describes, then I am waiting to hear how one of you will re-write classical model theory to accommodate this classical use/mention error. You might want to start by reading Korzybski's 'General Semantics'. IANAL, but I have heard of the use/mention thing, quite often. I don't honestly know whether classical model theory needs a rewrite, but I'm sure it doesn't on the basis of this thread. I also don't know enough to know whether it's applicable - from your reaction, I suspect not. As a publisher of information on the Web, I'm pretty much free to say what I like (cf. Tim's Design Notes). Fish are bicycles. But that isn't very useful. But if I say Sasha is some kind of weird Collie-German Shepherd cross, that has direct relevance to Sasha herself. More, the arcs in my description between Sasha and her parents have direct correspondence with the arcs between Sasha and her parents. There is information common to the reality and the description (at least in human terms). The description may, when you stand back, be very different in its nature to the reality, but if you wish to make use of the information, such common aspects are valuable. We've already established that HTTP doesn't deal with any kind of one true representation. Data about Sasha's parentage isn't Sasha, but it's closer than a non-committal 303 or rdfs:seeAlso. There's nothing around HTTP that says it can't be given the same name, and it's a darn sight more useful than a wave-over-there redirect or a random fish/bike association. I can't see anything it breaks either. Cheers, Danny. -- http://danny.ayers.name
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Wed, Jun 15, 2011 at 11:04 PM, Jason Borro ja...@openguid.net wrote: Good luck preserving your mental model if you require webmasters to spell Korzybski. This is an odd comment. It's like saying good luck preserving your model of TCP if you require network developers to know where Postel worked. TCP has to work, whether or not webmasters know the intellectual history its development, and the same will be true of whatever eventually becomes what the semweb ideas are aiming at. Pat's knows something about the history of what's known to work and what isn't. You ignore that history at the peril of your ideas simply not working. -Alan
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
re On Mon, Jun 13, 2011 at 08:33:47PM -0700, Pat Hayes wrote: But if you are a semantic inference engine, and you get the dog and its picture muddled, will you likely generate a lot of nonsensical assertions? Answer, Yes, you will. Which is the key point at issue here. We should be able to present the user a lot of sensical assertions (and maybe some nonsensical ones) if we know he is concerned with information about dogs instead of information about pictures. Anyway - I think special purpose reasoners will play a much bigger role in the near future than general purpose reasoners because they perform better with big and messy data. And publishers will start to differenciate between dogs and pictures of dogs as soon as it provides them added value. Until that day, we will have to live with the situation and try to nudge people in the right direction (which includes httprange-14). But mass adoption means messy data in any case. Regards, Michael Brunnbauer -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail bru...@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: Schema.org in RDF ...
On Sun, 2011-06-12 at 05:51 -0400, Alan Ruttenberg wrote: David, as you know, it is trivial to distinguish in representation the difference between an information object and a person. Correct. And that distinction is important to some apps and not to others. I am glad we agree. We also agree that what is important is not germane to the technical question of whether ambiguity is necessary, I hope. I don't know what you mean by that. It is trivial to say that foaf:Person owl:disjointWith foaf:Document or some such thing, which is what I thought you meant in your comment above. And it is trivial for *some* people to arrange for their URIs to return 303 redirects. But we have seen from experience that it is *not* trivial for others to do so, and it certainly has not been trivial to convince the less pedantic practitioners of the need to do so. And applications certainly are germane to the issue of ambiguity, because applications drive the modeling choices that we make in defining our resources. I don't understand why you keep repeating this misinformation. Huh??? That's a rather rude accusation. What misinformation do you mean? Please be more specific. A comment is posted that raises a specific form of ambiguity. Your response is that ambiguity is inevitable. Yet we agree that in this case(and in other specific cases in which you have responded with this flavor of comment) it is trivial to avoid. So your response is at best misleading or non-sequitor. You are missing the point. Sure, any *specific* ambiguity can be avoided. For *any* particular ambiguity it is possible to define our classes in a way to avoid that *particular* kind of ambiguity. But if you focus only on fixing each particular ambiguity you'll miss the forest for the trees. It is *fallacious* to think that the ambiguity problem in general can be solved by getting people to fix their data to be unambiguous, because: (a) different applications have different needs; (b) the number of potential ambiguities is *endless*; and (c) there is a cost involved in unnecessary disambiguation. In fact, in the httpRange-14 case that schema.org raises, that cost is so significant that many intelligent people have chosen *not* to disambiguate between the web page and the thing that it describes. The reality is that we *must* learn to deal with ambiguity, and this is merely one example of it. I do not think it is at all misleading to point out the larger issue that underlies this specific case. On the contrary, I think it would be misleading to ignore it. I'm sorry if my response came off as rude, however I am concerned that there be clarity in these conversations as the outcomes may turn out to be important. Apology gratefully accepted, and I agree clarity in these conversations is important -- but also difficult to achieve, as ambiguities keep sneaking in. :) -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: Schema.org in RDF ...
On 13 Jun 2011, at 00:20, Pat Hayes wrote: What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals). Of course. But you didn't, did you? You (that is, Schema.org) said that the range of the property was one of these and NOT the other. Which is what I was complaining about. Where is it said that the range is one and not the other? Well, if you say the range is xsd:string, then anything which is a value has to be a string, right? As for example (taken at random) schema:cookingMethod a rdf:Property; rdfs:label Cooking Method@en; rdfs:comment The method of cooking, such as Frying, Steaming, ...@en; rdfs:domain schema:Recipe; rdfs:range xsd:string; rdfs:isDefinedBy http://schema.org/Recipe; This says that the range is xsd:string, so nothing other than an xsd string will be acceptable here. Am I missing something? You keep switching topics. Read the conversation quoted above. You talked about properties where the range is supposed to be people, but you want to use a string. I said: No problem, we didn't say that schema:Person is disjoint from strings. Now you're talking about properties where the range is supposed to be strings, but you want to use ... people? That's a different case. The reason why we're having this conversation is this interesting quote from [1]: “We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of some data is better than none, we will accept this markup and do the best we can.” This is about the first case (string instead of thing) and not about the second (thing instead of string). The first case is immensely important, because publishers may have insufficient data or motivation to provide a structured value (e.g., schema:Person with its various properties), and therefore have to choose between just providing a simple string value (e.g., the person's name) or not using the property at all. The second case is of much less immediate concern. It occurs when some data publisher is not content with simply providing a string value that Google understands, but wants to provide a complex description with more detail than the schema.org terms provide. The answer to that is, keep using the schema.org property with a simple string value, and define an extension to the vocabulary. Best, Richard [1] http://schema.org/docs/datamodel.html
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/13/11 1:28 AM, Pat Hayes wrote: But I don't think all this is really germane to the http-range-14 issue. The point there is, does the URI refer to something like a representation (information resource, website, document, RDF graph, whatever) or something which definitely canNOT be sent over a wire? The Referent of a URI re., http-range-14 is the observation (or description) subject. In this context the subject may or may not be a real world object or entity. In the context of Linked Data, the observation (or description) subject URI resolves to a Representation of its Referent. Actual representation is accessible via an Address. Data representation formats are *optionally* negotiable e.g., via content negotiation, and ultimately varied i.e., many serialization formats for byte stream that actually transmits data from its source to its consumers. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 6/13/11 6:52 AM, Pat Hayes wrote: OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.) Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. No, 200 OK means this URI is functionally an Address i.e., a place that's ready to transmit the byte stream associated with the Address. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. When the functionality of the URI changes i.e., its a Name rather than an Address, courtesy of de-reference (indirection), there is a 303 redirect (an act of indirection). It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, Yes, a data server indicates to a client that a given Address is functional i.e., I'll transmit you a byte stream from this place which I crafted for this specific purpose. thereby excluding a whole lot of things, such as dogs, from being the referent in such cases. Yes, if the response is 200 OK since the URI is an Address. No if the response is a 303 since the URI is a Name. It still boils down to the URI abstraction which ingeniously caters for two vital data access by reference operations: Name (for de-reference and indirection) and Address (for Data Access). Kingsley Pat On Jun 12, 2011, at 6:46 PM, Danny Ayers wrote: On 13 June 2011 02:28, Pat Hayespha...@ihmc.us wrote: Next point: there can indeed be correspondences between the syntactic structure of a description and the aspects of reality it describes. That is what I was calling isomorphism (which I still don't think was inaccurate). But ok, say there are correspondences instead. I would suggest that those correspondences are enough to allow the description to take the place of a representation under HTTP definitions. But I don't think all this is really germane to the http-range-14 issue. The point there is, does the URI refer to something like a representation (information resource, website, document, RDF graph, whatever) or something which definitely canNOT be sent over a wire? I'm saying conceptually it doesn't matter if you can put it over the wire or not. But replace a novel written by a dog for dog in the above. Why should the concept of a document be fundamentally any different from the concept of a dog, hence representations of a document and representations of a dog? I dont follow your point here. If you mean, a document is just as real as a dog, I agree. So? But if you mean, there is no basic difference between a document and a dog, I disagree. And so does my cat. Difference sure, but not necessarily relevant. Ok, you can squeeze something over the wire that represents a novel written by a dog but you (probably) can't squeeze a dog over, but that's just a limitation of the protocol. So improved software engineering will enable us to teleport dogs over the internet? Come on, you don't actually believe this. It would save a lot of effort sometimes (walkies!) but all I'm suggesting is that if, hypothetically, you could teleport matter over the internet, all you'd be looking at as far as http-range-14 is concerned is another media type. Working back from there, and given correspondences as above, a descriptive document can be a valid representation of the identified resource even if it happens to be an actual thing, given that there isn't necessary any one true representation. We don't need the Information Resource distinction here (useful elsewhere maybe). Cheers, Danny. -- http://danny.ayers.name 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 -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
Before I comment, I just want to summarise my understanding because http-range-14 is a weird term; I understand it as the range-14 issue that when you use 302 to redirect from a URI-A to a URL-B we have a convention that URL-B has some relationship to URI-A but it's not defined, we don't treat this as semantic information and tend to throw it away. (stated to make sure I've understood correctly) This bit a chap working with some of my data; * he loaded some data from URI-A using a library * URI-A did a nice content-negotiated 302 to URL-B (and RDF document) * URL-B had a description of URI-A * The problem was he also wanted to auto extract the license for this data, but the triples gave the license as a relation to URL-B, but the system treated the data as loaded from URI-A At the most simple level, we could add some triples when loading a graph via redirection... URI-A myprefix:http302redirect URL-B or something richer with dates, http options etc. You could do something even fussier with http headers stating an explicit relationship with the 302, but all of this is very nice but the main problem seems to be that it's hard and doesn't benefit someone who just wants to knock something up quickly. The real problem seems to me that making resolvable, HTTP URIs for real world things was a clever but dirty hack and does not make any semantic sense. We should use thing://data.totl.net/scooby to refer to the dog and have a convention that http://data.totl.net/scooby will refer to some content about my dog. This URL can of course then content negotiate as normal. You could also use this in reverse. *thing*://www.imdb.com/title/tt0910554/ is the primary topic of http://www.imdb.com/title/tt0910554/ Yes, you could end up with a whole bunch of URIs for the same thing; thing://data.totl.net/scooby thing://data.totl.net/scooby.html thing://data.totl.net/scooby.pdf thing://data.totl.net/scooby.csv all are the same thing, but big deal. The only tricky thing would be people may get confused about the thing URI related to a document. For example, given a document in pdf, word and html, you might need a separate thing:// URI to describe the abstract concept of the document, but that's not the primary topic of any of the documents. Such fiddling details are more the province of people with experience, so I'm not too worried. What we should be doing is making the common garden data really easy to produce. I've spent a lot of time trying to teach these concepts to people at hackdays barcamps, plus in a professional context. http:// URIs for real world things clearly make it harder to learn. The follow-you-nose gimick is cool, but we could do that with a change convention, and a trivial update to existing libraries (just resolve thing:// via http://) I expect the answer is it's too late to change now. To which I am tempted to say change or die. (again, another Monday morning ranty mail! but I feel like someone should be commenting on the emperors URI convention. If there's a cheat sheet I should read before continuing commenting on these subject, please point me to it.) Kingsley Idehen wrote: On 6/13/11 1:28 AM, Pat Hayes wrote: But I don't think all this is really germane to the http-range-14 issue. The point there is, does the URI refer to something like a representation (information resource, website, document, RDF graph, whatever) or something which definitely canNOT be sent over a wire? The Referent of a URI re., http-range-14 is the observation (or description) subject. In this context the subject may or may not be a real world object or entity. In the context of Linked Data, the observation (or description) subject URI resolves to a Representation of its Referent. Actual representation is accessible via an Address. Data representation formats are *optionally* negotiable e.g., via content negotiation, and ultimately varied i.e., many serialization formats for byte stream that actually transmits data from its source to its consumers. -- Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248 You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 13, 2011, at 1:51 PM, William Waites wrote: * [2011-06-12 22:52:18 -0700] Pat Hayes pha...@ihmc.us écrit: ] OK, I am now completely and utterly lost. I have no idea what you ] are saying or how any of it is relevant to the http-range-14 issue. ] Want to try running it past me again? Bear in mind that I do not ] accept your claim that a description of something is in any useful ] sense isomorphic to the thing it describes. As in, some RDF describing, ] say, the Eiffel tower is not in any way isomorphic to the actual ] tower. (I also do not understand why you think this claim matters, ] by the way.) So in the previous email, Danny used the important word - relevant. Let's unpack that a little bit. Suppose we have no range-14 and all these RDF statements out there are all mixed up about what they refer to. Well, not completely mixed up. They're kind of clumped together, web pages and the things they are about tend to get confused but probably the chain of inferences that lead you to believe that the Eiffel tower is a dog is pretty unlikely. So there is some relationship between a description of the Eiffel tower and the tower itself. The relationship is akin to similarity in a very specific way - they are similar enough that someone thought it made sense to write down that the tower was 356m tall. What has that got to do with the tower being similar to its description? Unfortunately they got confused and wrote down that the web page was 356m tall. No matter, they are still different enough in the relevant ways that anyone interested in heights on the order of hundreds of meters is unlikely to be confused. First, you seem to be assuming here that the tower and its description are NOT similar, contrary to what you said earlier and Danny seems to be insisting upon. Second, this hypothetical person is, we both agree, confused. They made a mistake, what they said was wrong. Correct? I ask, because many people seem to want to say that they were NOT confused or wrong, just kind of less correct than if they used the right URI. Third, and most important, anyone interested is unlikely to be confused, yes indeed. But any piece of software or inference engine is not unlikely to be confused. In fact, it is virtually guaranteed to be in the position of generating absolute nonsense. If all the inference software was as smart as the average ten-year-old human, we wouldn't even need the semantic web because the software would be able to read the text on Web pages. But it isn't, and we do (need it, that is.) Same with the dog. Is the distinction between the dog and the picture important to me? Maybe, maybe not. It depends what I'm trying to do. If I want to make sure that I can recognise the doc when I meet her, a picture or the actual dog might do equally well. But if you are a semantic inference engine, and you get the dog and its picture muddled, will you likely generate a lot of nonsensical assertions? Answer, Yes, you will. Which is the key point at issue here. So that's the thing, similar or different in the relevant respects for the purpose at hand. Yeh, yeh. Contexts, local purpose, pragmatism. Now, make this happy thought cash out in an actual logic for use on the Web. Bear in mind that the very first principle of the Web is that the *publisher* of the data, who asserts these things about dogs or pictures of dogs, cannot possibly know what 'context of use' is going to be relevant to the *user* of the published content. So I say that my picture of Fido has had its rabies shots, and what will you make of this information, for your purposes, on the other side of the planet in a foreign city years after Fido has died? And what about all the other people who will use this misinformation for their different purposes? How am I going to keep them ALL happy? The purpose at hand is necessary to figure out relevance. Just deriving all the possible things that can be entailed from the information you have is no good. You have to derive the relevant things in a particular context. You have to throw out givens that are irrelevant to you or that lead you to irrelevant or nonsensical entailments. When you are the agent who is using this information, sure. But when you are the one publishing it or asserting it, you cannot do this. And when you are the one writing the rules to determine a globally accepted notion of entailment, you cannot do it. In the general case this is hard. It's not even clear if it is relevance understood like this is computable. The intent of the user is so clearly in the loop providing a reference frame for evaluating relevance and capturing and representing a user's intent is not something we have a good way of doing apart from hand-crafting interactions. Is it doable in simple cases (with rules programmed by humans) like figuring out the foaf:knows graph where people and their homepages can just be merged
Re: Schema.org in RDF ...
On Mon, Jun 13, 2011 at 7:50 AM, David Booth da...@dbooth.org wrote: On Sun, 2011-06-12 at 05:51 -0400, Alan Ruttenberg wrote: David, as you know, it is trivial to distinguish in representation the difference between an information object and a person. Correct. And that distinction is important to some apps and not to others. I am glad we agree. We also agree that what is important is not germane to the technical question of whether ambiguity is necessary, I hope. I don't know what you mean by that. It is trivial to say that foaf:Person owl:disjointWith foaf:Document or some such thing, which is what I thought you meant in your comment above. Very good, that will help. And it is trivial for *some* people to arrange for their URIs to return 303 redirects. I have not mentioned 303 or web behavior here at all, nor do I think it relevant to this discussion. You are making a claim about the necessity of ambiguity *as a fundamental principle*. While I think there were some interesting things that Pat had to say about this issue, I am claiming that raising that issue in this context is simply wrong and misleading. snip more irrelevant commentary You are missing the point. Sure, any *specific* ambiguity can be avoided. For *any* particular ambiguity it is possible to define our classes in a way to avoid that *particular* kind of ambiguity. But if you focus only on fixing each particular ambiguity you'll miss the forest for the trees. You will need to more than simply assert this in order for me to be convinced. For instance you would need to prove to me (and the other readers) that disambiguating some elements *introduces* ambiguity elsewhere. Please demonstrate this. It is *fallacious* to think that the ambiguity problem in general can be solved by getting people to fix their data to be unambiguous Once again this is off the point. There is some specific ambiguity that is in question here. We have agreed that there is no principle that says *these* ambiguities can not be avoided. It is an entirely different issue to discuss the cost of doing this. I have yet to comment on that in our discussion because I wish to get the fallacious arguments you make out of the picture first, since they confuse the issue. I am *very* interested in the cost/benefit issues. Let's talk about that without this nonsense that the problem isn't possible to fix *in principle*. snip irrelevant http-range14 issues I do not think it is at all misleading to point out the larger issue that underlies this specific case. On the contrary, I think it would be misleading to ignore it. It is promulgating FUD. -Alan
Re: Schema.org in RDF ...
David, as you know, it is trivial to distinguish in representation the difference between an information object and a person. Correct. And that distinction is important to some apps and not to others. I am glad we agree. We also agree that what is important is not germane to the technical question of whether ambiguity is necessary, I hope. I don't understand why you keep repeating this misinformation. Huh??? That's a rather rude accusation. What misinformation do you mean? Please be more specific. A comment is posted that raises a specific form of ambiguity. Your response is that ambiguity is inevitable. Yet we agree that in this case(and in other specific cases in which you have responded with this flavor of comment) it is trivial to avoid. So your response is at best misleading or non-sequitor. I'm sorry if my response came off as rude, however I am concerned that there be clarity in these conversations as the outcomes may turn out to be important. -Alan
Re: Schema.org in RDF ...
On Sunday, June 12, 2011, Lin Clark lin.w.cl...@gmail.com wrote: David, as you know, it is trivial to distinguish in representation the difference between an information object and a person. I don't understand why you keep repeating this misinformation. -Alan It is trivial to distinguish between an information resource and the resource it talks about There is no if. In the below you are talking about matters other than being able to make the distinction. if you are 1) developing a custom system under your control for your own needs, which is not extensible and does not have to integrate code published by developers with a different knowledge base than you Please give me some evidence for this. My experience (not insignificant) is otherwise. -and- 2) do not have end users who you have to educate in the distinction between an info resource and an other web resource so that they can effectively add content to your system. Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. However, it is not trivial to add this distinction when you are working in an extensible system which you do not control It depends on the manner in which the system is made extensible. Architecture and good design matters. However, It is this attitude that has led, in part, to the prulgation of schema.org as a closed architecture. or when you do not have the resources to invest in reeducation camps to change the way end users and other developers think. As an educator, in part, I do not consider educating people to require investing in reeducation camps. In my opinion, if you want to build a system by which data can be effectively aggregated and put to novel use by machines (this is what I thought we were doing) then I think you will fail if you think that will come by continuing to set no standards for how these systems communicate meaning and what kind of knowledge someone needs to have to work with them correctly. i cite the experience of the last 50 years of computer technology as evidence. -Alan I invite anyone who disagrees and who believes this is trivial to actually try effectively communicating the distinction made by httpRange-14 to an outside technology community and to attempt the social change necessary to make it work consistently in practice. Best,Lin
Re: Schema.org in RDF ...
Alan, Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. Welcome to the real world. Cheers, Michael -- Dr. Michael Hausenblas, Research Fellow LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote: On Sunday, June 12, 2011, Lin Clark lin.w.cl...@gmail.com wrote: David, as you know, it is trivial to distinguish in representation the difference between an information object and a person. I don't understand why you keep repeating this misinformation. -Alan It is trivial to distinguish between an information resource and the resource it talks about There is no if. In the below you are talking about matters other than being able to make the distinction. if you are 1) developing a custom system under your control for your own needs, which is not extensible and does not have to integrate code published by developers with a different knowledge base than you Please give me some evidence for this. My experience (not insignificant) is otherwise. -and- 2) do not have end users who you have to educate in the distinction between an info resource and an other web resource so that they can effectively add content to your system. Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. However, it is not trivial to add this distinction when you are working in an extensible system which you do not control It depends on the manner in which the system is made extensible. Architecture and good design matters. However, It is this attitude that has led, in part, to the prulgation of schema.org as a closed architecture. or when you do not have the resources to invest in reeducation camps to change the way end users and other developers think. As an educator, in part, I do not consider educating people to require investing in reeducation camps. In my opinion, if you want to build a system by which data can be effectively aggregated and put to novel use by machines (this is what I thought we were doing) then I think you will fail if you think that will come by continuing to set no standards for how these systems communicate meaning and what kind of knowledge someone needs to have to work with them correctly. i cite the experience of the last 50 years of computer technology as evidence. -Alan I invite anyone who disagrees and who believes this is trivial to actually try effectively communicating the distinction made by httpRange-14 to an outside technology community and to attempt the social change necessary to make it work consistently in practice. Best,Lin
Re: Schema.org in RDF ...
On 6/12/11 11:12 AM, Alan Ruttenberg wrote: Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. Lin, The example expressed by Alan is the crux of the matter. People know the difference between 'Obama' and a 'Book' about him. Sadly, a narrative has been constructed that leads to a really problematic misconception, as time has proven beyond all reasonable doubt. Here is the problem, as I know it. We are using hyperlinks as a mechanism for data representation via HTTP URI based Names. The URI abstraction caters for two things: Names and Addresses. When trying to untangle the unintuitive nature of HTTP URIs as a Naming mechanism for Things (e.g., real world entities or objects), a narrative have emerged aimed at tacking the hyperlink usage ambiguity problem and its emerged in a manner expands the ambiguity to generality whereas this is just a function of Name mechanism choice. Inferring that only SemWeb, LOD, and W3C folks care about the difference between a 'Obama' and a 'Book' about him is a truly broken narrative. People are just confused about how hyperlinks are evolving from Addresses to Names i.e., putting to use the power inherent in the URI abstraction such that Names resolve to Representations of their Referents. Even worse, there's similar confusion (within LOD and SemWeb communitis) when the issue of Resolvable Names not based on HTTP enter the conversation. As I've stated repeatedly, a majority of programmers and computer scientists thoroughly understand the concepts of: de-reference (indirection), address-of, and graph based data structures. They just don't recognize what they already understand when reading W3C specs and most of the LOD and SemWeb narratives. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Schema.org in RDF ...
On 6/12/11 1:00 PM, Kingsley Idehen wrote: Here is the problem, as I know it. We are using hyperlinks as a mechanism for data representation via HTTP URI based Names. The URI abstraction caters for two things: Names and Addresses. When trying to untangle the unintuitive nature of HTTP URIs as a Naming mechanism for Things (e.g., real world entities or objects), a narrative have emerged aimed at tacking the hyperlink usage ambiguity problem and its emerged in a manner expands the ambiguity to generality whereas this is just a function of Name mechanism choice. Meant to say: Here is the problem, as I know it. We are using hyperlinks as a mechanism for data representation via HTTP URI based Names. The URI abstraction caters for two things via *Schemes*: Names and Addresses. When trying to untangle the unintuitive nature of HTTP URIs, as a Naming mechanism for Things (e.g., real world entities or objects), a narrative have emerged aimed at *tackling* the hyperlink usage ambiguity problem and its emerged in a manner expands the aforementioned ambiguity to generality whereas this is just a function of HTTP scheme based Names. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 12 June 2011 01:51, Pat Hayes pha...@ihmc.us wrote: On Jun 11, 2011, at 12:20 PM, Richard Cyganiak wrote: ... It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. I think we should foster a greater level of respect for representation choices here. Your dismissal of the distinction between information resources and what they are about insults the efforts of many researchers and practitioners and their efforts in domains where such a distinction in quite important. Let's try not to alienate part of this community in order to interoperate with another. Look, Alan. I've wasted eight years arguing about that shit and defending httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, Freebase and the New York Times are violating httpRange-14. I consider that battle lost. I recanted. I've come to embrace agnosticism and I am not planning to waste any more time discussing these issues. Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever again even mentioning information resource, but I don't think we can just make this go away by ignoring it. What do we say when a URI is used both to retrieve, um sorry, identify, a Web page but is also used to refer to something which is quite definitely not a web page? What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? In the first case we can just say that identifying and reference are distinct, and that one expects the web page to provide information about the referent, which is a nice comfortable doctrine but has some holes in it. (Chiefly, how then do we actually refer to a web page?) But the second is more serious, seems to me, as it violates the basic semantic model underlying all of RDF through OWL and beyond. Maybe we need to re-think this model, but if so then we really ought to be doing that re-thinking in the RDF WG right now, surely? Just declaring an impatient agnosticism and refusing to discuss these issues does not get things actually fixed here. For pragmatic reasons I'm inclined towards Richard's pov, but it would be nice for the model to make sense. Pat, how does this sound: From HTTP we get the notions of resources and representations. The resource is the conceptual entity, the representations are concrete expressions of the resource. So take a photo of my dog - http://example.org/sasha-photo foaf:depicts http://example.org/Sasha . If we deref http://example.org/sasha-photo then we would expect to get a bunch of bits that can be displayed as an image. But that bunch of bits may be returned with HTTP header - Content-Type: image/jpeg or Content-Type: image/gif Which, for convenience, lets say correspond to files on the server called sasha-photo.jpg and sasha-photo.gif Aside from containing a different bunch of bits because of the encoding, sasha-photo.jpg could be a lossy-compressed version of sasha-photo.gif, containing less pixel information yet sharing many characteristics. All ok so far..? If so, from this we can determine that a representation of a resource need not be complete in terms of the information it contains to fulfill the RDF statement and the HTTP contract. Now turning to http://example.org/Sasha, what happens if we deref that? Sasha isn't an information resource, so following HTTP-range-14 we would expect a redirect to (say) a text/html description of Sasha. But what if we just got a 200 OK and some bits Content-Type: text/html ? We are told by this that we have a representation of my dog, but from the above, is there any reason to assume it's a complete representation? The information would presumably be a description, but is it such a leap to say that because this shares many characteristics with my dog (there will be some isomorphism between a thing and a description of a thing, right?) that this is a legitimate, however partial, representation? In other words, what we are seeing of my dog with - Content-Type: text/html. is just a very lossy version of her representation as - Content-Type: physical-matter/dog Does that make (enough) sense? Cheers, Danny. -- http://danny.ayers.name
Re: Schema.org in RDF ...
Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. My experience is with an extensible system which powers about 2% of the Web, which has over 10,000 contributed modules and 1,000 developers working on the core platform—Drupal. I have been one of the two primary people developing and educating users about the use of Linked Data technology in Drupal 7. This may be different than your experience, but it certainly isn't negligible experience when talking about the successful adoption of these technologies. It depends on the manner in which the system is made extensible. Architecture and good design matters. However, It is this attitude that has led, in part, to the prulgation of schema.org as a closed architecture. The system is extensible via the hook system, which basically follows the aspect oriented paradigm. It also uses what can be considered a Presentation Abstraction Control architecture (also called Hierarchical MVC), where the different agents at different levels of the hierarchy can come from different modules designed by different developers. This extensibility means developers with a very wide range of knowledge and experience can contribute parts of the functionality. I think this is a good thing, as do many others who attribute Drupal's success to these architectural features. Because different parts of the EAV relationship are extensible and can be developed by different developers in Drupal, it requires that all parties understand the distinction between info resource and thing resource and how to put that in practice. This means teaching them to* sometimes* use hash URIs when content is entered (which overloads the hash URI with different meanings, as it is already used for another purpose in HTML) or to use 303's with content negotiation (which even some vocabulary publishers deeply embedded in the SemWeb world don't seem to understand how to do). Good design does matter, but we have to define what we are optimizing for when we say good design: - If you are optimizing for correctness, then good design means making everyone understand and use this new distinction and changing the workflow. - If you are optimizing for large scale participation, then good design means you work with the workflows that users are already familiar with and just supplement those workflows with SemWeb technology where the technology has the chance of making something easier. I do believe that if someone steps back and thinks about it, making the distinction between a Web page about a person and the person themselves does make sense. But most people aren't stepping back and thinking about it, they are doing... and we aren't there in the room with them to tell them to take a step back and think. We can wag fingers all we want at these people, but really the most successful Web designs Don't Make Me Think. I think we also have to understand what is the best solution for now—when people don't yet understand these technologies and we need adoption—and what is the best solution for 10 years from now—when, if we have been successful at getting the tech adopted, people will understand the fundamentals of this technology and can be taken a step further. Best, Lin
Re: Schema.org in RDF ...
Hi Pat, On 12 Jun 2011, at 00:33, Pat Hayes wrote: Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. Let me respectfully disagree. Range assertions (in RDFS or OWL) do *not* capture the notion of expected type. They state a strict actual type, and cannot be consistently be over-ridden by some other information. Which has the consequence that these are liable to be, quite often, plain flat wrong. Which in turn has the consequence that there is something to be gained by dropping them, to wit, internal consistency. They are not mere documentation; they have strictly entailed consequences which many actual reasoners can and will generate, and which to deny would be to violate the RDFS specs. If you don't want these conclusions to be generated, don't make the assertions that would sanction them. Data on the Web is messy. You cannot reason over it without filtering it first. I think it is useful to document how data publishers are *expected* to use these terms, even if we know that many will -- for good or bad reasons -- use them in *unexpected* ways. For documentation, use the structures provided in RDFS for documentation, such as rdfs:comment. rdfs:comment is for prose. We explicitly know the “expected types” of properties, and I'd like to keep that information in a structured form rather than burying it in prose. As far as I can see, rdfs:range is the closest available term in W3C's data modeling toolkit, and it *is* correct as long as data publishers use the terms with the “expected type.” Best, Richard
Re: Schema.org in RDF ...
On 12 Jun 2011, at 00:51, Pat Hayes wrote: Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever again even mentioning information resource, but I don't think we can just make this go away by ignoring it. What do we say when a URI is used both to retrieve, um sorry, identify, a Web page but is also used to refer to something which is quite definitely not a web page? Then we study the specific data provider to figure out if the published assertions are about the web page or the topic of the web page, or apply various kinds of heuristics to figure it out. If we are logicians, then we say: “Oh, how clever, they are punning.” What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals). This is not pretty, but it is pragmatic. A data consumer can use rules or SPARQL CONSTRUCT to make the shape of the data more uniform. Best, Richard In the first case we can just say that identifying and reference are distinct, and that one expects the web page to provide information about the referent, which is a nice comfortable doctrine but has some holes in it. (Chiefly, how then do we actually refer to a web page?) But the second is more serious, seems to me, as it violates the basic semantic model underlying all of RDF through OWL and beyond. Maybe we need to re-think this model, but if so then we really ought to be doing that re-thinking in the RDF WG right now, surely? Just declaring an impatient agnosticism and refusing to discuss these issues does not get things actually fixed here. Pat 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
Re: Schema.org in RDF ...
On 6/12/11 2:26 PM, Lin Clark wrote: Again, this strikes me as speaking from very little experience. I spend a good deal of my time collaboratively developing ontologies and working with users of them. I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. My experience is with an extensible system which powers about 2% of the Web, which has over 10,000 contributed modules and 1,000 developers working on the core platform—Drupal. 100% of the Web and Internet is powered by data access by reference . It the most basic building block of computing, even pre silicon. I have been one of the two primary people developing and educating users about the use of Linked Data technology in Drupal 7. This may be different than your experience, but it certainly isn't negligible experience when talking about the successful adoption of these technologies. You are looking from Semantic Web narrative outwards instead of looking from the outside in. Do that and you'll grok Alan's point. It depends on the manner in which the system is made extensible. Architecture and good design matters. However, It is this attitude that has led, in part, to the prulgation of schema.org http://schema.org as a closed architecture. The system is extensible via the hook system, which basically follows the aspect oriented paradigm. It also uses what can be considered a Presentation Abstraction Control architecture (also called Hierarchical MVC), where the different agents at different levels of the hierarchy can come from different modules designed by different developers. This extensibility means developers with a very wide range of knowledge and experience can contribute parts of the functionality. I think this is a good thing, as do many others who attribute Drupal's success to these architectural features. Because different parts of the EAV relationship are extensible and can be developed by different developers in Drupal, it requires that all parties understand the distinction between info resource and thing resource and how to put that in practice. Information Resource is a poor invented replacement due to overloaded use of Resource. A chunk of data at a location is a Resource. It can bear representation of a Document or be more granular by bearing data objects (via EAV/SPO 3-tuples using links). We used have a Web of Document Addresses (URLs) and now via Name indirection (i.e., de-referencable Names) we have a new layer of abstraction. Imagine if you used DNS as your annecdote re. evolution of the Web. Once we had NIC addresses and then we had Names, courtesy of DNS. Imagine an InterWeb of NIC addresses vs one driven by Names. Even simpler example, imagine a Spreadsheet without Cell Naming capability? Most people start their Spreadsheet experience with Cell Addresses and then evolve to using Cell Names. As I keep on saying, the pattern is old, the use of Hyperlinks and ubiquity of WWW combine to deliver new context for old concepts. This means teaching them to/sometimes/ use hash URIs when content is entered (which overloads the hash URI with different meanings, as it is already used for another purpose in HTML) or to use 303's with content negotiation (which even some vocabulary publishers deeply embedded in the SemWeb world don't seem to understand how to do). Good design does matter, but we have to define what we are optimizing for when we say good design: * If you are optimizing for correctness, then good design means making everyone understand and use this new distinction and changing the workflow. * If you are optimizing for large scale participation, then good design means you work with the workflows that users are already familiar with and just supplement those workflows with SemWeb technology where the technology has the chance of making something easier. I do believe that if someone steps back and thinks about it, making the distinction between a Web page about a person and the person themselves does make sense. But most people aren't stepping back and thinking about it, they are doing... and we aren't there in the room with them to tell them to take a step back and think. We can wag fingers all we want at these people, but really the most successful Web designs Don't Make Me Think. I think we also have to understand what is the best solution for now—when people don't yet understand these technologies and we need adoption—and what is the best solution for 10 years from now—when, if we have been successful at getting the tech adopted, people will understand the fundamentals of this technology and can be taken a step further. Not understanding can be a function of chosen anecdote. This is the case most of the time re. Linked Data, RDF, and Semantic Web. Best, Lin -- Regards, Kingsley Idehen President CEO
Re: Schema.org in RDF ...
On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote: I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. This has nothing to do with books about Obama. It's about the difference between an URI-named resource which can return, say, a JSON representation of Obama; and a URI-named resource that *is* Obama. Explaining why using the same URI for both of those supposedly breaks the Web isn't *quite* that easy. Best, Richard
Re: Schema.org in RDF ...
On 11 Jun 2011, at 21:21, Giovanni Tummarello wrote: will you be posting this as a FAQ i think its definitely worth it. Good idea, thanks. Some of the answers are now here: http://schema.rdfs.org/faq.html Richard Gio On Sat, Jun 11, 2011 at 6:55 PM, Richard Cyganiak rich...@cyganiak.de wrote: All, Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and off-list. This is a collective response to various arguments brought up. I'll paraphrase the arguments. Limiting ranges of properties to strings is bad because we LD people might want to use URIs or blank nodes there. Schema.org says the range is a string, and the RDFS translation reflects this. We tried to formally describe schema.org in RDFS. We did not try to make a fork that improves upon their modelling. That might be a worthwhile project too, but a different project. Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type. This is the opposite case from the one above: They say that in place of a resource, you can always use a text. That's ok—we didn't say that schema:Thing is disjoint from literals. (I'm tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation.) The range should use rdfs:Literal instead of xsd:string to allow language tags. That's a good point. The problem is that xsd:string is too narrow and rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string literals (tagged and untagged), we'll use that when its name has been settled, and perhaps just leave the inaccurate xsd:string in place for now. You should use owl:allValuesFrom instead of the union domains/ranges. Probably correct in terms of good OWL modelling. But the current modelling is not wrong AFAICT, and it's nicer to use the same construct for single- and multi-type domains and ranges. Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. You should jiggle where rdfs:isDefinedBy points to, or use wdrs:describedby. This could probably be done better, but the way we currently do it is simple, and not wrong, so we're a bit reluctant to change it. You're missing an owl:Class type on the anonymous union classes. Good catch, fixed. Thanks Holger! You should add owl:FunctionalProperty for all single-valued properties. The schema.org documentation unfortunately doesn't talk about the cardinality of properties. Using heuristics to determine which properties could be functional seems a bit risky, given that it's easy to shoot oneself in the foot with owl:FunctionalProperty. There are UTF-8 encoding problems in comments. Fixed. Thanks Aidan! You should mint new URIs and use http://schema.rdfs.org/Thing instead of http://schema.org/Thing. Schema.org defines URIs for a set of useful vocabulary terms. The nice thing about it is that the URIs have Google backing. The Google backing would be lost by forking with a different set of URIs. You should mint new URIs because the schema.org URIs don't resolve to RDF. Dereferenceability is only a means to an end: establishing identifiers that are widely understood as denoting a particular thing. Let's acknowledge reality: Google-backed URIs with HTML-only documentation achieve this better than researcher-backed URIs which follow best practices to a tee with a cherry on top. You are violating httpRange-14 because you say that http://schema.org/Thing is a class, while it clearly is an information resource. Schema.org documentation uses these URIs as classes and properties in RDFa. They also return 200 from those URIs. So it's them who are violating httpRange-14, not us. Draw your own conclusion about the viability of httpRange-14. You should use http://schema.org/Thing#this. Schema.org is using http://schema.org/Thing as a class in their RDFa documentation. I don't think we should mint different URIs in their namespace. http://schema.org/Person is not the same as foaf:Person; one is a class of documents, the other the class of people. I don't think that's correct at all. http://schema.org/Person is the class of people and is equivalent to foaf:Person. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. Best, Richard
Re: Schema.org in RDF ...
On 6/12/11 3:42 PM, Richard Cyganiak wrote: On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote: I've yet to encounter a person who didn't understand the difference between a book about Obama and Obama. This has nothing to do with books about Obama. It's about the difference between an URI-named resource which can return, say, a JSON representation of Obama; and a URI-named resource that *is* Obama. Explaining why using the same URI for both of those supposedly breaks the Web isn't *quite* that easy. Best, Richard Richard, It isn't about braking the Web or its AWWW, really. It's about how its always been when dealing with data via programs. An Object has: 1. Name 2. Representation Address 3. Actual Representation. I can even articulate this using the much overloaded Resource term by saying: courtesy of Linked Data tweak (or evolution) Web Resources now has a: 1. Name 2. Representation Address 3. Actual Representation. Prior to the use of Links for structured data representation a Resource had a: 1. Representation Address 2. Actual Representation. It really is as simple as outlined above. HTTP explicitly includes the ability to negotiate Actual Representation via mime types. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Schema.org in RDF ...
On 12 June 2011 16:26, Richard Cyganiak rich...@cyganiak.de wrote: Hi Pat, On 12 Jun 2011, at 00:33, Pat Hayes wrote: Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. Let me respectfully disagree. Range assertions (in RDFS or OWL) do *not* capture the notion of expected type. They state a strict actual type, and cannot be consistently be over-ridden by some other information. Which has the consequence that these are liable to be, quite often, plain flat wrong. Which in turn has the consequence that there is something to be gained by dropping them, to wit, internal consistency. They are not mere documentation; they have strictly entailed consequences which many actual reasoners can and will generate, and which to deny would be to violate the RDFS specs. If you don't want these conclusions to be generated, don't make the assertions that would sanction them. Data on the Web is messy. You cannot reason over it without filtering it first. I think it is useful to document how data publishers are *expected* to use these terms, even if we know that many will -- for good or bad reasons -- use them in *unexpected* ways. For documentation, use the structures provided in RDFS for documentation, such as rdfs:comment. rdfs:comment is for prose. We explicitly know the “expected types” of properties, and I'd like to keep that information in a structured form rather than burying it in prose. As far as I can see, rdfs:range is the closest available term in W3C's data modeling toolkit, and it *is* correct as long as data publishers use the terms with the “expected type.” I don't think it is that close to expected type, or at least it's kinda back to front. If we have - :Colour a rdfs:Class . :hasColour a rdf:Property . :hasColour rdfs:range :Colour . - and someone makes a statement #something :hasColour #wet . then we get #wet a :Colour . no? so it's not an expectation thing, it's an inference that comes after the fact...if you see what I mean. As Pat suggested, I think this could easily lead to unintended conclusions. Cheers, Danny. -- http://danny.ayers.name
Re: Schema.org in RDF ...
On Jun 12, 2011, at 7:36 AM, Richard Cyganiak wrote: On 12 Jun 2011, at 00:51, Pat Hayes wrote: Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever again even mentioning information resource, but I don't think we can just make this go away by ignoring it. What do we say when a URI is used both to retrieve, um sorry, identify, a Web page but is also used to refer to something which is quite definitely not a web page? Then we study the specific data provider to figure out if the published assertions are about the web page or the topic of the web page, or apply various kinds of heuristics to figure it out. If we are logicians, then we say: “Oh, how clever, they are punning.” :-) I wish I knew how to build reasoners that could be this clever. What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals). Of course. But you didn't, did you? You (that is, Schema.org) said that the range of the property was one of these and NOT the other. Which is what I was complaining about. Pat This is not pretty, but it is pragmatic. A data consumer can use rules or SPARQL CONSTRUCT to make the shape of the data more uniform. Best, Richard In the first case we can just say that identifying and reference are distinct, and that one expects the web page to provide information about the referent, which is a nice comfortable doctrine but has some holes in it. (Chiefly, how then do we actually refer to a web page?) But the second is more serious, seems to me, as it violates the basic semantic model underlying all of RDF through OWL and beyond. Maybe we need to re-think this model, but if so then we really ought to be doing that re-thinking in the RDF WG right now, surely? Just declaring an impatient agnosticism and refusing to discuss these issues does not get things actually fixed here. Pat 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
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Sun, Jun 12, 2011 at 6:19 PM, Pat Hayes pha...@ihmc.us wrote: but the serious problem with this idea is, that it makes it impossible to simply refer to these information resources themselves. So we would be unable to talk about Web pages using the Web description language RDF. That seems too strong. Just thinking about this alternative - that 200 responders (for the purposes of linked data) are not considered IRs. Instead 200 implies an assertion (for, say, http://www.ihmc.us/users/phayes/) _:foo a :information-thing _:foo :at http://www.ihmc.us/users/phayes/^^xsd:anyURI (there exists an information resource accessible at http://www.ihmc.us/users/phayes/) to which could then be asserted in your favored syntax: _:page a :web-page _:page :at http://www.ihmc.us/users/phayes/^^xsd:anyURI _:page dc:creator http://www.ihmc.us/users/phayes/ This effectively flips what is now the default (you would use, e.g. foaf:primaryTopic to go in the opposite direction) Not that I'm advocating this. For one thing there are many information thinks that couldn't possibly be understood as designators. (well, shouldn't ;-) -Alan
Re: Schema.org in RDF ...
On 12 Jun 2011, at 18:34, Pat Hayes wrote: What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals). Of course. But you didn't, did you? You (that is, Schema.org) said that the range of the property was one of these and NOT the other. Which is what I was complaining about. Where is it said that the range is one and not the other? Citing from the schema.rdfs.org FAQ [1], which has the same answer I gave earlier here in the thread: Q: Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type, why is this not reflected in the RDFS? A: That's ok—we didn't say that schema:Thing is disjoint from literals, so you can use a string when the declared range is schema:Person. (We were tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation, but narrowly decided against it.) So I think it's all ok. Best, Richard [1] http://schema.rdfs.org/faq.html
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
(there will be some isomorphism between a thing and a description of a thing, right? Absolutely not. Descriptions are not in any way isomorphic to the things they describe. (OK, some 'diagrammatic' representations can be claimed to be, eg in cartography, but even those cases don't stand up to careful analysis. in fact.) Beh! Some isomorphism is all I ask for. Take your height and shoe size - those numeric descriptions will correspond 1:1 with aspects of the reality. Keep going to a waxwork model of you, the path you walked in the park this afternoon - are you suggesting there's no isomorphism? ** To illustrate. Someone goes to a website about dogs, likes one of the dogs, and buys it on-line. He goes to collect the dog, the shopkeeper gives him a photograph of the dog. Um, Where is the dog? Right there, says the seller, pointing to the photograph. That isn't good enough. The seller mutters a bit, goes into the back room, comes back with a much larger, crisper, glossier picture, says, is that enough of the dog for you? But the customer still isn't satisfied. The seller finds a flash card with an hour-long HD movie of the dog, and even offers, if the customer is willing to wait a week or two, to have a short novel written by a well-known author entirely about the dog. But the customer still isn't happy. The seller is at his wits end, because he just doesn't know how to satisfy this customer. What else can I do? He asks. I don't have any better representations of the dog than these. So the customer says, look, I want the *actual dog*, not a representation of a dog. Its not a matter of getting me more information about the dog; I want the actual, smelly animal. And the seller says, what do you mean, an actual dog? We just deal in **representations** of dogs. There's no such thing as an actual dog. Surely you knew that when you looked at our website? Lovely imagery, thanks Pat. But replace a novel written by a dog for dog in the above. Why should the concept of a document be fundamentally any different from the concept of a dog, hence representations of a document and representations of a dog? Ok, you can squeeze something over the wire that represents a novel written by a dog but you (probably) can't squeeze a dog over, but that's just a limitation of the protocol. There's equally an *actual* document (as a bunch of bits) and an *actual* dog (as a bunch of cells). Cheers, Danny. -- http://danny.ayers.name
Re: Schema.org in RDF ...
On Jun 12, 2011, at 11:12 AM, Richard Cyganiak wrote: On 12 Jun 2011, at 18:34, Pat Hayes wrote: What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals). Of course. But you didn't, did you? You (that is, Schema.org) said that the range of the property was one of these and NOT the other. Which is what I was complaining about. Where is it said that the range is one and not the other? Well, if you say the range is xsd:string, then anything which is a value has to be a string, right? As for example (taken at random) schema:cookingMethod a rdf:Property; rdfs:label Cooking Method@en; rdfs:comment The method of cooking, such as Frying, Steaming, ...@en; rdfs:domain schema:Recipe; rdfs:range xsd:string; rdfs:isDefinedBy http://schema.org/Recipe; This says that the range is xsd:string, so nothing other than an xsd string will be acceptable here. Am I missing something? Pat Citing from the schema.rdfs.org FAQ [1], which has the same answer I gave earlier here in the thread: Q: Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type, why is this not reflected in the RDFS? A: That's ok—we didn't say that schema:Thing is disjoint from literals, so you can use a string when the declared range is schema:Person. (We were tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation, but narrowly decided against it.) So I think it's all ok. Best, Richard [1] http://schema.rdfs.org/faq.html 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
Re: Schema.org in RDF ...
On 06/12/2011 08:19 PM, Richard Cyganiak wrote: Hi Danny, On 12 Jun 2011, at 17:57, Danny Ayers wrote: We explicitly know the “expected types” of properties, and I'd like to keep that information in a structured form rather than burying it in prose. As far as I can see, rdfs:range is the closest available term in W3C's data modeling toolkit, and it *is* correct as long as data publishers use the terms with the “expected type.” I don't think it is that close to expected type I didn't say it's close to “expected type”. I said that we want to keep the information in a structured form, and that rdfs:range is the closest construct available in the W3C toolkit. Hi, Why not make a new property for such loose semantics (and make rdfs:range subproperty of it)? Surely we didn't go out of way to have great flexibility, compared to controlled vocabularies, for nothing... #something :hasColour #wet . then we get #wet a :Colour . If you apply RDFS/OWL reasoning to broken data, you get more broken data. I don't understand why anyone would be surprised by that. I am surprised someone wants to publish broken data. Best, Jiri signature.asc Description: OpenPGP digital signature
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On Jun 12, 2011, at 4:13 PM, Danny Ayers wrote: (there will be some isomorphism between a thing and a description of a thing, right? Absolutely not. Descriptions are not in any way isomorphic to the things they describe. (OK, some 'diagrammatic' representations can be claimed to be, eg in cartography, but even those cases don't stand up to careful analysis. in fact.) Beh! Some isomorphism is all I ask for. Take your height and shoe size - those numeric descriptions will correspond 1:1 with aspects of the reality. Keep going to a waxwork model of you, the path you walked in the park this afternoon - are you suggesting there's no isomorphism? Yes, in fact I am *denying* there is *any* isomorphism. What structures are you intending to appeal to when you say 'isomorphic'? Do you see reality as being some kind of giant category? Or what? Lets suppose that the interpretation/denotation/semantic/reference mapping goes from the representation to the reality. (Since its an isomorphism, it should be invertible, so this is an arbitrary choice, right?) Call this mapping ref, so X ref Y means that Y is one way reality might be assuming X is true, when X is used as a representation. First point: for descriptions, ref is a Galois mapping, which means that when X gets larger - when the representation says more about the reality - then Y, the number of ways that the reality can be, gets smaller. The more you say, the more tightly you constrain the ways the world can be. This is exactly the opposite from how an isomorphism would behave. Next point: there can indeed be correspondences between the syntactic structure of a description and the aspects of reality it describes. Your example of the path I walked would be one, if you were to draw the path on an accurate map. But this is completely hostage to the map being **accurate**. If I used a not-to-scale sketch map, then no, you don't get isomorphism. Yet it seems to me that these two cases, the real map and a sketch map, both seem to work in the same kind of semantic way. So this explanation of how they work cannot depend on there being an isomorphism. Maybe there is a kind of homomorphism, but even that is kind of hard to make work. What it seems to be is more like, the map projection function is a homomorphism of the entire mapped terrain, and then marks or symbols on the map indicate terrain location by inverting this projection morphism and asserting an existential to the effect that the thing described is contained in that back-projected space in the terrain from space occupied by the mark or symbol in the map space. But I don't think all this is really germane to the http-range-14 issue. The point there is, does the URI refer to something like a representation (information resource, website, document, RDF graph, whatever) or something which definitely canNOT be sent over a wire? ** To illustrate. Someone goes to a website about dogs, likes one of the dogs, and buys it on-line. He goes to collect the dog, the shopkeeper gives him a photograph of the dog. Um, Where is the dog? Right there, says the seller, pointing to the photograph. That isn't good enough. The seller mutters a bit, goes into the back room, comes back with a much larger, crisper, glossier picture, says, is that enough of the dog for you? But the customer still isn't satisfied. The seller finds a flash card with an hour-long HD movie of the dog, and even offers, if the customer is willing to wait a week or two, to have a short novel written by a well-known author entirely about the dog. But the customer still isn't happy. The seller is at his wits end, because he just doesn't know how to satisfy this customer. What else can I do? He asks. I don't have any better representations of the dog than these. So the customer says, look, I want the *actual dog*, not a representation of a dog. Its not a matter of getting me more information about the dog; I want the actual, smelly animal. And the seller says, what do you mean, an actual dog? We just deal in **representations** of dogs. There's no such thing as an actual dog. Surely you knew that when you looked at our website? Lovely imagery, thanks Pat. But replace a novel written by a dog for dog in the above. Why should the concept of a document be fundamentally any different from the concept of a dog, hence representations of a document and representations of a dog? I dont follow your point here. If you mean, a document is just as real as a dog, I agree. So? But if you mean, there is no basic difference between a document and a dog, I disagree. And so does my cat. Ok, you can squeeze something over the wire that represents a novel written by a dog but you (probably) can't squeeze a dog over, but that's just a limitation of the protocol. So improved software engineering will enable us to teleport dogs over the internet? Come on, you don't actually
Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]
On 13 June 2011 02:28, Pat Hayes pha...@ihmc.us wrote: Next point: there can indeed be correspondences between the syntactic structure of a description and the aspects of reality it describes. That is what I was calling isomorphism (which I still don't think was inaccurate). But ok, say there are correspondences instead. I would suggest that those correspondences are enough to allow the description to take the place of a representation under HTTP definitions. But I don't think all this is really germane to the http-range-14 issue. The point there is, does the URI refer to something like a representation (information resource, website, document, RDF graph, whatever) or something which definitely canNOT be sent over a wire? I'm saying conceptually it doesn't matter if you can put it over the wire or not. But replace a novel written by a dog for dog in the above. Why should the concept of a document be fundamentally any different from the concept of a dog, hence representations of a document and representations of a dog? I dont follow your point here. If you mean, a document is just as real as a dog, I agree. So? But if you mean, there is no basic difference between a document and a dog, I disagree. And so does my cat. Difference sure, but not necessarily relevant. Ok, you can squeeze something over the wire that represents a novel written by a dog but you (probably) can't squeeze a dog over, but that's just a limitation of the protocol. So improved software engineering will enable us to teleport dogs over the internet? Come on, you don't actually believe this. It would save a lot of effort sometimes (walkies!) but all I'm suggesting is that if, hypothetically, you could teleport matter over the internet, all you'd be looking at as far as http-range-14 is concerned is another media type. Working back from there, and given correspondences as above, a descriptive document can be a valid representation of the identified resource even if it happens to be an actual thing, given that there isn't necessary any one true representation. We don't need the Information Resource distinction here (useful elsewhere maybe). Cheers, Danny. -- http://danny.ayers.name
Re: Schema.org in RDF ...
All, Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and off-list. This is a collective response to various arguments brought up. I'll paraphrase the arguments. Limiting ranges of properties to strings is bad because we LD people might want to use URIs or blank nodes there. Schema.org says the range is a string, and the RDFS translation reflects this. We tried to formally describe schema.org in RDFS. We did not try to make a fork that improves upon their modelling. That might be a worthwhile project too, but a different project. Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type. This is the opposite case from the one above: They say that in place of a resource, you can always use a text. That's ok—we didn't say that schema:Thing is disjoint from literals. (I'm tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation.) The range should use rdfs:Literal instead of xsd:string to allow language tags. That's a good point. The problem is that xsd:string is too narrow and rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string literals (tagged and untagged), we'll use that when its name has been settled, and perhaps just leave the inaccurate xsd:string in place for now. You should use owl:allValuesFrom instead of the union domains/ranges. Probably correct in terms of good OWL modelling. But the current modelling is not wrong AFAICT, and it's nicer to use the same construct for single- and multi-type domains and ranges. Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. You should jiggle where rdfs:isDefinedBy points to, or use wdrs:describedby. This could probably be done better, but the way we currently do it is simple, and not wrong, so we're a bit reluctant to change it. You're missing an owl:Class type on the anonymous union classes. Good catch, fixed. Thanks Holger! You should add owl:FunctionalProperty for all single-valued properties. The schema.org documentation unfortunately doesn't talk about the cardinality of properties. Using heuristics to determine which properties could be functional seems a bit risky, given that it's easy to shoot oneself in the foot with owl:FunctionalProperty. There are UTF-8 encoding problems in comments. Fixed. Thanks Aidan! You should mint new URIs and use http://schema.rdfs.org/Thing instead of http://schema.org/Thing. Schema.org defines URIs for a set of useful vocabulary terms. The nice thing about it is that the URIs have Google backing. The Google backing would be lost by forking with a different set of URIs. You should mint new URIs because the schema.org URIs don't resolve to RDF. Dereferenceability is only a means to an end: establishing identifiers that are widely understood as denoting a particular thing. Let's acknowledge reality: Google-backed URIs with HTML-only documentation achieve this better than researcher-backed URIs which follow best practices to a tee with a cherry on top. You are violating httpRange-14 because you say that http://schema.org/Thing is a class, while it clearly is an information resource. Schema.org documentation uses these URIs as classes and properties in RDFa. They also return 200 from those URIs. So it's them who are violating httpRange-14, not us. Draw your own conclusion about the viability of httpRange-14. You should use http://schema.org/Thing#this. Schema.org is using http://schema.org/Thing as a class in their RDFa documentation. I don't think we should mint different URIs in their namespace. http://schema.org/Person is not the same as foaf:Person; one is a class of documents, the other the class of people. I don't think that's correct at all. http://schema.org/Person is the class of people and is equivalent to foaf:Person. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. Best, Richard
Re: Schema.org in RDF ...
On Sat, Jun 11, 2011 at 12:55 PM, Richard Cyganiak rich...@cyganiak.de wrote: That's a good point. The problem is that xsd:string is too narrow and rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string literals (tagged and untagged), we'll use that when its name has been settled, and perhaps just leave the inaccurate xsd:string in place for now. There already exists such a type that is a W3C recommendation. It is called rdf:PlainLiteral - see http://www.w3.org/TR/rdf-plain-literal/ I'm not sure why RDF 1.1 working group is not aware of that. -Alan
Re: Schema.org in RDF ...
On Sat, Jun 11, 2011 at 12:55 PM, Richard Cyganiak rich...@cyganiak.de wrote: It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. I think we should foster a greater level of respect for representation choices here. Your dismissal of the distinction between information resources and what they are about insults the efforts of many researchers and practitioners and their efforts in domains where such a distinction in quite important. Let's try not to alienate part of this community in order to interoperate with another. -Alan
Re: Schema.org in RDF ...
Alan, Always a pleasure to hear from you. On 11 Jun 2011, at 18:55, Alan Ruttenberg wrote: There already exists such a type that is a W3C recommendation. It is called rdf:PlainLiteral - see http://www.w3.org/TR/rdf-plain-literal/ I'm not sure why RDF 1.1 working group is not aware of that. Thank you for your contribution. The RDF WG is well aware of that. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. I think we should foster a greater level of respect for representation choices here. Your dismissal of the distinction between information resources and what they are about insults the efforts of many researchers and practitioners and their efforts in domains where such a distinction in quite important. Let's try not to alienate part of this community in order to interoperate with another. Look, Alan. I've wasted eight years arguing about that shit and defending httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, Freebase and the New York Times are violating httpRange-14. I consider that battle lost. I recanted. I've come to embrace agnosticism and I am not planning to waste any more time discussing these issues. Best, Richard
Re: Schema.org in RDF ...
My sincere congratulations, i had someone overlooked at this level of detail needed here. The choices are pragmatic and - in my personal opinion having talked directly at SemTech with a lot of people involved in this - should serve the community as good as possible. will you be posting this as a FAQ i think its definitely worth it. Gio On Sat, Jun 11, 2011 at 6:55 PM, Richard Cyganiak rich...@cyganiak.de wrote: All, Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and off-list. This is a collective response to various arguments brought up. I'll paraphrase the arguments. Limiting ranges of properties to strings is bad because we LD people might want to use URIs or blank nodes there. Schema.org says the range is a string, and the RDFS translation reflects this. We tried to formally describe schema.org in RDFS. We did not try to make a fork that improves upon their modelling. That might be a worthwhile project too, but a different project. Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type. This is the opposite case from the one above: They say that in place of a resource, you can always use a text. That's ok—we didn't say that schema:Thing is disjoint from literals. (I'm tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation.) The range should use rdfs:Literal instead of xsd:string to allow language tags. That's a good point. The problem is that xsd:string is too narrow and rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string literals (tagged and untagged), we'll use that when its name has been settled, and perhaps just leave the inaccurate xsd:string in place for now. You should use owl:allValuesFrom instead of the union domains/ranges. Probably correct in terms of good OWL modelling. But the current modelling is not wrong AFAICT, and it's nicer to use the same construct for single- and multi-type domains and ranges. Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. You should jiggle where rdfs:isDefinedBy points to, or use wdrs:describedby. This could probably be done better, but the way we currently do it is simple, and not wrong, so we're a bit reluctant to change it. You're missing an owl:Class type on the anonymous union classes. Good catch, fixed. Thanks Holger! You should add owl:FunctionalProperty for all single-valued properties. The schema.org documentation unfortunately doesn't talk about the cardinality of properties. Using heuristics to determine which properties could be functional seems a bit risky, given that it's easy to shoot oneself in the foot with owl:FunctionalProperty. There are UTF-8 encoding problems in comments. Fixed. Thanks Aidan! You should mint new URIs and use http://schema.rdfs.org/Thing instead of http://schema.org/Thing. Schema.org defines URIs for a set of useful vocabulary terms. The nice thing about it is that the URIs have Google backing. The Google backing would be lost by forking with a different set of URIs. You should mint new URIs because the schema.org URIs don't resolve to RDF. Dereferenceability is only a means to an end: establishing identifiers that are widely understood as denoting a particular thing. Let's acknowledge reality: Google-backed URIs with HTML-only documentation achieve this better than researcher-backed URIs which follow best practices to a tee with a cherry on top. You are violating httpRange-14 because you say that http://schema.org/Thing is a class, while it clearly is an information resource. Schema.org documentation uses these URIs as classes and properties in RDFa. They also return 200 from those URIs. So it's them who are violating httpRange-14, not us. Draw your own conclusion about the viability of httpRange-14. You should use http://schema.org/Thing#this. Schema.org is using http://schema.org/Thing as a class in their RDFa documentation. I don't think we should mint different URIs in their namespace. http://schema.org/Person is not the same as foaf:Person; one is a class of documents, the other the class of people. I don't think that's correct at all. http://schema.org/Person is the class of people and is equivalent to foaf:Person. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. Best, Richard
Re: Schema.org in RDF ...
On Sat, 2011-06-11 at 17:55 +0100, Richard Cyganiak wrote: [ . . . ] http://schema.org/Person is not the same as foaf:Person; one is a class of documents, the other the class of people. I don't think that's correct at all. http://schema.org/Person is the class of people and is equivalent to foaf:Person. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. Furthermore, the kind of ambiguity that this creates is *inescapable* in general, and we simply need to learn to deal with it. As long as an application does not attempt to assert that foaf:Person is owl:disjointWith the class of documents, there is no problem. It is only a problem for those applications the *need* to distinguish between foaf:Persons and document. Furthermore, there is a *cost* in making finer distinctions than needed. For example, an ontology that models the world as flat costs less to process and maintain than one that models the world as round, even though it is obviously wrong in some sense. But modeling the world as flat is *better* for an application that is merely computing driving directions, because it is simpler, even though it would be totally inadequate for an aircraft application. Resource ambiguity is not something that should be viewed as an absolute. Rather, it is *relative* to a particular application: a URI that is completely unambiguous to one application may be ambiguous to another application that requires finer distinctions. For more explanation of this, see myth #3 in Resource Identity and Semantic Extensions: Making Sense of Ambiguity: http://dbooth.org/2010/ambiguity/paper.html#myth3 And see Pat Hayes's favorite example of the definition of Mount Everest: http://lists.w3.org/Archives/Public/semantic-web/2011Mar/0242.html While it is nicer to the community to avoid ambiguity that is *likely* to cause problems to lots of applications, ultimately it is up to the URI owner to decide what kinds of applications they want their URIs to support. OTOH, if your application will be negatively affected, there is nothing wrong with lobbying the URI owner to change their ways to better support *your* application. At the same time, you should recognize that *your* application is not *every* application. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: Schema.org in RDF ...
On 6/11/11 5:55 PM, Richard Cyganiak wrote: I don't think that's correct at all.http://schema.org/Person is the class of people and is equivalent to foaf:Person. It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. Yes, until we demonstrate tangible value via useful real world applications that make a difference. Thus, outside this community, the deeper (and actual) value of de-reference (indirection) and address-of operations handling via Linked style URIs will remain mysterious and speculative. A long time ago (pre. DNS) folks where uncertain about the value of associating names with IP addresses. Eventually, DNS caught on and the rest is history. We're repeating the journey with Linked Data (which is really DataDNS or DataObjectNameServices), end game will be the same :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Schema.org in RDF ...
On 6/11/11 8:20 PM, Richard Cyganiak wrote: Look, Alan. I've wasted eight years arguing about that shit and defending httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, Freebase and the New York Times are violating httpRange-14. I consider that battle lost. I recanted. I've come to embrace agnosticism and I am not planning to waste any more time discussing these issues. Richard, The battle isn't lost. The basic lesson is this, less talk and more walk. To date httpRange-14 has been a clump of gobbledygook to most. This is why I've always raised concerns with both the RDF and Linked Data narratives. RDF supports seek to push it as the sole option for Linked Data which is a brutal fallacy, diabolical marketing, and the cruelest of obstructions to insert into Linked Data's momentum. Linked Data is about a time test computing practice in the realm of data access by reference. There are a vast number of programmers outside the W3C that understand de-reference (indirection) and address-of operations. These basic operations are utterly lost in the httpRange-14 narrative because it opted to carve out an island from the broader continent that is computer science. Using Links as espoused by TimBL's Linked Data meme is an innovation that has its origins in fundamental data access by reference. The difference is that we are using an old concept at InterWeb scale. The day we tweak the narrative is the day the confusion starts to dissipate. Disambiguating de-reference (indirection) and address-of operations via a HTTP messaging heuristic such that Objects are endowed with Names is a no-brainer, but only when the concept is understood. Thus, as stated in my earlier post, we have to make solutions that demonstrate the underlying power of this old concept that's now available to end-users, power-users, integrators, and developers via Links. Let's keep on educating, but via solutions that make value palpable. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Schema.org in RDF ...
On Jun 11, 2011, at 9:55 AM, Richard Cyganiak wrote: All, Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and off-list. This is a collective response to various arguments brought up. I'll paraphrase the arguments. ... Nothing is gained from the range assertions. They should be dropped. They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost. Conversely, nothing is gained by dropping them. Let me respectfully disagree. Range assertions (in RDFS or OWL) do *not* capture the notion of expected type. They state a strict actual type, and cannot be consistently be over-ridden by some other information. Which has the consequence that these are liable to be, quite often, plain flat wrong. Which in turn has the consequence that there is something to be gained by dropping them, to wit, internal consistency. They are not mere documentation; they have strictly entailed consequences which many actual reasoners can and will generate, and which to deny would be to violate the RDFS specs. If you don't want these conclusions to be generated, don't make the assertions that would sanction them. For documentation, use the structures provided in RDFS for documentation, such as rdfs:comment. Pat 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
Re: Schema.org in RDF ...
On Jun 11, 2011, at 10:55 AM, Alan Ruttenberg wrote: On Sat, Jun 11, 2011 at 12:55 PM, Richard Cyganiak rich...@cyganiak.de wrote: That's a good point. The problem is that xsd:string is too narrow and rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string literals (tagged and untagged), we'll use that when its name has been settled, and perhaps just leave the inaccurate xsd:string in place for now. There already exists such a type that is a W3C recommendation. It is called rdf:PlainLiteral - see http://www.w3.org/TR/rdf-plain-literal/ I'm not sure why RDF 1.1 working group is not aware of that. It is. But rdf:PlainLiteral requires the literal to be re-written in an odd and unintuitive fashion. The WG is working out a slight variation on this which will get past that awkwardness. Just be patient... Pat -Alan 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
Re: Schema.org in RDF ...
On Jun 11, 2011, at 12:20 PM, Richard Cyganiak wrote: ... It's just that the schema.org designers don't seem to care much about the distinction between information resources and angels and pinheads. This is the prevalent attitude outside of this mailing list and we should come to terms with this. I think we should foster a greater level of respect for representation choices here. Your dismissal of the distinction between information resources and what they are about insults the efforts of many researchers and practitioners and their efforts in domains where such a distinction in quite important. Let's try not to alienate part of this community in order to interoperate with another. Look, Alan. I've wasted eight years arguing about that shit and defending httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, Freebase and the New York Times are violating httpRange-14. I consider that battle lost. I recanted. I've come to embrace agnosticism and I am not planning to waste any more time discussing these issues. Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever again even mentioning information resource, but I don't think we can just make this go away by ignoring it. What do we say when a URI is used both to retrieve, um sorry, identify, a Web page but is also used to refer to something which is quite definitely not a web page? What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person? In the first case we can just say that identifying and reference are distinct, and that one expects the web page to provide information about the referent, which is a nice comfortable doctrine but has some holes in it. (Chiefly, how then do we actually refer to a web page?) But the second is more serious, seems to me, as it violates the basic semantic model underlying all of RDF through OWL and beyond. Maybe we need to re-think this model, but if so then we really ought to be doing that re-thinking in the RDF WG right now, surely? Just declaring an impatient agnosticism and refusing to discuss these issues does not get things actually fixed here. Pat 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
