Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Tom: Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level. body h1This is the car I want to sell/h1 Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009 span ... my whole RDF in RDFa /span body The advantage of that would be that - you just have to maintain ONE file, - data and metadata are close by, so the likelihood of being up to date increases, and - at the same time, the code does not get too messy. - Also - no problems setting up the server (*). - Easy to create on-line tools that generate RDFa snippets for simple pasting. - Yahoo and Google will most likely honor RDFa meta-data only. Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g. dates, country codes,...) I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc. Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description. The main problem with my proposal is that there is the risk that Google considers this cloaking and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index. A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those. Best Martin Tom Heath wrote: Martin, 2009/6/27 Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org: So if this hidden div / span approach is not feasible, we got a problem. The reason is that, as beautiful the idea is of using RDFa to make a) the human-readable presentation and b) the machine-readable meta-data link to the same literals, the problematic is it in reality once the structure of a) and b) are very different. For very simple property-value pairs, embedding RDFa markup is no problem. But if you have a bit more complexity at the conceptual level and in particular if there are significant differences to the structure of the presentation (e.g. in terms of granularity, ordering of elements, etc.), it gets very, very messy and hard to maintain. Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. Tom. -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: mh...@computer.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out the GoodRelations vocabulary for E-Commerce on the Web of Data! Webcast: http://www.heppnetz.de/projects/goodrelations/webcast/ Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology http://tinyurl.com/semtech-hepp Tool for registering your business: http://www.ebusiness-unibw.org/tools/goodrelations-annotator/ Overview article on Semantic Universe: http://tinyurl.com/goodrelations-universe Project page and resources for developers: http://purl.org/goodrelations/ Tutorial materials: Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009 begin:vcard fn:Martin Hepp n:Hepp;Martin org:Bundeswehr University Munich;E-Business and Web Science Research Group adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany email;internet:mh...@computer.org tel;work:+49 89 6004 4217 tel;pager:skype: mfhepp url:http://www.heppnetz.de version:2.1 end:vcard
Re: Visualization of domain and range
Bernhard, Yes, I understand that this is how rdfs:domain and rdfs:range are interpreted. I agree that the knowledge addition of RDFS and OWL is a great strength. I would rephrase your interpretation to: you can use foaf:holdsAccount. if something has a foaf:holdsAccount property then you MUST interpret it as foaf:Agent, and the value of this property MUST be interpreted as foaf:OnlineAccount. Of course, MUST is only if you choose to employ RDFS reasoners. Anything goes in non-inference,RDF-as-a-datastore land. Unfortunately, I want to employ an RDFS reasoner AND use the foaf:holdsAccount to point to /non/Online Accounts. I can't use it because my /non/online Accounts WILL be interpreted as foaf:OnlineAccounts, which I want to be satisfiably false (but is provably true). To fix this, we'd have to: - ( foaf:holdsAccount rdfs:range foaf:OnlineAccount . ) + ( foaf:holdsAccount rdfs:range ns:Account . foaf:OnlineAccount rdfs:subClassOf ns:Account . ) So, returning to my general question about asserting the domain and range of a property. Is it prematurely limiting if the first-party developers inadvertently set the range to a /subclass/ of a class that a third-party developer thinks is a reasonable range? Thanks for your consideration! Regards, Tim Lebo ps - I'm trying to collect design patterns for OWL at http://www.twine.com/twine/12dff54dt-1wj/owl-the-web-ontology-language-design-patterns On Sat, Jun 27, 2009 at 4:00 AM, Bernhard Schandl bernhard.scha...@univie.ac.at wrote: foaf:holdsAccount rdfs:domain foaf:Agent; rdfs:range foaf:OnlineAccount . Is constraining a property with BOTH a domain and range a good design pattern? It seems rather short-sighted with respect to reuse and extension. Domain and range are no restrictions in that sense; rather they extend the possible (!) interpretations of resources. Hence you don't say, you can use foaf:holdsAccount only with foaf:Agent and foaf:OnlineAccount, but rather, if something has a foaf:holdsAccount property then you can interpret it as foaf:Agent, and the value of this property can be interpreted as foaf:OnlineAccount. IMO this is one of the greatest strengths of modelling with RDF(S) and OWL.
Re: Visualization of domain and range
On Sun, Jun 28, 2009 at 3:44 AM, Bernhard Schandl bernhard.scha...@univie.ac.at wrote: Instead of changing the original FOAF ontology (which only the owners of the FOAF namespace can do), I would suggest that you add another property for your application and define it as super-property of foaf:holdsAccount, foaf:holdsAccount rdfs:subPropertyOf ex:holdsAccount . and use ex:holdsAccount instead of foaf:holdsAccount. However whenever you encounter a foaf:holdsAccount you can treat it as instance of ex:holdsAccount. That solves it. The solution came to me this morning as I was waking up, but you beat me to it :-) If you do not allow ontology developers to define restrictions on the classes and properties they define, then we end up with plain collections of terms, but without the possibility to derive useful conclusions from the data. However to build meaningful applications we need constraints on the data, and if you do not need these constraints you have two options: either do not use inference, or define your own (unrestricted) vocabulary and link it to the . Best, Bernhard That is a really good was of describing. Thanks for your insights! Respectively, Tim Lebo
Re: Visualization of domain and range
All, Thanks for an interesting discussion. It is interesting how many visual styles different people can come up with. Is there a place that gathers these up for comparison? I made a twine at http://www.twine.com/twine/12df6wvd7-1f0/owl-the-web-ontology-language-visualization. It includes the examples from this thread; feel free to add more. I have developed my own visual styles over the years and would like to see if I got it wrong :-) Is there a good source for a description of the commonly-accepted conventions? I also love the fact that Dan started to enumerate the OWL tasks that the visual should support. We can't evaluate a visualization unless we know the tasks that it must support. With the new OWL 2 constructs, I'll have to go back to the drawing board for things like property chains and keys. I was excited to find out that the disjointUnionOf construct came through, because I already made the visual abbreviation for the verbose OWL 1 expressions. Regards, Tim Lebo ps - svn co http://svn.foaf-project.org/foaf/trunk/xmlns.com/htdocs/foaf/spec/images/only gives a jpg, svg, and graffle. Can you include a URL for the foaf.owl spec that inspired these works of art? I want to make sure I work on the same input. In http://www.flickr.com/photos/danbri/1856478164/ ([4]) I try to do too many things at once: * show the classes that each property is used with * show sub-property relationships * show sub-class relationships * show some typical properties * show attachment points for friends of FOAF namespaces (DOAP, SIOC, DC, Geo etc), with classes and with sample properties This is a lot of information. I did try to make a gradual reveal slideshow version, building up from something simple. It wasn't great. The layout was done by hand to minimise crossovers, and looking at it, I think the whole structure could be twisted/stretched to be more evenly presented. It was fiddly to do though. A sample of instance-data would probably convey most of the same information about domain/range, and would allow subclasses reasonably too. Sub-property would remain hard... If anyone wants to mess around with the FOAF example, source data in OmniGraffle format is here and also in SVG: just do svn co http://svn.foaf-project.org/foaf/trunk/xmlns.com/htdocs/foaf/spec/images/;
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Martin, 2009/6/29 Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org: Hi Tom: Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level. body h1This is the car I want to sell/h1 Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009 span ... my whole RDF in RDFa /span body The advantage of that would be that - you just have to maintain ONE file, - data and metadata are close by, so the likelihood of being up to date increases, and - at the same time, the code does not get too messy. - Also - no problems setting up the server (*). - Easy to create on-line tools that generate RDFa snippets for simple pasting. - Yahoo and Google will most likely honor RDFa meta-data only. Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g. dates, country codes,...) I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc. Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description. The main problem with my proposal is that there is the risk that Google considers this cloaking and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index. A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those. These are exactly the reasons why I emphasise the limitations and ask that we don't oversell the capabilities of any technology, RDFa included. Tom.
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Martin Hepp (UniBW) wrote: Hi Tom: Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level. body h1This is the car I want to sell/h1 Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009 span ... my whole RDF in RDFa /span body The advantage of that would be that - you just have to maintain ONE file, - data and metadata are close by, so the likelihood of being up to date increases, and - at the same time, the code does not get too messy. - Also - no problems setting up the server (*). - Easy to create on-line tools that generate RDFa snippets for simple pasting. - Yahoo and Google will most likely honor RDFa meta-data only. Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g. dates, country codes,...) I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc. Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description. The main problem with my proposal is that there is the risk that Google considers this cloaking and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index. A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those. Martin, If Google doesn't see invisible DIVs as cloaking, the issue vaporizes. Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa) approach they will at least remain in the Google index via usual SEO oriented keyword gimmickry, albeit generally suboptimal. If we make a recipe doc showcasing these issues, we will more than likely get Google to recalibrate back to the Web; especially if we can demonstrate that other search engine players --that have support RDFa -- not being afflicted with the same cloaking myopia. Kingsley Best Martin Tom Heath wrote: Martin, 2009/6/27 Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org: So if this hidden div / span approach is not feasible, we got a problem. The reason is that, as beautiful the idea is of using RDFa to make a) the human-readable presentation and b) the machine-readable meta-data link to the same literals, the problematic is it in reality once the structure of a) and b) are very different. For very simple property-value pairs, embedding RDFa markup is no problem. But if you have a bit more complexity at the conceptual level and in particular if there are significant differences to the structure of the presentation (e.g. in terms of granularity, ordering of elements, etc.), it gets very, very messy and hard to maintain. Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. Tom. -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: mh...@computer.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out the GoodRelations vocabulary for E-Commerce on the Web of Data! Webcast: http://www.heppnetz.de/projects/goodrelations/webcast/ Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology http://tinyurl.com/semtech-hepp Tool for registering your business: http://www.ebusiness-unibw.org/tools/goodrelations-annotator/ Overview article on Semantic Universe: http://tinyurl.com/goodrelations-universe Project page and resources for developers: http://purl.org/goodrelations/ Tutorial materials: Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Tom, On Sun, Jun 28, 2009 at 11:46 PM, Tom Heathtom.he...@talis.com wrote: Martin, 2009/6/27 Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org: So if this hidden div / span approach is not feasible, we got a problem. The reason is that, as beautiful the idea is of using RDFa to make a) the human-readable presentation and b) the machine-readable meta-data link to the same literals, the problematic is it in reality once the structure of a) and b) are very different. For very simple property-value pairs, embedding RDFa markup is no problem. But if you have a bit more complexity at the conceptual level and in particular if there are significant differences to the structure of the presentation (e.g. in terms of granularity, ordering of elements, etc.), it gets very, very messy and hard to maintain. Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. Mmm...you put me in a difficult position here. :) If I leap to RDFa's defence then it looks like I think it solves all the world's problems. But if I remain silent, then it looks like the problem being raised is some kind of fundamental flaw. Ah well, let's dive in... First I should say that I'd be the first to agree that RDFa has limitations. But the issue here is that I don't think the problem raised by Martin can be classed as a limitation in the way you're implying, Tom. If we go back a step, RDFa was carefully designed so that it could carry any combination of the RDF concepts in an HTML document. In the end we dropped reification and lists, because it didn't seem that the RDF community itself was clear on the future of those, but they are both easily added back if the issues were to be resolved. In short, it is possible to use HTML+RDFa to create complete RDF documents, such as RDF Schemas, OWL ontologies, and so on, and the resulting documents would be no more complex than their equivalent RDF/XML or N3 versions, with the benefit that they can be delivered using any of the many HTML publishing techniques currently available. But most of the discussion around RDFa relates to its other use, where it's possible to use it to 'sprinkle' metadata into HTML documents that are primarily aimed at human readers. By being alongside the human-readable output, it makes the metadata easier to maintain. And in addition it gives the user agent the opportunity to enhance the view of the data, by making use of the 'local' metadata. However, the point that Martin was getting at, is that sometimes there is just way more data in the 'RDF view' than in the 'human view', and that makes it very difficult to make the two align. I don't think that this is a flaw in RDFa itself, and I'm not convinced that there is an easy solution in the form of another technology that would solve this. Martin's solution seems a reasonable one to me. (Although I wonder if part of the problem might be that too much information is being provided in the RDF view, rather than using links to other data that can be retrieved. Perhaps Michael could give an example.) Regards, Mark -- Mark Birbeck, webBackplane mark.birb...@webbackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Yihong: I am a big fan of Codd's one fact in one place credo. However, in this particular case, that principle is violated anyway, since the literal values are often duplicated for presentation and meta-data prupolses anyway (think of 2009-06-29 vs. June 29, 2009). Second, for dynamic Web apps, it does not really matter whether the same fact is exposed once or twice, since the central location is one place in the database anyway. Third, this is the only way how a tool like the GoodRelations annotator [1] can create RDFa snippets for simple copy-and-paste into existing pages. Also note that in the particular case of RDFa, the principle of one fact in one place clashes with the separation of concerns principle, in particular, that of keeping data and presentation separate. The textbook-style beauty of simplicity of RDFa holds for adding a dc:creator property to a string value that is the same for presentation and at the data level. Beyond that, RDFa can create code that is very hard to maintain. In fact, I know that a large software company dismissed the use of RDFa in their products because of the unmanageable mix of conceptual and presentation layer. As far as security is concerned: I there is no real difference in my proposal, as the content attribute of RDFa allows serving different data to human and to machines, and this is a needed feature anyway. Digital signatures at the document or element level and / or data provenance approached will likely cater for that. Best Martin Yihong Ding wrote: Hi Kingley and Martin, A potential problem of the model Martin suggested is that the same data has to be presented at least TWICE in one document. Although the RDFa portion of the data is supposed to be automatically generated, it, however, does not prohibit anybody from manually revising it. Therefore, it leaves a huge hole for the hackers (or anybody who want to do some deceptive job). In our imperfect world, this problem is severe. Adding an extra layer of data mapping always causes additional work on data maintenance. This time, the extra work could be a nightmare though the architecture is neat. yihong On Mon, Jun 29, 2009 at 8:03 AM, Kingsley Idehen kide...@openlinksw.comwrote: Martin Hepp (UniBW) wrote: Hi Tom: Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level. body h1This is the car I want to sell/h1 Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009 span ... my whole RDF in RDFa /span body The advantage of that would be that - you just have to maintain ONE file, - data and metadata are close by, so the likelihood of being up to date increases, and - at the same time, the code does not get too messy. - Also - no problems setting up the server (*). - Easy to create on-line tools that generate RDFa snippets for simple pasting. - Yahoo and Google will most likely honor RDFa meta-data only. Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g. dates, country codes,...) I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc. Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description. The main problem with my proposal is that there is the risk that Google considers this cloaking and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index. A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those. Martin, If Google doesn't see invisible DIVs as cloaking, the issue vaporizes. Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa) approach they will at least remain in the Google index via usual SEO oriented keyword gimmickry, albeit generally suboptimal. If we make a recipe doc showcasing these issues, we will more than likely get Google to recalibrate back to the Web;
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
On Mon, 2009-06-29 at 13:30 +0100, Mark Birbeck wrote: If we go back a step, RDFa was carefully designed so that it could carry any combination of the RDF concepts in an HTML document. In the end we dropped reification and lists, because it didn't seem that the RDF community itself was clear on the future of those, but they are both easily added back if the issues were to be resolved. RDF reification and lists do *work* in RDFa, they're just a bit of a pain to mark up. e.g. here's a reification: div xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:db=http://dbpedia.org/resource/; typeof=rdf:Statement span property=dc:creatorMark Birkbeck/span says that span rel=rdf:subject resource=[db:Sky]the sky/span span rel=rdf:predicate resource=http://dbpedia.org/property/color; is/span span rel=rdf:object resource=[db:Blue]blue/span. /div And an example of a list can be found here: http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Toby, Yes...of course...you are right. :) I would say too, that reification is even more long-winded than the example you have given! You don't have the actual statement the sky is blue in your mark-up, so you need even more RDFa. (You only have the statement Mark says 'the sky is blue'.) But either way, you are right that the whole thing can be spelt out longhand (as can lists). The only reason I mentioned it was because for a long time in RDFa we had a much simpler construct based on occurrences of *nested* meta and link properties. However, some browsers thought they were doing us a favour by moving the meta and link elements out of the body and into the head, which meant it was not possible to implement this feature in JavaScript. (Obviously server-side RDFa parsers would have had no problem with it.) As for lists, the obvious shorthand would be ol, ul, and li, but it was not obvious what triples should be generated, so we left it. I.e., your example uses the first/next/nil technique for collections, but of course there is also the rdf:_1 technique for a list. It wasn't immediately clear which would be the more useful -- or conformant -- one to generate. Regards, Mark On Mon, Jun 29, 2009 at 2:05 PM, Toby Inkstert...@g5n.co.uk wrote: On Mon, 2009-06-29 at 13:30 +0100, Mark Birbeck wrote: If we go back a step, RDFa was carefully designed so that it could carry any combination of the RDF concepts in an HTML document. In the end we dropped reification and lists, because it didn't seem that the RDF community itself was clear on the future of those, but they are both easily added back if the issues were to be resolved. RDF reification and lists do *work* in RDFa, they're just a bit of a pain to mark up. e.g. here's a reification: div xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:db=http://dbpedia.org/resource/; typeof=rdf:Statement span property=dc:creatorMark Birkbeck/span says that span rel=rdf:subject resource=[db:Sky]the sky/span span rel=rdf:predicate resource=http://dbpedia.org/property/color; is/span span rel=rdf:object resource=[db:Blue]blue/span. /div And an example of a list can be found here: http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk -- Mark Birbeck, webBackplane mark.birb...@webbackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Mark, 2009/6/29 Mark Birbeck mark.birb...@webbackplane.com: Hi Tom, On Sun, Jun 28, 2009 at 11:46 PM, Tom Heathtom.he...@talis.com wrote: Martin, 2009/6/27 Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org: So if this hidden div / span approach is not feasible, we got a problem. The reason is that, as beautiful the idea is of using RDFa to make a) the human-readable presentation and b) the machine-readable meta-data link to the same literals, the problematic is it in reality once the structure of a) and b) are very different. For very simple property-value pairs, embedding RDFa markup is no problem. But if you have a bit more complexity at the conceptual level and in particular if there are significant differences to the structure of the presentation (e.g. in terms of granularity, ordering of elements, etc.), it gets very, very messy and hard to maintain. Amen. Thank you for writing this. I completely agree. RDFa has some great use cases but (like any technology) has its limitations. Let's not oversell it. Mmm...you put me in a difficult position here. :) ;) If I leap to RDFa's defence then it looks like I think it solves all the world's problems. But if I remain silent, then it looks like the problem being raised is some kind of fundamental flaw. Just in case there's any doubt, let me clarify that this isn't an anti-RDFa position from me, just trying to unpack the issue. Ah well, let's dive in... First I should say that I'd be the first to agree that RDFa has limitations. But the issue here is that I don't think the problem raised by Martin can be classed as a limitation in the way you're implying, Tom. If we go back a step, RDFa was carefully designed so that it could carry any combination of the RDF concepts in an HTML document. In the end we dropped reification and lists, because it didn't seem that the RDF community itself was clear on the future of those, but they are both easily added back if the issues were to be resolved. In short, it is possible to use HTML+RDFa to create complete RDF documents, such as RDF Schemas, OWL ontologies, and so on, and the resulting documents would be no more complex than their equivalent RDF/XML or N3 versions, with the benefit that they can be delivered using any of the many HTML publishing techniques currently available. Absolutely agreed. I don't dispute this at all. Though it's not really my point. See below... But most of the discussion around RDFa relates to its other use, where it's possible to use it to 'sprinkle' metadata into HTML documents that are primarily aimed at human readers. By being alongside the human-readable output, it makes the metadata easier to maintain. In some cases. It depends on the publishing architecture. What effect does it have on the maintenance cost of the layout/structural markup of the page? And in addition it gives the user agent the opportunity to enhance the view of the data, by making use of the 'local' metadata. However, the point that Martin was getting at, is that sometimes there is just way more data in the 'RDF view' than in the 'human view', and that makes it very difficult to make the two align. Yes, this is exactly how I understood his point. It's also exactly why I keep banging on about us not saying that x is better than y. It's not about a limitation of RDFa as a technology (apologies if it came across that way), simply a reflection of the fact that it can be challenging to deploy in some circumstances. Again, this is context dependent, and the best solution can only be determined by examining that context. I don't think that this is a flaw in RDFa itself, Agreed. and I'm not convinced that there is an easy solution in the form of another technology that would solve this. Well, such cases may justify the 303/conneg pattern. Martin's solution seems a reasonable one to me. (Although I wonder if part of the problem might be that too much information is being provided in the RDF view, rather than using links to other data that can be retrieved. Perhaps Michael could give an example.) Completely agreed on this point. You'll see this approach manifested in Revyu.com, where there is redundancy in data between HTML pages for the sake of presenting human users with a more complete view (without requiring them to visit multiple pages); the same is not true of the (broadly) equivalent RDF documents, where I tried to avoid redundancy, on the basis that any SW agent worth it's salt should be able to dereference the referenced URIs to retrieve the data it needs. IIRC others disagree with my approach here (TimBL? Richard C?), but this speaks completely to the question of what is the appropriate interaction paradigm for apps built on the Web of Data. If we can understand the answers to this question then it may help guide our deployment strategies for RDFa. Cheers, Tom.
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
On Jun 28, 2009, at 6:39 PM, Tim Berners-Lee wrote: On 2009-06 -25, at 13:29, Pat Hayes wrote: On Jun 25, 2009, at 11:44 AM, Martin Hepp (UniBW) wrote: Hi all: After about two months of helping people generate RDF/XML metadata for their businesses using the GoodRelations annotator [1], I have quite some evidence that the current best practices of using .htaccess are a MAJOR bottleneck for the adoption of Semantic Web technology. I agree, and raised this issue with the W3C TAG some time ago. It was apparently not taken seriously. The general consensus seemed to be that any normal adult should be competent to manipulate an Apache server. (Was yours a deliberate sarcastic misrepresentation of the TAG's consensus, or a genuine misunderstanding? A genuine misunderstanding, based on the personal feedback I got, I admit, rather than a careful perusal of the TAG published decisions, my bad. ) The TAG has expressed that the fact that Apache needs root intervention when it doesn't have the right mime type set up is a serious bug. Well, Im glad to hear that, and apologize for not knowing it. But as I said in my reply to Tom, that doesn't help me actually use the SWeb from out here in the one-way side roads off the information superhighway. My own company, however, refuses to allow its employees to have access to .htaccess files, and I am therefore quite unable to conform to the current best practice from my own work situation. I believe that this situation is not uncommon. So you mean you can't set up content negotiation and redirection. Right. As I discovered when I was trying to follow the http-range-14 decision and experiment with my notorious 'PatHayes' self-referential page, in order to bring it into line with the recommendations. Talk about eating dog food... But you can use foo#bar URIs like I do. True. Will the company allow a mime.types file to include application/rdf +xml? No problem there, AFAIK. Pat Tim 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: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
On Jun 28, 2009, at 6:20 PM, Tom Heath wrote: Hi Pat, 2009/6/25 Pat Hayes pha...@ihmc.us: With the sincerest respect, Tom, your attitude here is part of the problem. Maybe, along with many other people, I am indeed still stuck in the mid-1990s. You have permission to be as condescending as you like. But still, here I am, stuck. Thoroughly stuck. So no amount of condescending sooo-20th-century, my dear chatter is going to actually enable me to get to a place where I can do what you think I should be doing. Condescension was never my intention here. My goal was to draw a comparison that might enable us to learn a lesson from the history of the Web and use that to help us move forward. As Mark described, over the course of time more and more tools became available that made it easier to publish HTML. Presumably these only arose because publishing HTML was to some degree hard. The Web community has gone through this process once already; let's learn the lessons from last time and apply them to publishing RDF so people don't have to be stuck any more. Um.. I thought that was MY point :-) Dan outlined some technical approaches to doing this sort of thing. Some domain-specific apps already exist that (hopefully) reduce the pain; it was one of the goals of Revyu.com for example. I cannot use a rewrite rule to catch incoming requests, or do whatever you are talking about here. I live in an environment where I simply do not have access at all to the workings of my server at a level that close to the metal, because it is already woven into a clever maze of PHP machinery which is too fragile to allow erks like me to mess with it. Some of the best W3C techies have taken a look, and they can't find a way through it, either. Maybe Im in a special position, but I bet a whole lot of people, especially in the corporate world, are in a similar bind. You're talking about two very different groups here. If the right tools are created then individuals will presumably adopt some specialised SaaS analogous to say wordpress.com. Corporations are a different kettle of fish I work for a small research company which happens to have an ambitious Webmaster and a Director who is sensitive to visual graphics and Web image issues. The result is a maze of complex PHP giving users a very nice experience, but not conducive to transparent use by its inhabitants. Just from casual Web browsing, I cannot believe that I am in a very small minority. There are a lot of 'sexy' sites out there that must be in a similar state. I know that several 'web authoring' systems produce similar PHP mazes, because Ive tried using them and then editing the output they produce, an experience rather like debugging BCPL. , but just as many built their own Web-serving infrastructure in the 90s, so they will invest in publishing data to the Semantic Web if they perceive adequate value (demonstrating that value is where we need to be working even harder!). System level access to a server is quite a different beast than being allowed to publish HTML on a website somewhere. I can, and do, publish HTML, or indeed just about any file I like, but I don't get to insert code. So 6 lines or 600, it makes no difference. But in any case, this is ridiculous. RDF is just XML text, for goodness sake. I need to insert lines of code into a server file, and write PHP scripts, in order to publish some RDF or HTML? That is insane. It would have been insane in the mid-1990s and its even more insane now. No. This is incorrect. This discussion only applies to the 303-redirect/slash URI pattern. You can avoid this completely by using the hash URI pattern as someone mentioned (sorry for not crediting directly, getting hard to navigate this thread). Yes, of course, and I apologize for overstating the case. Still, the slash-URI seems to be much more acceptable to many unsemantic Webbies, who are used to thinking of URIs as being stripped of their post-hash content at the slightest internet shiver, so don't regard a name including a hash as something 'real'; and it is the case about which all the fuss is being made. If the published advice was: always use hash URI patterns, I would be happy. But the published advice *starts* with 303 redirects and .htaccess file modifications. IMO, it is you (and Tim and the rest of the W3C) who are stuck in the past here. Most Web users do not, and will not, write code. They will be publishing content in a cloud somewhere, even further away from the gritty world of scripts and lines of code than people - most people - are now. Most actual content providers are never going to want to even know that PHP scripts exist, let alone be obliged to write or copy one. You've over-interpreted my words here. See above. If so, I apologise. But think of what Im saying as a cry for help. There are a lot of people like me, I suspect, who would really like
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
On Mon, 2009-06-29 at 01:20 +0200, Tom Heath wrote: [ . . . ] This discussion only applies to the 303-redirect/slash URI pattern. You can avoid this completely by using the hash URI pattern . . . . And as a reminder, you can also use a 303-redirect service if you cannot configure your server, such as: http://thing-described-by.org/ For example, http://thing-described-by.org?http://dbooth.org/2005/dbooth/ does a 303 redirect to http://dbooth.org/2005/dbooth/ That last one doesn't happen to serve RDF, but it certainly could. -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Hi Pat, OK, yelling heard loud and clear :) By way of concrete actions, I gave Ivan Herman a (probably unfairly) hard time today here at Dagstuhl to 'encourage' the authors of the Vocabs Best Practices to press on with the revision of that document that addresses the current issues. An update of the How to Publish Linked Data on the Web tutorial is also on the cards; perhaps one of the outcomes of this revision could be a greater emphasis on the hash URI pattern (and maybe also the 'health warning' you describe ;). Cheers, Tom. 2009/6/29 Pat Hayes pha...@ihmc.us: On Jun 28, 2009, at 6:20 PM, Tom Heath wrote: Hi Pat, 2009/6/25 Pat Hayes pha...@ihmc.us: With the sincerest respect, Tom, your attitude here is part of the problem. Maybe, along with many other people, I am indeed still stuck in the mid-1990s. You have permission to be as condescending as you like. But still, here I am, stuck. Thoroughly stuck. So no amount of condescending sooo-20th-century, my dear chatter is going to actually enable me to get to a place where I can do what you think I should be doing. Condescension was never my intention here. My goal was to draw a comparison that might enable us to learn a lesson from the history of the Web and use that to help us move forward. As Mark described, over the course of time more and more tools became available that made it easier to publish HTML. Presumably these only arose because publishing HTML was to some degree hard. The Web community has gone through this process once already; let's learn the lessons from last time and apply them to publishing RDF so people don't have to be stuck any more. Um.. I thought that was MY point :-) Dan outlined some technical approaches to doing this sort of thing. Some domain-specific apps already exist that (hopefully) reduce the pain; it was one of the goals of Revyu.com for example. I cannot use a rewrite rule to catch incoming requests, or do whatever you are talking about here. I live in an environment where I simply do not have access at all to the workings of my server at a level that close to the metal, because it is already woven into a clever maze of PHP machinery which is too fragile to allow erks like me to mess with it. Some of the best W3C techies have taken a look, and they can't find a way through it, either. Maybe Im in a special position, but I bet a whole lot of people, especially in the corporate world, are in a similar bind. You're talking about two very different groups here. If the right tools are created then individuals will presumably adopt some specialised SaaS analogous to say wordpress.com. Corporations are a different kettle of fish I work for a small research company which happens to have an ambitious Webmaster and a Director who is sensitive to visual graphics and Web image issues. The result is a maze of complex PHP giving users a very nice experience, but not conducive to transparent use by its inhabitants. Just from casual Web browsing, I cannot believe that I am in a very small minority. There are a lot of 'sexy' sites out there that must be in a similar state. I know that several 'web authoring' systems produce similar PHP mazes, because Ive tried using them and then editing the output they produce, an experience rather like debugging BCPL. , but just as many built their own Web-serving infrastructure in the 90s, so they will invest in publishing data to the Semantic Web if they perceive adequate value (demonstrating that value is where we need to be working even harder!). System level access to a server is quite a different beast than being allowed to publish HTML on a website somewhere. I can, and do, publish HTML, or indeed just about any file I like, but I don't get to insert code. So 6 lines or 600, it makes no difference. But in any case, this is ridiculous. RDF is just XML text, for goodness sake. I need to insert lines of code into a server file, and write PHP scripts, in order to publish some RDF or HTML? That is insane. It would have been insane in the mid-1990s and its even more insane now. No. This is incorrect. This discussion only applies to the 303-redirect/slash URI pattern. You can avoid this completely by using the hash URI pattern as someone mentioned (sorry for not crediting directly, getting hard to navigate this thread). Yes, of course, and I apologize for overstating the case. Still, the slash-URI seems to be much more acceptable to many unsemantic Webbies, who are used to thinking of URIs as being stripped of their post-hash content at the slightest internet shiver, so don't regard a name including a hash as something 'real'; and it is the case about which all the fuss is being made. If the published advice was: always use hash URI patterns, I would be happy. But the published advice *starts* with 303 redirects and .htaccess file modifications. IMO, it is you (and Tim and the rest of the W3C) who are
how do I report bad sameAs links? (dbpedia - Cyc)
http://sw.opencyc.org/2008/06/10/concept/Mx4rv8L0_JwpEbGdrcN5Y29ycA says it is owl:sameAs dbpedia:Spaced And DBpedia reports the same. They're both wrong! The DBpedia page is about a television situation comedy show; the Cyc page is about a freeware computer game. cheers, Dan
