Re: http://ld2sd.deri.org/lod-ng-tutorial/
Just a remark about what we're doing in Sindice, for all who want to be indexed properly by us. we recursively dereference the properties that are used thus trying to obtain a closure over the description of the properties that are used. We also consider OWL imports. When the recursive fetching is computer, we apply RDFS + some owl reasoning (OWLIM being the final reasoner at the moment) and index it. We are currently working on a public validator where people can try their files and see the full chain of fetching/inference. Giovanni On Mon, Jun 22, 2009 at 7:42 PM, Martin Hepp (UniBW)martin.h...@ebusiness-unibw.org wrote: Hi Michael: (moving this to LOD public as suggested) General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. As for owl:imports: When importing an ontology by owl:imports, you commit to the whole formal account of that ontology. If you just include an element from that ontology by using it and hope that dereferencing will get the relevant formal account in your model, you expose your model to randomness - you don't know what subset of the formal account you will get served. Ontology modularization is a pretty difficult task, and people use various heuristics for deciding what to put in the subset being served for an element. There is no guarantee that the fragment you get contains everything that you need. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Best Martin Michael Hausenblas wrote: Martin, As an aside: I think I proposed already once to not have this discussion in a private circle of 'randomly' selected people but rather in the appropriate lists (rdfa public or public-lod). However, if you prefer to continue here, we continue here, FWIW. In my opinion the owl:imports stems from a time where people confused publishing on the Semantic Web with firing up Protege and clicking around like wild. So, concluding, for me it is not obvious to use owl:imports and I don't see *any* benefit from using it. Not in RDF/XML and also not in RDFa ;) you know that i sometimes appreciate your opinion ;-), Yeah, same here :D ... but i think it is pretty questionable to break with well-defined standards specifications for just a matter of gut feeling and personal preference. Ok, let me rephrase this. You, or whoever publishes RDFa can of course do whatever she likes. Wanna use owl:imports? Fine. Don't wanna use it. Ok! The point I was trying to make (not very successfully, though): from a linked data perspective (and basically this is what Richard and I try to achieve here; offering good practices for linked data *in* RDFa) the usage of owl:imports is, how to put it, not encouraged. So far I have not heard any convincing argument from you why one should use it, but I'm happy and open to learn. Cheers, Michael -- -- 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
Re: http://ld2sd.deri.org/lod-ng-tutorial/
On 22/6/09 23:16, Martin Hepp (UniBW) wrote: Yves Raimond wrote: Ontology modularization is a pretty difficult task, and people use various heuristics for deciding what to put in the subset being served for an element. There is no guarantee that the fragment you get contains everything that you need. There is no safe way of importing only parts of an ontology, unless you know that its modularization is 100% reliable. Serving fragments of likely relevant parts of an ontology for reducing the network overhead is not the same as proper modularization of the ontology. Can you give a concrete example of the danger described here? ie. the pair of a complete (safe) ontology file and a non-safe subset, and an explanation of the problems caused. I can understand there is no guarantee that the fragment you get contains everything you need, and I also remind everyone that dereferencing is a privilege not a right: sometimes the network won't give you what you want, when you want it. But I've yet to hear of anyone who has suffered due to term-oriented ontology fragment downloads. I guess medical ontologies would be the natural place for horror stories? cheers, Dan
Re: http://ld2sd.deri.org/lod-ng-tutorial/
Hi Dan: I think Alan already gave examples this morning. An ontology can contain statements about the relationship between conceptual elements - classes, properties, individuals - that (1) influence the result to queries but (2) are not likely retrieved when you just dereference an element from that ontology. The more complex an ontology is, the more difficult is it to properly modularize it. But basically my main point is that the use of owl:imports is defined pretty well in http://www.w3.org/TR/owl-ref/#imports-def and there is no need to deviate from the spec just for the matter of gut feeling and annoyance about the past dominance of DL research in the field. And as the spec says - with a proper owl:imports statement, any application can decide if and what part of the imported ontologies are being included to the local model for the task at hand. Martin Dan Brickley wrote: On 22/6/09 23:16, Martin Hepp (UniBW) wrote: Yves Raimond wrote: Ontology modularization is a pretty difficult task, and people use various heuristics for deciding what to put in the subset being served for an element. There is no guarantee that the fragment you get contains everything that you need. There is no safe way of importing only parts of an ontology, unless you know that its modularization is 100% reliable. Serving fragments of likely relevant parts of an ontology for reducing the network overhead is not the same as proper modularization of the ontology. Can you give a concrete example of the danger described here? ie. the pair of a complete (safe) ontology file and a non-safe subset, and an explanation of the problems caused. I can understand there is no guarantee that the fragment you get contains everything you need, and I also remind everyone that dereferencing is a privilege not a right: sometimes the network won't give you what you want, when you want it. But I've yet to hear of anyone who has suffered due to term-oriented ontology fragment downloads. I guess medical ontologies would be the natural place for horror stories? cheers, Dan -- -- 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: http://ld2sd.deri.org/lod-ng-tutorial/
Martin, (moving this to LOD public as suggested) Thanks. General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. I don't think it is particular helpful to insult people, to utter imputations and judge a book by its cover. If we can agree to stop using such terminology I'm more than happy to continue the discussion. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Ok, so, again, for the chaps who didn't get the entire story. Martin champions the use of owl:import (and wants to see it written down as a good practice?) in linked data. My take on this is as follows: when one takes the linked data principles and applies them in practice (esp. referring to #2, here) there are naturally a dozens implementation choices as the principles simply leave room for interpretation. The people here know me from the RDFa TF, from the AWWSW TF and last but not least from the LOD community as a simple-minded, pragmatic guy, I hope ;) So, my hunch would be: the market will make the final decision, not a Martin Hepp and also not a Michael Hausenblas. If people think this is a clever idea, they will use it when publishing linked data. AFAIK, to date the usage of owl:import in linked data is close to non-existing (even in pre-LOD times it seemed to be not very common [1]). Concluding, I'd propose - respecting the nature of good *practice* - once we notice a serious usage of owl:import in LOD data, we may want to rehash this topic. Cheers, Michael [1] http://ebiquity.umbc.edu/blogger/2007/06/15/how-owlimport-is-used/ -- Dr. Michael Hausenblas 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 From: Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org Organization: http://www.heppnetz.de Reply-To: martin.h...@ebusiness-unibw.org Date: Mon, 22 Jun 2009 20:42:23 +0200 To: Michael Hausenblas michael.hausenb...@deri.org Cc: h...@ebusiness-unibw.org, Richard Cyganiak rich...@cyganiak.de, Hepp, Martin mh...@computer.org, Hugh Glaser h...@ecs.soton.ac.uk, mark.birb...@webbackplane.com, Booth, David (HP Software - Boston) dbo...@hp.com, Linked Data community public-lod@w3.org Subject: Re: http://ld2sd.deri.org/lod-ng-tutorial/ Hi Michael: (moving this to LOD public as suggested) General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. As for owl:imports: When importing an ontology by owl:imports, you commit to the whole formal account of that ontology. If you just include an element from that ontology by using it and hope that dereferencing will get the relevant formal account in your model, you expose your model to randomness - you don't know what subset of the formal account you will get served. Ontology modularization is a pretty difficult task, and people use various heuristics for deciding what to put in the subset being served for an element. There is no guarantee that the fragment you get contains everything that you need. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Best Martin Michael Hausenblas wrote: Martin, As an aside: I think I proposed already once to not have this discussion in a private circle of 'randomly' selected people but rather in the appropriate lists (rdfa public or public-lod). However, if you prefer to continue here, we continue here, FWIW. In my opinion the owl:imports stems
Re: http://ld2sd.deri.org/lod-ng-tutorial/
On 23/6/09 09:33, Martin Hepp (UniBW) wrote: Hi Dan: I think Alan already gave examples this morning. An ontology can contain statements about the relationship between conceptual elements - classes, properties, individuals - that (1) influence the result to queries but (2) are not likely retrieved when you just dereference an element from that ontology. The more complex an ontology is, the more difficult is it to properly modularize it. Indeed, I missed his mail until after I'd sent mine. And the examples are helpful. However they are - for the non-SemWeb enthusiast - incredibly abstract: FunctionalObjectProperty(p) InverseFunctionalObjectProperty(p) ObjectPropertyDomain(:a) ObjectPropertyRange(:b) etc. What I'd love to see is some flesh on these bones: a wiki page that works through these cases in terms of a recognisable example. Products, people, documents, employees, access control, diseases, music, whatever. I want something I can point to that says this is why it is important to take care of the formalisms..., this is what we can do so that simple-minded but predictable machines do the hard work instead of us But basically my main point is that the use of owl:imports is defined pretty well in http://www.w3.org/TR/owl-ref/#imports-def and there is no need to deviate from the spec just for the matter of gut feeling and annoyance about the past dominance of DL research in the field. And as the spec says - with a proper owl:imports statement, any application can decide if and what part of the imported ontologies are being included to the local model for the task at hand. +1 on respecting the specs, but also all know that not every piece of specification finds itself useful in practice. Having a worked-through to the instance level account of why owl:imports is useful would help. There is no compulsion re standards here: if someone is happy publishing RDFS, we can't make them use OWL. If they're happy using OWL we can't make them use RIF. If they're happy with RIF 1, we can't make them use RIF 2 etc. Or any particular chapter or verse of those specs. What we can do is ground our evangelism in practical examples. And for those to be compelling, they can't solely be at the level of properties of properties; we need an account in terms of instance level use cases too. cheers, Dan
Re: http://ld2sd.deri.org/lod-ng-tutorial/
Martin, It was not my intend to insult anybody. Thank you. And Michael, please be frank - there is a tendency in the LOD community which goes along the lines of OWL and DL-minded SW research has proven obsolete anyway, so we LOD guys and girls just pick and use the bits and pieces we like and don't care about the rest. Your words, not mine ;) What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. Exactly the opposite of I will use this pragmatic pattern until it breaks but instead architectural beauty for eternity. While simplicity makes it possible to deploy an initial implementation of a distributed system, extensibility allows us to avoid getting stuck forever with the limitations of what was deployed. From the seminal paper 'Principled Design of the Modern Web Architecture' by Roy T. Fielding and Richard N. Taylor [1]. Agree. Cheers, Michael [1] http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf -- Dr. Michael Hausenblas 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 From: Martin Hepp (UniBW) martin.h...@ebusiness-unibw.org Organization: http://www.heppnetz.de Reply-To: martin.h...@ebusiness-unibw.org Date: Tue, 23 Jun 2009 11:01:19 +0200 To: Michael Hausenblas michael.hausenb...@deri.org Cc: mark.birb...@webbackplane.com, David Booth da...@dbooth.org, Linked Data community public-lod@w3.org Subject: Re: http://ld2sd.deri.org/lod-ng-tutorial/ It was not my intend to insult anybody. But I still don't get why some of you want to recommend a pattern that breaks with a current W3C recommendation just on the basis that there are many documents out there that break with it. The Swoogle post from 2007 simply says that there are many documents out there that are not using it properly. But there are also many RDF resources out there that break with LOD principles and LOD recommendations and nobody would dare to question the principles solely on the basis of bad implementations. And Michael, please be frank - there is a tendency in the LOD community which goes along the lines of OWL and DL-minded SW research has proven obsolete anyway, so we LOD guys and girls just pick and use the bits and pieces we like and don't care about the rest. As Kingsley said - deceptively simple solutions are cheap in the beginning but can be pretty costly in the long run. What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. Exactly the opposite of I will use this pragmatic pattern until it breaks but instead architectural beauty for eternity. Just look at the http specs. The fact that you can do a nice 303 is because someone in the distant past very cleverly designed a protocol goes well beyond the pragmatic I have a URL (sic!) and want to fetch the Web page in HTML (sic!). So when being proud of being the pragmatic guys keep in mind that nothing is as powerful in practice as something that is theoretically consistent. Best Martin Michael Hausenblas wrote: Martin, (moving this to LOD public as suggested) Thanks. General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. I don't think it is particular helpful to insult people, to utter imputations and judge a book by its cover. If we can agree to stop using such terminology I'm more than happy to continue the discussion. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Ok, so, again, for the chaps who didn't get the entire story. Martin champions the use of owl:import (and wants to see it written down as a good practice?) in linked data. My take on this is as follows: when one takes the linked data principles and applies them in practice (esp. referring to #2, here) there are naturally a dozens implementation choices as the principles simply leave room for interpretation. The people here know me from the RDFa TF, from the AWWSW TF and last but not least from the LOD community as a
RDFa vs RDF/XML and content negotiation
I've been trying to weigh up the pros and cons of these two approaches to understand more clearly when you might want to use each. I hope that the list members will be able to provide me with the benefit of their experience and insight! So the situation is that I have some information on a topic and I want to make it available both in machine readable form and in human readable form, for example a company wanting to publish information on its products, or a government department wanting to publish some statistics. I can either: 1) include 'human' and 'machine' representations in the same web page using RDFa 2) have an HTML representation and a separate RDF/XML representation (or N3 or whatever) and decide which to provide via HTTP content negotiation. So which should I use? I suppose it depends on how the information will be produced, maintained and consumed. Some generic requirements/wishes: - I only want to have one place where the data is managed. - I want people to be able to browse around a nicely formatted representation of the information, ie a regular web page, probably incorporating all sorts of other stuff as well as the data itself. - I don't want to type lots of XHTML or XML. - I want the data to be found and used by search engines and aggregators. The approach presented by Halb, Raimond and Hausenblas ( http://events.linkeddata.org/ldow2008/papers/06-halb-raimond-building-linked-data.pdf) seems attractive: to summarise crudely, auto-generate some RDFa from your database, but provide an RDF/XML dump too. On the other hand I find that RDFa leads to rather messy markup - I prefer the 'cleanliness' of the separate representations. For any non-trivial amount of data, then we will need a templating engine of some sort for either approach. I suppose what may tip the balance is that Yahoo and Google are starting to make use of RDFa, but AFAIK they are not (yet) doing anything with classic content-negotiated linked data. Anyone care to argue for one approach or the other? I suppose the answer may well be it depends :-) But if so, what does it depend on? Thanks in advance Bill Roberts
Re: Common Tag - semantic tagging convention
On Tue, 2009-06-23 at 12:37 +0100, Pierre-Antoine Champin wrote: Le 18/06/2009 16:46, Alexandre Passant a écrit : I just reply to an e-mail from Toby on the topic on the commontag ml. Since the archives are not yet public, let-me repost my point about the mappings here. A Tag in common tag is a tag a seen in Newman's ontology. My understanding of Newman's ontology is that the URI tag:cheese (for example) represent every occurence of the string cheese used as a tag. This cannot work with common tag, since cheese can be used: - on resource R1 at date D1 as an AuthorTag - on resource R2 at date D2 as a ReaderTag This practically forces us to define two distinct Tag resources, both with the label cheese, but with different types and taggingDate. Of course, nothing prevents us from using the same resource, but in that case, we would not know anymore which date and which tag type correspond to which resource... So the design of Common Tag implies that Tag resources should not be reused across different tagging actions, which IMHO makes them quite different from Newman's Tags (and close to Tagging, in fact). Yes, exactly, that is the case. pa -- Andraz Tori, CTO Zemanta Ltd, New York, London, Ljubljana www.zemanta.com mail: and...@zemanta.com tel: +386 41 515 767 twitter: andraz, skype: minmax_test
Re: RDFa vs RDF/XML and content negotiation
On Tue, 2009-06-23 at 13:09 +0100, Toby Inkster wrote: For my railway data http://ontologi.es/rail/ I publish static XHTML +RDFa files (all but two of which are generated by script) and use a combination of Apache .htaccess files and small PHP scripts to dynamically generate other formats (JSON, RDF/XML, N-Triples, Turtle) on request. Just to clarify, when I say dynamically generate I mean by parsing the XHTML+RDFa off disk and into memory and then dumping it out in the requested format. So essentially, I'm just publishing XHTML+RDFa and leaving the web server to generate other formats from it when needed. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: http://ld2sd.deri.org/lod-ng-tutorial/
Martin, [SNIP] As Kingsley said - deceptively simple solutions are cheap in the beginning but can be pretty costly in the long run. I meant: Deceptively Simple is good. While Simply Simple is bad due to inherent architectural myopia obscured by initial illusion of cheapness etc.. What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. That's what I meant by: Deceptively Simple, architectural apex is narrow (simple) while the base is broad (a pyramid) :-) Exactly the opposite of I will use this pragmatic pattern until it breaks but instead That's what I meant by: Simple Simple, architectural apex is broad while the base is narrow (think inverted pyramid). architectural beauty for eternity. Yes! That what you get with: Deceptively Simple :-) Kingsley Just look at the http specs. The fact that you can do a nice 303 is because someone in the distant past very cleverly designed a protocol goes well beyond the pragmatic I have a URL (sic!) and want to fetch the Web page in HTML (sic!). So when being proud of being the pragmatic guys keep in mind that nothing is as powerful in practice as something that is theoretically consistent. Best Martin Michael Hausenblas wrote: Martin, (moving this to LOD public as suggested) Thanks. General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. I don't think it is particular helpful to insult people, to utter imputations and judge a book by its cover. If we can agree to stop using such terminology I'm more than happy to continue the discussion. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Ok, so, again, for the chaps who didn't get the entire story. Martin champions the use of owl:import (and wants to see it written down as a good practice?) in linked data. My take on this is as follows: when one takes the linked data principles and applies them in practice (esp. referring to #2, here) there are naturally a dozens implementation choices as the principles simply leave room for interpretation. The people here know me from the RDFa TF, from the AWWSW TF and last but not least from the LOD community as a simple-minded, pragmatic guy, I hope ;) So, my hunch would be: the market will make the final decision, not a Martin Hepp and also not a Michael Hausenblas. If people think this is a clever idea, they will use it when publishing linked data. AFAIK, to date the usage of owl:import in linked data is close to non-existing (even in pre-LOD times it seemed to be not very common [1]). Concluding, I'd propose - respecting the nature of good *practice* - once we notice a serious usage of owl:import in LOD data, we may want to rehash this topic. Cheers, Michael [1] http://ebiquity.umbc.edu/blogger/2007/06/15/how-owlimport-is-used/ -- -- 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 -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: RDFa vs RDF/XML and content negotiation
Just RDFa and live happy IMO. A machine doesnt care about the messy part of the markup. The advantage of a single URL to access it too much to be a match for anything. It is a fact that people like us like to look at RDF directly as well. But it should be a problem to use a firefox plugin to extract the RDF Giovanni On Tue, Jun 23, 2009 at 12:09 PM, bill.robe...@planet.nl wrote: I've been trying to weigh up the pros and cons of these two approaches to understand more clearly when you might want to use each. I hope that the list members will be able to provide me with the benefit of their experience and insight! So the situation is that I have some information on a topic and I want to make it available both in machine readable form and in human readable form, for example a company wanting to publish information on its products, or a government department wanting to publish some statistics. I can either: 1) include 'human' and 'machine' representations in the same web page using RDFa 2) have an HTML representation and a separate RDF/XML representation (or N3 or whatever) and decide which to provide via HTTP content negotiation. So which should I use? I suppose it depends on how the information will be produced, maintained and consumed. Some generic requirements/wishes: - I only want to have one place where the data is managed. - I want people to be able to browse around a nicely formatted representation of the information, ie a regular web page, probably incorporating all sorts of other stuff as well as the data itself. - I don't want to type lots of XHTML or XML. - I want the data to be found and used by search engines and aggregators. The approach presented by Halb, Raimond and Hausenblas ( http://events.linkeddata.org/ldow2008/papers/06-halb-raimond-building-linked-data.pdf) seems attractive: to summarise crudely, auto-generate some RDFa from your database, but provide an RDF/XML dump too. On the other hand I find that RDFa leads to rather messy markup - I prefer the 'cleanliness' of the separate representations. For any non-trivial amount of data, then we will need a templating engine of some sort for either approach. I suppose what may tip the balance is that Yahoo and Google are starting to make use of RDFa, but AFAIK they are not (yet) doing anything with classic content-negotiated linked data. Anyone care to argue for one approach or the other? I suppose the answer may well be it depends :-) But if so, what does it depend on? Thanks in advance Bill Roberts
Re: http://ld2sd.deri.org/lod-ng-tutorial/
Martin, partially you could solve the problem yourself by putting the owl:import triples in your ontology fragments e.g. the fragment, when served, says owl import so that you're sure the ontology is used as a whole.. would this do it? :-) fixing the problem in a single location might be so much easier than expecting all to fix it at their side (remember.. they see no advantage in it, just extra triples) Giovanni On Tue, Jun 23, 2009 at 10:01 AM, Martin Hepp (UniBW)martin.h...@ebusiness-unibw.org wrote: It was not my intend to insult anybody. But I still don't get why some of you want to recommend a pattern that breaks with a current W3C recommendation just on the basis that there are many documents out there that break with it. The Swoogle post from 2007 simply says that there are many documents out there that are not using it properly. But there are also many RDF resources out there that break with LOD principles and LOD recommendations and nobody would dare to question the principles solely on the basis of bad implementations. And Michael, please be frank - there is a tendency in the LOD community which goes along the lines of OWL and DL-minded SW research has proven obsolete anyway, so we LOD guys and girls just pick and use the bits and pieces we like and don't care about the rest. As Kingsley said - deceptively simple solutions are cheap in the beginning but can be pretty costly in the long run. What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. Exactly the opposite of I will use this pragmatic pattern until it breaks but instead architectural beauty for eternity. Just look at the http specs. The fact that you can do a nice 303 is because someone in the distant past very cleverly designed a protocol goes well beyond the pragmatic I have a URL (sic!) and want to fetch the Web page in HTML (sic!). So when being proud of being the pragmatic guys keep in mind that nothing is as powerful in practice as something that is theoretically consistent. Best Martin Michael Hausenblas wrote: Martin, (moving this to LOD public as suggested) Thanks. General note: I am quite unhappy with a general movement in parts of the LOD community to clash with the OWL world even when that is absolutely unnecessary. It is just a bad engineering practice to break with existing standards unless you can justify the side-effects. And this stubborn i don't care what the OWL specs says pattern is silly, in particular if the real motivation of many proponents of this approach is that they don't want or cannot read the OWL specs. I don't think it is particular helpful to insult people, to utter imputations and judge a book by its cover. If we can agree to stop using such terminology I'm more than happy to continue the discussion. On the other hand - what is your pain with using RDFa in a way so that the extracted RDF model is equivalent to the model from an RDF/XML or N3 serialization? Why this absolutely arbitrary we LOD guys don't like owl:import ( we don't like OWL anyway, you know?), so we simply omit it behavior? It is just silly to break with established standards just for saving 1 - 2 triples. Ok, so, again, for the chaps who didn't get the entire story. Martin champions the use of owl:import (and wants to see it written down as a good practice?) in linked data. My take on this is as follows: when one takes the linked data principles and applies them in practice (esp. referring to #2, here) there are naturally a dozens implementation choices as the principles simply leave room for interpretation. The people here know me from the RDFa TF, from the AWWSW TF and last but not least from the LOD community as a simple-minded, pragmatic guy, I hope ;) So, my hunch would be: the market will make the final decision, not a Martin Hepp and also not a Michael Hausenblas. If people think this is a clever idea, they will use it when publishing linked data. AFAIK, to date the usage of owl:import in linked data is close to non-existing (even in pre-LOD times it seemed to be not very common [1]). Concluding, I'd propose - respecting the nature of good *practice* - once we notice a serious usage of owl:import in LOD data, we may want to rehash this topic. Cheers, Michael [1] http://ebiquity.umbc.edu/blogger/2007/06/15/how-owlimport-is-used/ -- -- 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!
Re: RDFa vs RDF/XML and content negotiation
Bill, It will certainly not surprise you that I'd suggest to go for (technically speaking) linked data with RDFa. However, we have sort of started to collect a checklist you might want to review [1]. Anyone care to argue for one approach or the other? I suppose the answer may well be it depends :-) But if so, what does it depend on? Can depend, in my experience, for example on: + granularity (fine-grained, multidimensional statistical data vs. DC author/title thing) + dynamics (is it a one-shot or does the data change with time like on a blog, etc.) Cheers, Michael [1] http://ld2sd.deri.org/lod-ng-tutorial/#checklist [2] http://linkeddata.deri.ie/services -- Dr. Michael Hausenblas 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 From: bill.robe...@planet.nl Date: Tue, 23 Jun 2009 13:09:32 +0200 To: Linked Data community public-lod@w3.org Subject: RDFa vs RDF/XML and content negotiation Resent-From: Linked Data community public-lod@w3.org Resent-Date: Tue, 23 Jun 2009 11:45:59 + I've been trying to weigh up the pros and cons of these two approaches to understand more clearly when you might want to use each. I hope that the list members will be able to provide me with the benefit of their experience and insight! So the situation is that I have some information on a topic and I want to make it available both in machine readable form and in human readable form, for example a company wanting to publish information on its products, or a government department wanting to publish some statistics. I can either: 1) include 'human' and 'machine' representations in the same web page using RDFa 2) have an HTML representation and a separate RDF/XML representation (or N3 or whatever) and decide which to provide via HTTP content negotiation. So which should I use? I suppose it depends on how the information will be produced, maintained and consumed. Some generic requirements/wishes: - I only want to have one place where the data is managed. - I want people to be able to browse around a nicely formatted representation of the information, ie a regular web page, probably incorporating all sorts of other stuff as well as the data itself. - I don't want to type lots of XHTML or XML. - I want the data to be found and used by search engines and aggregators. The approach presented by Halb, Raimond and Hausenblas ( http://events.linkeddata.org/ldow2008/papers/06-halb-raimond-building-linked-d ata.pdf) seems attractive: to summarise crudely, auto-generate some RDFa from your database, but provide an RDF/XML dump too. On the other hand I find that RDFa leads to rather messy markup - I prefer the 'cleanliness' of the separate representations. For any non-trivial amount of data, then we will need a templating engine of some sort for either approach. I suppose what may tip the balance is that Yahoo and Google are starting to make use of RDFa, but AFAIK they are not (yet) doing anything with classic content-negotiated linked data. Anyone care to argue for one approach or the other? I suppose the answer may well be it depends :-) But if so, what does it depend on? Thanks in advance Bill Roberts
Re: http://ld2sd.deri.org/lod-ng-tutorial/
Hi Kingsley, You are of course right - I assume that, despite the terminological mess I introduced, you agree with my line of argument; I fully acknowledge it is heavily inspired by our San Jose sushi talk ;-) Martin Kingsley Idehen wrote: Martin, [SNIP] As Kingsley said - deceptively simple solutions are cheap in the beginning but can be pretty costly in the long run. I meant: Deceptively Simple is good. While Simply Simple is bad due to inherent architectural myopia obscured by initial illusion of cheapness etc.. What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. That's what I meant by: Deceptively Simple, architectural apex is narrow (simple) while the base is broad (a pyramid) :-) Exactly the opposite of I will use this pragmatic pattern until it breaks but instead That's what I meant by: Simple Simple, architectural apex is broad while the base is narrow (think inverted pyramid). architectural beauty for eternity. Yes! That what you get with: Deceptively Simple :-) Kingsley Just look at the http specs. The fact that you can do a nice 303 is because someone in the distant past very cleverly designed a protocol goes well beyond the pragmatic I have a URL (sic!) and want to fetch the Web page in HTML (sic!). So when being proud of being the pragmatic guys keep in mind that nothing is as powerful in practice as something that is theoretically consistent. Best Martin 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
Elevations in DBPedia
All,
I just wanted to have a few elevations of mountains:
PREFIX pr: http://dbpedia.org/property/
select distinct * where
{
?uri a http://dbpedia.org/ontology/Mountain ;
http://dbpedia.org/ontology/elevation ?elev ;
pr:name ?name ;
pr:range http://dbpedia.org/resource/Hindu_Kush
} ORDER BY DESC(?elev) LIMIT 10
try:
http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.orgshould-sponge=query=PREFIX+pr%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fproperty%2F%3E%0D%0A%0D%0Aselect+distinct+%2A+where+%0D%0A%7B%0D%0A++%3Furi+a+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2FMountain%3E+%3B+%0D%0A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2Felevation%3E+%3Felev+%3B+%0D%0A+pr%3Aname+%3Fname+%3B%0D%0A+pr%3Arange+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FHindu_Kush%3E%0D%0A%0D%0A%7D++ORDER+BY+DESC%28%3Felev%29+LIMIT+10format=text%2Fhtmldebug=on
What you notice in the result is the different format for the elevation, some
are
dbpedia-owl:elevation 7403^^dbpedia-owl:metre ;
some are
dbpedia-owl:elevation 7,349 metres (24,112 feet) ;
This will cause a mess in the application... Could this be solved when DBPedia
is compiled some way?
Cheers,
Kjetil
Re: RDFa vs RDF/XML and content negotiation
Thanks everyone who replied. It seems that there's a lot of support for the RDFa route in that (perhaps not statistically significant) sample of opinion. But to summarise my understanding of your various bits of advice: since there aren't currently so many applications out there consuming RDF, a good RDF publisher should provide as many options as possible. Therefore rather than deciding for either RDFa or a content-negotiated approach, why not do both (and provide a dump file too) Cheers Bill
LOD Data Sets, Licensing, and AWS
All, As you may have noticed, AWS still haven't made the LOD cloud data sets -- that I submitted eons ago -- public. Basically, the hold-up comes down to discomfort with the lack of license clarity re. some of the data sets. Action items for all data set publishers: 1. Integrate your data set licensing into your data set (for LOD I would expect CC-BY-SA to be the norm) 2. Indicate license terms in the appropriate column at: http://esw.w3.org/topic/DataSetRDFDumps If licenses aren't clear I will have to exclude offending data sets from the AWS publication effort. -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: LOD Data Sets, Licensing, and AWS
Hi all, On Tue, Jun 23, 2009 at 9:36 PM, Kingsley Idehen kide...@openlinksw.comwrote: All, As you may have noticed, AWS still haven't made the LOD cloud data sets -- that I submitted eons ago -- public. Basically, the hold-up comes down to discomfort with the lack of license clarity re. some of the data sets. Action items for all data set publishers: 1. Integrate your data set licensing into your data set (for LOD I would expect CC-BY-SA to be the norm) Please do not use CC-BY-SA for LOD - it is not an appropriate licence and it is making the problem worse. That licence uses copyright which does not hold for factual information. Please use an Open Data Commons license or CC-0 http://www.opendatacommons.org/licenses/ http://wiki.creativecommons.org/CC0 If your dataset contains copyrighted material too (e.g. reviews) and you hold the rights over that content then you should also apply a standard copyright licence. So for completeness you need a licence for your data and one for your content. If you use CC-0 you can apply it to both at the same time. Obviously if you aren't the rightsholder (e.g. it is scraped data/content from someone else) then you can't just slap any licence you like on it - you have to abide by the original rightsholder's wishes. Personally I would try and select a public domain waiver or dedication, not one that requires attributon. The reason can be seen at http://en.wikipedia.org/wiki/BSD_license#UC_Berkeley_advertising_clausewhere stacking of attributions becomes a huge burden. Having datasets require attribution will negate one of the linked data web's greatest strengths: the simplicity of remixing and reusing data. A group of us have submitted a tutorial on these issues for ISWC 2009, hopefully it will get accepted because this is a really important area of Linked Data that is poorly understood. 2. Indicate license terms in the appropriate column at: http://esw.w3.org/topic/DataSetRDFDumps If licenses aren't clear I will have to exclude offending data sets from the AWS publication effort. I completely support declaring what rights are asserted or waived for a dataset, so please everyone help this effort. Ian
Re: http://ld2sd.deri.org/lod-ng-tutorial/
On Tue, Jun 23, 2009 at 8:01 AM, Giovanni Tummarello g.tummare...@gmail.com wrote: Just a remark about what we're doing in Sindice, for all who want to be indexed properly by us. we recursively dereference the properties that are used thus trying to obtain a closure over the description of the properties that are used. We also consider OWL imports. When the recursive fetching is computer, we apply RDFS + some owl reasoning (OWLIM being the final reasoner at the moment) and index it. Just out of interest, if you detect an inconsistency do you still index it? Ian
Re: LOD Data Sets, Licensing, and AWS
On Tue, Jun 23, 2009 at 4:36 PM, Kingsley Idehen kide...@openlinksw.com wrote: All, As you may have noticed, AWS still haven't made the LOD cloud data sets -- that I submitted eons ago -- public. Basically, the hold-up comes down to discomfort with the lack of license clarity re. some of the data sets. Action items for all data set publishers: 1. Integrate your data set licensing into your data set (for LOD I would expect CC-BY-SA to be the norm) First off, I am not a lawyer, and neither I nor Science Commons give legal advice. I can pass along the results of our research and policy work in this space, and connect you with others at Science Commons if need be. Data is tricky, since it's not always clear whether copyright licenses can be applied. Copyright law at its core applies when there is creative expression and does not protect facts, which most data arguably is. It's very difficult to discern where copyright protection ends and when the data is naturally in the public domain, and so we do not advocate applying a copyright license to data (CC-BY-SA being an example of such). Here are some links if you are interested in understanding more about the problem. http://sciencecommons.org/resources/faq/database-protocol/ http://sciencecommons.org/projects/publishing/open-access-data-protocol/ http://www.slideshare.net/kaythaney/sharing-scientific-data-legal-normative-and-social-issues http://sciencecommons.org/wp-content/uploads/freedom-to-research.pdf A further issue is that any *license* applied to data constrains the ability to integrate it on a large scale because any requirement on the licensee gets magnified as more and more data sources become available, each with a separate requirement. Instead it is suggested that providers effectively commit the data to the public domain. In order to do that, Science Commons defined a protocol for implementing open access data. It is intended that various license and public domain dedications might follow this protocol, and there are two thus far that we have certified as truly open. The Public Domain Dedication and License http://www.opendatacommons.org/licenses/pddl/ and CC Zero http://creativecommons.org/publicdomain/zero/1.0/ We recommend that you use one of these approaches when releasing your data, to ensure maximum freedom to integrate. With regards, Alan Ruttenberg http://sciencecommons.org/about/whoweare/ruttenberg/ 2. Indicate license terms in the appropriate column at: http://esw.w3.org/topic/DataSetRDFDumps If licenses aren't clear I will have to exclude offending data sets from the AWS publication effort. -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: http://ld2sd.deri.org/lod-ng-tutorial/
On Tue, Jun 23, 2009 at 10:12 AM, Dan Brickley dan...@danbri.org wrote: On 23/6/09 11:01, Martin Hepp (UniBW) wrote: And Michael, please be frank - there is a tendency in the LOD community which goes along the lines of OWL and DL-minded SW research has proven obsolete anyway, so we LOD guys and girls just pick and use the bits and pieces we like and don't care about the rest. What made the Web so powerful is that its Architecture is extremely well-thought underneath the first cover of simplicity. One of those principles is partial understanding - the ability to do something useful without understanding everything... Absolutely. We should also remember that multiple ontologies may exist that cover a given term. I think this is often forgotten. There is no requirement that the ontology statements retrieved by dereferencing the URI should be used - they are only provided as _an_ additional source of information. There may be many other ways to discover relevant ontologies and a large class of those will be for private use. If I choose to assert that dc:date and rev:createdOn are owl:equivalentProperties then that is my prerogative. The beauty of the semweb is that I can publish my assertions and potentially other people could choose to adopt them. Ian
Re: LOD Data Sets, Licensing, and AWS
Alan Ruttenberg wrote: On Tue, Jun 23, 2009 at 4:36 PM, Kingsley Idehen kide...@openlinksw.com wrote: All, As you may have noticed, AWS still haven't made the LOD cloud data sets -- that I submitted eons ago -- public. Basically, the hold-up comes down to discomfort with the lack of license clarity re. some of the data sets. Action items for all data set publishers: 1. Integrate your data set licensing into your data set (for LOD I would expect CC-BY-SA to be the norm) First off, I am not a lawyer, and neither I nor Science Commons give legal advice. I can pass along the results of our research and policy work in this space, and connect you with others at Science Commons if need be. Data is tricky, since it's not always clear whether copyright licenses can be applied. Copyright law at its core applies when there is creative expression and does not protect facts, which most data arguably is. It's very difficult to discern where copyright protection ends and when the data is naturally in the public domain, and so we do not advocate applying a copyright license to data (CC-BY-SA being an example of such). Here are some links if you are interested in understanding more about the problem. http://sciencecommons.org/resources/faq/database-protocol/ http://sciencecommons.org/projects/publishing/open-access-data-protocol/ http://www.slideshare.net/kaythaney/sharing-scientific-data-legal-normative-and-social-issues http://sciencecommons.org/wp-content/uploads/freedom-to-research.pdf A further issue is that any *license* applied to data constrains the ability to integrate it on a large scale because any requirement on the licensee gets magnified as more and more data sources become available, each with a separate requirement. Instead it is suggested that providers effectively commit the data to the public domain. In order to do that, Science Commons defined a protocol for implementing open access data. It is intended that various license and public domain dedications might follow this protocol, and there are two thus far that we have certified as truly open. The Public Domain Dedication and License http://www.opendatacommons.org/licenses/pddl/ and CC Zero http://creativecommons.org/publicdomain/zero/1.0/ We recommend that you use one of these approaches when releasing your data, to ensure maximum freedom to integrate. Alan, Which license simply allows me to assert that I want to be attributed by data source URI. Example (using DBpedia even though it isn't currently CC-BY-SA): I have the URI: http://dbpedia.org/resource/Linked_Data. If you use this URI as a data source in a Linked Data meshup of Web 2.0 mashup, I would like any user agent to be able to discover http://dbpedia.org/resource/Linked_Data. Thus, Data provided by DBpedia isn't good enough because the path to the actual data source isn't reflected in the literal and generic attribution. The point above is the crux of the matter for traditional media companies (today) and smaller curators of high quality data (in the near future). Nobody wants to invest time in making high quality data spaces that are easily usurped by crawling and reconstitution via completely different URIs that dislocate the originals; or even worse, produce pretty presentations that complete obscure paths to original data provider (what you see in a lot of Ajax and RIA style apps today). Kingsley With regards, Alan Ruttenberg http://sciencecommons.org/about/whoweare/ruttenberg/ 2. Indicate license terms in the appropriate column at: http://esw.w3.org/topic/DataSetRDFDumps If licenses aren't clear I will have to exclude offending data sets from the AWS publication effort. -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: RDFa vs RDF/XML and content negotiation
Bill Roberts wrote: Thanks everyone who replied. It seems that there's a lot of support for the RDFa route in that (perhaps not statistically significant) sample of opinion. But to summarise my understanding of your various bits of advice: since there aren't currently so many applications out there consuming RDF, a good RDF publisher should provide as many options as possible. Amen! Therefore rather than deciding for either RDFa or a content-negotiated approach, why not do both (and provide a dump file too) Exactly! RDFa vs Content Negotiation is a misnomer re. Web Architecture :-) Kingsley Cheers Bill -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: RDFa vs RDF/XML and content negotiation
Therefore rather than deciding for either RDFa or a content-negotiated approach, why not do both (and provide a dump file too) Exactly! +1 Also: You can provide a translation of your rdfahttp://en.wikipedia.org/wiki/RDFa +xhtml http://en.wikipedia.org/wiki/XHTML into normal RDFhttp://en.wikipedia.org/wiki/Resource_Description_Frameworkthrough GRDDL http://en.wikipedia.org/wiki/GRDDL. That basically means into putting a profile attribute into your head tag which points to a resource which says This is how you pull out RDF from here. head profile=http://ns.inria.fr/grddl/rdfa/; You could provide links to an installation of Cognition or similar to extract that on the fly - http://buzzword.org.uk/swignition/grddl More at http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/tmp/grddl/rdfaprimer/PrimerRDFaSection.html Zemanta http://www.zemanta.com helped me add links pictures to this email. It can do it for you too. http://www.zemanta.com/
Re: LOD Data Sets, Licensing, and AWS
On Tue, Jun 23, 2009 at 11:11 PM, Kingsley Idehen kide...@openlinksw.comwrote: Using licensing to ensure the data providers URIs are always preserved delivers low cost and implicit attribution. This is what I believe CC-BY-SA delivers. There is nothing wrong with granular attribution if compliance is low cost. Personally, I think we are on the verge of an Attribution Economy, and said economy will encourage contributions from a plethora of high quality data providers (esp. from the tradition media realm). Regardless of any attribution economy, CC-BY-SA is basically unenforceable for data so is not appropriate. You can't copyright the diameter of the moon. Ian
List of public datasets on CKAN?
Hi all, I understand the main lists of public datasets for the LOD project are at: http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets http://esw.w3.org/topic/DataSetRDFDumps Many of these datasets are on CKAN (http://www.ckan.net), which is an open source registry of open datasets and other knowledge resources. For example, see the package pages for Freebase (http://www.ckan.net/package/read/freebase) or DMOZ (http://www.ckan.net/package/read/dmoz). You can also see other collections of data, such as 'eutransparency' (http://ckan.net/tag/read/eutransparency) or 'science' (http://ckan.net/tag/read/science). I'm writing to ask whether the LOD community think it would be useful to add more of the LOD datasets to CKAN? LOD datsets could have a 'linkedopendata' or 'lod' tag. Advantages of doing this might include: * Ability to tag resources by subject matter, and to include tags on access, format, ... * We could provide CKAN data as RDF (as well as current JSON) * We're working on something like 'apt-get' for the knowledge packages, so (multiple) datasets can be automatically grabbed... * More flexibility than HTML table? Also I'd be really interested to hear what kinds of things might be most useful for the LOD community! E.g. would it be useful to be able to generate a dump based on a particular tag? Or to have provision for domain specific metadata (e.g. geodata bounding box, ...). CKAN exists to make life easier for people working with open data! What do people think? -- Jonathan Gray Community Coordinator The Open Knowledge Foundation http://www.okfn.org
Re: LOD Data Sets, Licensing, and AWS
2009/6/24 Ian Davis li...@iandavis.com On Tue, Jun 23, 2009 at 11:11 PM, Kingsley Idehen kide...@openlinksw.comwrote: Using licensing to ensure the data providers URIs are always preserved delivers low cost and implicit attribution. This is what I believe CC-BY-SA delivers. There is nothing wrong with granular attribution if compliance is low cost. Personally, I think we are on the verge of an Attribution Economy, and said economy will encourage contributions from a plethora of high quality data providers (esp. from the tradition media realm). Regardless of any attribution economy, CC-BY-SA is basically unenforceable for data so is not appropriate. You can't copyright the diameter of the moon. Ian Interestingly, there is a large economy involved with patenting gene sequences. Aren't they facts also? Why is patenting different to copyright in this respect? Cheers, Peter
Re: LOD Data Sets, Licensing, and AWS
On Wednesday, June 24, 2009, Peter Ansell ansell.pe...@gmail.com wrote: 2009/6/24 Ian Davis li...@iandavis.com On Tue, Jun 23, 2009 at 11:11 PM, Kingsley Idehen kide...@openlinksw.com wrote: Using licensing to ensure the data providers URIs are always preserved delivers low cost and implicit attribution. This is what I believe CC-BY-SA delivers. There is nothing wrong with granular attribution if compliance is low cost. Personally, I think we are on the verge of an Attribution Economy, and said economy will encourage contributions from a plethora of high quality data providers (esp. from the tradition media realm). Regardless of any attribution economy, CC-BY-SA is basically unenforceable for data so is not appropriate. You can't copyright the diameter of the moon. Ian Interestingly, there is a large economy involved with patenting gene sequences. Aren't they facts also? Why is patenting different to copyright in this respect? I can't explain the technicalities (IANAL) but there are many different types of property rights that are granted by governments over information : copyright, database right, patent right, moral right etc. Each of those have seperate legislation that varies by jurisdiction (WIPO is attempting to normalising some of them). It's complicated which is why the efforts of creative commons, science commons and open data commons are so valuable: they create simple ways for people to declare the conditions under which their data and content can be reused. Ian
Re: RDFa vs RDF/XML and content negotiation
I agree that both is better, but there is a catch. As did Toby with his system, in http://t4gm.info, I serve up both XHTML+RDFa and perform content negotiation, generating triples in the MIME type expected by a given RDF-accepting user agent by redirecting the given static XHTML+RDFa page through the RDFa Distiller service. The main issue with this, however, was configuring this in Apache on the hosting provider I use resulted in a solution based on .htaccess that does not respect quality values. I am not currently aware of a working solution to this problem. Doing content negotiation in a completely correct manner presupposes a level of expertise and control over the server side that is not available to everyone who could be fruitfully producing XHTML+RDFa, serving it up with a vanilla HTTP server or embedding it in a hosted blog post. - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Tue, Jun 23, 2009 at 3:31 PM, Kingsley Idehenkide...@openlinksw.com wrote: Bill Roberts wrote: Thanks everyone who replied. It seems that there's a lot of support for the RDFa route in that (perhaps not statistically significant) sample of opinion. But to summarise my understanding of your various bits of advice: since there aren't currently so many applications out there consuming RDF, a good RDF publisher should provide as many options as possible. Amen! Therefore rather than deciding for either RDFa or a content-negotiated approach, why not do both (and provide a dump file too) Exactly! RDFa vs Content Negotiation is a misnomer re. Web Architecture :-) Kingsley Cheers Bill -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: LOD Data Sets, Licensing, and AWS
Ian Davis wrote: On Tue, Jun 23, 2009 at 11:11 PM, Kingsley Idehen kide...@openlinksw.com mailto:kide...@openlinksw.com wrote: Using licensing to ensure the data providers URIs are always preserved delivers low cost and implicit attribution. This is what I believe CC-BY-SA delivers. There is nothing wrong with granular attribution if compliance is low cost. Personally, I think we are on the verge of an Attribution Economy, and said economy will encourage contributions from a plethora of high quality data providers (esp. from the tradition media realm). Regardless of any attribution economy, CC-BY-SA is basically unenforceable for data so is not appropriate. You can't copyright the diameter of the moon. Ian I am not talking about copyrighting the diameter of the moon. I am talking about the origin of the diameter of the moon that is de-referencable via an HTTP URI :-) Just want a pathway to the origin of the perspective that is being used in some other context and space. -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
