Re: ANN: geometry2rdf software library
Hi Christopher We are also developing a KML exporter with a viewer (within a map) of RDF resources. You can find it at [1]. Right now it takes a while to load the facets; once you have the facets, for example click on Aiport. Then, click on the KML button (up/right corner on the map) to get the KML. We expect to deliver the final version soon. All this work is included within the context of GeoLinkedData [2] which is an open initiative whose aim is to enrich the Web of Data with Spanish geospatial data. Thanks Alex and Boris [1] http://geo.linkeddata.es:8282/GeoLinkedData-DbPedia/ [2] http://geo.linkeddata.es/ On 17/01/2011 3:01, Christopher Gutteridge wrote: Cool, I've been doing something (very hacky) the other way around. http://graphite.ecs.soton.ac.uk/geo2kml/ It only handles points and dc:spatial POLYGONs so far, but is really handy for checking RDF geo point data, as you can bung it onto google maps (or earth) to see if it looks sane. (I'll happily give away the PHP source if anyone wants, but it's pretty shonky *grin*) Boris Villazón Terrazas wrote: Dear all We are pleased to announce geometry2rdf [1], a library for generating RDF from geometrical information (Points, LineStrings and Polygons). The current version of the library works with Oracle geospatial databases. All the best, Victor, Miguel Angel and Boris [1] http://www.oeg-upm.net/index.php/downloads/151-geometry2rdf
Re: ANN: geometry2rdf software library
Boris would you be able to provide a bit of explanation on why would you want o do that e.g. what evidence are there (nice use cases) were an rdf export of low level features in the map is of use thanks! Gio On Mon, Jan 17, 2011 at 2:34 AM, Boris Villazón Terrazas bvilla...@fi.upm.es wrote: Victor, Miguel Angel and Boris
ANN: DBpedia 3.6 released
Hi all, we are happy to announce the release of DBpedia 3.6. The new release is based on Wikipedia dumps dating from October/November 2010. The new DBpedia dataset describes more than 3.5 million things, of which 1.67 million are classified in a consistent ontology, including 364,000 persons, 462,000 places, 99,000 music albums, 54,000 films, 16,500 video games, 148,000 organizations, 148,000 species and 5,200 diseases. The DBpedia dataset features labels and abstracts for 3.5 million things in up to 97 different languages; 1,850,000 links to images and 5,900,000 links to external web pages; 6,500,000 external links into other RDF datasets, and 632,000 Wikipedia categories. The dataset consists of 672 million pieces of information (RDF triples) out of which 286 million were extracted from the English edition of Wikipedia and 386 million were extracted from other language editions and links to external datasets. Along with the release of the new datasets, we are happy to announce the initial release of the DBpedia MappingTool (http://mappings.dbpedia.org/index.php/MappingTool): a graphical user interface to support the community in creating and editing mappings as well as the ontology. The new release provides the following improvements and changes compared to the DBpedia 3.5.1 release: 1. Improved DBpedia Ontology as well as improved Infobox mappings using http://mappings.dbpedia.org/. Furthermore, there are now also mappings in languages other than English. These improvements are largely due to collective work by the community. There are 13.8 million RDF statements based on mappings (11.1 million in version 3.5.1). All this data is in the /ontology/ namespace. Note that this data is of much higher quality than the Raw Infobox data in the /property/ namespace. Statistics of the mappings wiki on the date of release 3.6: + Mappings: + English: 315 Infobox mappings (covers 1124 templates including redirects) + Greek: 137 Infobox mappings (covers 192 templates including redirects) + Hungarian: 111 Infobox mappings (covers 151 templates including redirects) + Croatian: 36 Infobox mappings (covers 67 templates including redirects) + German: 9 Infobox mappings + Slovenian: 4 Infobox mappings + Ontology: + 272 classes + Properties: + 629 object properties + 706 datatype properties (they are all in the /datatype/ namespace) 2. Some commonly used property names changed. + Please see http://dbpedia.org/ChangeLog and http://dbpedia.org/Datasets/Properties to know which relations changed and update your applications accordingly! 3. New Datatypes for increased quality in mapping-based properties + xsd:positiveInteger, xsd:nonNegativeInteger, xsd:nonPositiveInteger, xsd:negativeInteger 4. Improved parsing coverage. + Parsing of lists of elements in Infobox property values that improves the completeness of extracted facts. + Method to deal with missing repeated links in Infoboxes that do appear somewhere else on the page. + Flag templates are parsed. + Various improvements on internationalization. 5. Improved recognition of + Wikipedia namespace identifiers. + Wikipedia language codes. + Category hierarchies. 6. Disambiguation links for acronyms (all upper-case title) are now extracted (for example, Kilobyte and Knowledge_base for KB): + Wikilinks consisting of multiple words: If the starting letters of the words appear in correct order (with possible gaps) and cover all acronym letters. + Wikilinks consisting of a single word: If the case-insensitive longest common subsequence with the acronym is equal to the acronym. 7. Encoding (bugfixes): + The new datasets support the complete range of Unicode code points (up to 0x10). 16-bit code points start with '\u', code points larger than 16-bits start with '\U'. + Commas and ampersands do not get encoded anymore in URIs. Please see http://dbpedia.org/URIencoding for an explanation regarding the DBpedia URI encoding scheme. 8. Extended Datasets: + Thanks to Johannes Hoffart (Max-Planck-Institut für Informatik) for contributing links to YAGO2. + Freebase links have been updated. They now refer to mids (http://wiki.freebase.com/wiki/Machine_ID) because guids have been deprecated. You can download the new DBpedia dataset from http://dbpedia.org/Downloads36 As usual, the dataset is also available as Linked Data and via the DBpedia SPARQL endpoint at http://dbpedia.org/sparql Lots of thanks to: + All editors that contributed to the DBpedia ontology mappings via the Mappings Wiki. + Max Jakob (Freie Universität Berlin, Germany) for improving the DBpedia extraction framework and for extracting the new datasets. + Robert Isele and Anja Jentzsch (both Freie Universität Berlin, Germany) for helping Max with their expertise on the extraction framework. + Paul Kreis (Freie Universität Berlin, Germany) for analyzing the DBpedia data of the previous release and
Re: Introducing Vocabularies of a Friend (VOAF)
Bernard, Thanks for your answer. Another question I was wondering: Can we extend the VOAF ontology to describe SKOS taxonomies ? Does this question make sense to you ? In the case of SKOS, we have only the notion of concepts not classes and properties. Regards Stephane Fellah On Sat, Jan 15, 2011 at 6:52 PM, Bernard Vatant bernard.vat...@mondeca.comwrote: Hi Stephane 2011/1/15 Stephane Fellah fella...@gmail.com Sounds very interesting initiative. Based on my understanding, I think it should be possible to write a tool that read any OWL document and generate a VOAF document. Indeed I've been thinking along those lines. The current dataset is handcrafted as a prototype should be, but I'm indeed thinking now about ways to generate the VOAF description automagically from the OWL or RDFS files. Devil is in the details, though. Some information you can't really get by conventional parsing of the graph, such as which namespaces are used, to populate the voaf:reliesOn property. Those you can get by ad hoc syntactic scripts, but vocabularies are published using a variety of syntaxes. May be Swoogle could be a good starting point, but not sure how the API can provide the list of ontology namespaces through the REST API. I don't know either, but I'm sure someone will find a way :) The imports section would corresponds to the imports statement. The tools would count the number of classes and properties in the ontology namespace. It would be interesting to aggregate all this information and see which vocabularies have the most influence using SNA algorithms. You are welcome to play along those lines. I think there are a lot of opportunities and things to discover. This is just the beginning of the story. Best Bernard -- Bernard Vatant Senior Consultant Vocabulary Data Engineering Tel: +33 (0) 971 488 459 Mail: bernard.vat...@mondeca.com Mondeca 3, cité Nollez 75018 Paris France Web:http://www.mondeca.com Blog:http://mondeca.wordpress.com
ICWE 2011: Second Call for Papers
11th International Conference on Web Engineering (ICWE 2011) http://icwe2011.webengineering.org June 20-24, 2011, Paphos, Cyprus *** Second Call for Papers *** The International Conference on Web Engineering (ICWE) aims at promoting scientific and practical excellence on Web Engineering, and at bringing together researchers and practitioners working in technologies, methodologies, tools, and techniques used to develop and maintain Web-based applications leading to better systems, and thus to enabling and improving the dissemination and use of content and services through the Web. A special focus of ICWE 2011 will be Web Data Engineering. *Topics of Interest* The conference fosters original submissions covering, but not restricted to the following topics of interest: Web application engineering * Processes and methods for Web application development * Conceptual modeling of Web applications * Model-driven Web application development * Domain-specific languages for Web application development * Component-based Web application development * Web application architectures and frameworks * Rich Internet Applications * Mashup development and end user Web programming * Patterns for Web application development and pattern mining * Web content management and data-intensive Web applications * Web usability and accessibility * I18N of Web applications and multi-lingual development * Testing and evaluation of Web applications * Deployment and usage analysis of Web applications * Performance modeling, monitoring, and evaluation * Empirical Web engineering * Web quality and Web metrics * Adaptive, contextualized and personalized Web applications * Mobile Web applications and device-independent delivery Web service engineering * Web service engineering methodologies * Web Service-oriented Architectures * Semantic Web services * Web service-based architectures and applications * Quality of service and its metrics for Web applications * Inter-organizational Web applications * Ubiquity and pervasiveness * Linked Data Services Web data engineering * Semantic Web engineering * Web 2.0 technologies * Social Web applications * Web mining and information extraction * Linked Data * Web data linking, fusion * Information quality assessment * Data repair strategies * Dataset dynamics * Dataset introspection * Linked Data consumption, visualisation and exploration * Deep Web * Web science and Future Internet applications *Submission instructions* Authors of the research and industrial papers track must explain the relationship of their work to the Web Engineering discipline in their submissions. Research papers must comprise substantial innovative discussion with respect to the related work and must be well motivated and presented. * Extension: Papers must not be longer than 15 (fifteen) pages. * Format: according to the LNCS guidelines. * Submission: http://www.easychair.org/conferences/?conf=icwe2011 *Publishing of accepted works* The conference proceedings will be published by Springer-Verlag as an LNCS volume. Official proceedings will include: full papers (15 pages), demonstration papers (4 pages) and posters (4 pages). Workshop papers and contributions to the doctoral consortium will be published separately. Final versions of accepted papers must strictly adhere to the LNCS guidelines and must include a printable file of the camera-ready version, as well as all source files thereof. No changes to such formatting rules are permitted. Authors of accepted papers must also download and sign a copyright form that will be made available on the Web site of the conference. Each paper requires at least one full registration to the main conference. Selected papers will be invited to submit an extended version to a special issue of the JCR-indexed Journal Of Web Engineering (pending agreement). *Important Dates* * Submission deadline: February 14, 2011 (23:59 Hawaii Time) * Notification of acceptance: April 14, 2011 * Camera-ready version: April 28, 2011 *Program Chairs* * Oscar Diaz, University of the Basque Country, Spain * Sören Auer, Universität Leipzig, Germany In case of inquiries, please contact the program chairs at: pcchairs [at] icwe2011.webengineering.org *Conference Committee* General Chair * George A. Papadopoulos, University of Cyprus, Cyprus Industrial Track Chair * Andreas Doms, SAP Research, Germany Workshop Chairs: * Nora Koch, LMU and Cirquent GmbH, Germany * Andreas Harth, KIT, Germany Tutorial Chairs * Cesare Pautasso, University of Lugano, Switzerland Demo Poster Chairs * Axel Ngonga, Universitat Leipzig * Pelechano Vicente, Universidad Politecnica de Valencia Doctoral Consortium Chairs * Peter Dolog, Aalborg University, Denmark, * Bernhard Haslhofer,
2nd CfP: Linked Data on the Web (LDOW2011) Workshop at WWW2011
Hi all, this is just a quick reminder that the submission deadline of the 4th International Workshop on Linked Data on the Web (LDOW2011) at WWW2011, Hyderabad, India is approaching slowly. The deadline is in about 3 weeks: Submission deadline: 8th February, 2011 The LDOW2011 website is now available at: http://events.linkeddata.org/ldow2011/ http://events.linkeddata.org/ldow2011/ Please find below the CfP and we are looking forward to see you at LDOW2011! Cheers, Chris Bizer Tom Heath Tim Berners-Lee Michael Hausenblas = Linked Data on the Web (LDOW2011) Workshop at WWW2011 http://events.linkeddata.org/ldow2011/ = Workshop date: March 29th, 2011, Hyderabad, India Submission deadline: 8th February, 2011 = Objectives The Web has developed into a global information space consisting not just of linked documents, but also of linked data. In 2010, we have seen significant growth in the size of the Web of Data as well as in the number of communities contributing to its creation. In addition, there is intensive work on applications that consume Linked Data from the Web. The LDOW2011 workshop in Hyderabad follows the LDOW2008 workshop in Beijing, the LDOW2009 workshop in Madrid, and the LDOW2010 workshop in Raleigh. As the previous workshops, LDOW2011 is open to cover all topics related to Linked Data publication as well as consumption, including principled research in the areas of user interfaces for the Web of Data as well as on issues of quality, trust and provenance in Linked Data. We also expect to see a number of submissions related to current areas of high Linked Data activity, such as government transparency, life sciences and the media industry. The goal of this workshop is to provide a forum for exposing high quality, novel research and applications in these (and related) areas. In addition, by bringing together researchers in this field, we expect the event to further shape the ongoing Linked Data research agenda. = Topics of Interest Topics of interest for the LDOW2011 workshop include, but are not limited to: 1. Foundations of Linked Data * Web architecture and dataspace theory * dataset dynamics and synchronisation * analizing and profiling the Web of Data 2. Data Linking and Fusion * entity consolidation and linking algorithms * Web-based data integration and data fusion * performance and scalability of integration architectures 3. Write-enabled Linked Data Web * access authentication mechanisms for Linked Datasets (WebID, etc.) * authorisation mechanisms for Linked Datasets (WebACL, etc.) * enabling write-access to legacy data sources (Google APIs, Flickr API, etc.) 4. Data Publishing * publishing legacy data sources as Linked Data on the Web * cost-benefits of the 5 star LOD plan 5. Data Usage * tracking provenance of Linked Data * evaluating quality and trustworthiness of Linked Data * licensing issues in Linked Data publishing * distributed query of Linked Data * RDF-to-X, turning RDF to legacy data 6. Interaction with the Web of Data * approaches to visualise Linked Data * interacting with distributed Web data * Linked Data browsers, indexer and search engines = Submissions We seek three kinds of submissions: 1. Full technical papers: up to 10 pages in ACM format 2. Short technical and position papers: up to 5 pages in ACM format 3. Demo description: up to 2 pages in ACM format Submissions must be formatted using the WWW2011 templates available via the LDOW2011 homepage. We note that the author list does not need to be anonymised, as we we do not have a double-blind review process in place. Submissions will be peer reviewed by at least three independent reviewers. Accepted papers will be presented at the workshop and included in the workshop proceedings. Please submit your paper via EasyChair at http://www.easychair.org/conferences/?conf=ldow2011 = Important Dates Submission deadline: 8th February, 2011 Notification of acceptance: 25th February, 2011 Camera ready versions of accepted papers: 10nd March, 2011 Workshop date: Tuesday, 28th or 29th March, 2011 = Organising Committee Christian Bizer, Freie Universität Berlin, Germany Tom Heath, Talis Systems Ltd, UK Tim Berners-Lee, MIT CSAIL, USA Michael Hausenblas, DERI, NUI Galway, Ireland = Contact For further information about the workshop, please contact the workshops chairs at ldow2011 [at] events [dot linkeddata [dot] org = -- Prof. Dr. Christian Bizer
Property for linking from a graph to HTTP connection meta-data?
Hi all, In some cases, it's useful to attach HTTP connection meta-data, in particular HTTP response header parameters, to an RDF graph, in particular whenever we rdfize existing Web content. For example, if we fetch a CSV file and derive an RDF representation thereof, we may want to preserve the original HTTP header information. Luckily, there is a W3C RDF vocabulary for HTTP [1, 2]. Directly using the header properties [3] seems possible. However, it would turn the RDF graph into a http:Response (because the domain of all header properties is http:Response). Does anybody know of a standard property for linking a RDF graph to a http:GetRequest, http:Connection, or http:Response instance? Maybe rdfs:seeAlso (@TBL: ;- ))? Best Martin [1] http://www.w3.org/2006/http# [2] http://www.w3.org/TR/HTTP-in-RDF/ [3] http://www.w3.org/WAI/ER/HTTP/WD-HTTP-in-RDF-20070301#header martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.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
Re: Introducing Vocabularies of a Friend (VOAF)
I can't help but feel that calling it VOAF is just going to muddy the waters. Friendly vocabularies for the linked data Web doesn't help clarify either. It's cute, but I strongly suggest you at the very least make this 'tag line' far more clear. Frankly calling something 'voaf' when people will hear it mixed in with 'foaf' is just making the world more confusing. I had a lot of confusion until I found out the SHOCK vocab people were talking about was spelled SIOC. One other minor suggestion; Vocabulary http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fwww.mondeca.com%2Ffoaf%2Fvoaf%23Vocabulary#http://www.mondeca.com/foaf/voaf#Vocabulary ? rdfs:subClassOf http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23subClassOf#http://www.w3.org/2000/01/rdf-schema#subClassOf ? void:Dataset http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Frdfs.org%2Fns%2Fvoid%23Dataset#http://rdfs.org/ns/void#Dataset might be a mistake because void:Dataset is defined as A set of RDF triples that are published, maintained or aggregated by a single provider. ad it may be that you would want to define non RDF vocabs using this. I see no value in making this restriction. On 17/01/11 15:26, Stephane Fellah wrote: Bernard, Thanks for your answer. Another question I was wondering: Can we extend the VOAF ontology to describe SKOS taxonomies ? Does this question make sense to you ? In the case of SKOS, we have only the notion of concepts not classes and properties. Regards Stephane Fellah On Sat, Jan 15, 2011 at 6:52 PM, Bernard Vatant bernard.vat...@mondeca.com mailto:bernard.vat...@mondeca.com wrote: Hi Stephane 2011/1/15 Stephane Fellah fella...@gmail.com mailto:fella...@gmail.com Sounds very interesting initiative. Based on my understanding, I think it should be possible to write a tool that read any OWL document and generate a VOAF document. Indeed I've been thinking along those lines. The current dataset is handcrafted as a prototype should be, but I'm indeed thinking now about ways to generate the VOAF description automagically from the OWL or RDFS files. Devil is in the details, though. Some information you can't really get by conventional parsing of the graph, such as which namespaces are used, to populate the voaf:reliesOn property. Those you can get by ad hoc syntactic scripts, but vocabularies are published using a variety of syntaxes. May be Swoogle could be a good starting point, but not sure how the API can provide the list of ontology namespaces through the REST API. I don't know either, but I'm sure someone will find a way :) The imports section would corresponds to the imports statement. The tools would count the number of classes and properties in the ontology namespace. It would be interesting to aggregate all this information and see which vocabularies have the most influence using SNA algorithms. You are welcome to play along those lines. I think there are a lot of opportunities and things to discover. This is just the beginning of the story. Best Bernard -- Bernard Vatant Senior Consultant Vocabulary Data Engineering Tel: +33 (0) 971 488 459 Mail: bernard.vat...@mondeca.com mailto:bernard.vat...@mondeca.com Mondeca 3, cité Nollez 75018 Paris France Web: http://www.mondeca.com Blog: http://mondeca.wordpress.com -- Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248 / Lead Developer, EPrints Project, http://eprints.org/ / Web Projects Manager, ECS, University of Southampton, http://www.ecs.soton.ac.uk/ / Webmaster, Web Science Trust, http://www.webscience.org/
URI Comparisons: RFC 2616 vs. RDF
Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and b) in practice (e.g. in popular triplestores)? I did not test it yet, but I assume that not all implementations would treat http://purl.org/NET/c4dm/event.owl#Event HTTP://purl.org/NET/c4dm/event.owl#Event http://PURL.org/NET/c4dm/event.owl#Event http://purl.org:80/NET/c4dm/event.owl#Event as the same class. Any facts or opinions? Best Martin [1] http://www.ietf.org/rfc/rfc2616.txt martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.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
Re: URI Comparisons: RFC 2616 vs. RDF
On 1/17/11 10:51 AM, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources Yes, where an RDF resource is a Data Container at an Address (URL). Thus, equivalent results for de-referencing a URL en route to accessing data. No, when resource also implies an Entity (Data Item or Data Object) that is assigned a Name via URI. The examples above strike me as URLs. Of course, cURL could indicate otherwise, but for now (via my visual senses) they appear to be URLs (resource addresses). a) in theory and b) in practice (e.g. in popular triplestores)? I did not test it yet, but I assume that not all implementations would treat http://purl.org/NET/c4dm/event.owl#Event HTTP://purl.org/NET/c4dm/event.owl#Event http://PURL.org/NET/c4dm/event.owl#Event http://purl.org:80/NET/c4dm/event.owl#Event as the same class. Any facts or opinions? See my comments above. Kingsley Best Martin [1] http://www.ietf.org/rfc/rfc2616.txt martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.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 -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: URI Comparisons: RFC 2616 vs. RDF
On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. BTW the more up to date RFC for looking at equivalence (as opposed to equality) issues is probably the IRI spec [2] which defines a comparison ladder for testing equivalence. Dave [1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-URIref [2] http://www.ietf.org/rfc/rfc3987.txt
Re: URI Comparisons: RFC 2616 vs. RDF
Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. I'd suggest that it's a little more complex than that, and that this may be an issue to clear up in the next RDF WG (it's on the charter I believe). For example: When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI HTTP://www.EXAMPLE.com/ is equivalent to http://www.example.com/. - http://tools.ietf.org/html/rfc3986#section-6.2.2.1 However, that's only for URIs which use the generic syntax (which most URIs we ever touch do use). It would be great if a normalized-IRI with specific normalization rules could be drafted up as part of the next WG charter - after all they are a pretty pivotal part of the sem web setup, and it would be relatively easy to clear up these issues. Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
On 1/17/11 11:37 AM, Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. BTW the more up to date RFC for looking at equivalence (as opposed to equality) issues is probably the IRI spec [2] which defines a comparison ladder for testing equivalence. Dave [1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-URIref [2] http://www.ietf.org/rfc/rfc3987.txt Dave, Important RFC excerpt: A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. . The context for resources is not equivalent or identical to the notion of an Identifier used as a Data Object (Item or Entity) Name. This context is all about good old machine addressable resources. In Linked Data context (aka. Distributed Data Object context) an Identifier usex as a Name Reference can de-reference to a resource that bears (or carries) a Representation of its Description ( a graph pictorial where Attribute=Value pairs coalesce around a Name Reference). Names are Names, if they are Unique, they should be Unique. Of course, not so when dealing with Addresses of data, which is what the RFC context applies to as I understand it. Until we clarify Resource confusion will reign. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: URI Comparisons: RFC 2616 vs. RDF
Kingsley Idehen wrote: On 1/17/11 10:51 AM, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources Yes, where an RDF resource is a Data Container at an Address (URL). Thus, equivalent results for de-referencing a URL en route to accessing data. No, when resource also implies an Entity (Data Item or Data Object) that is assigned a Name via URI. Logically, yes on both counts, we should/could be normalizing these URIs as we consume and publish using the syntax based normalization rules [1] which apply to all URI/IRIs with the generic syntax (such as the examples above) Any client consuming data, or server publishing data, can use the normalization rules, so it stands to reason that it's pretty important that we all do it to avoid false negatives. [1] http://tools.ietf.org/html/rfc3986#section-6.2.2 Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
Hi, I am particularly interested about this issue, because I am currently struggling with such a problem within the Sindice project. Given also the answer of Dave, what would be the best practices within a (RDF) system to correctly handle URIs ? Should the system implements URI normalisation based on the RFC 2616 exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. and should take care of decoding all percent-encoded characters ? However, when dealing with percent-encoded character, some cases become tricky to handle. For example, some URIs [1] have a space encoded at the end of the string. By decoding it, certain systems/applications could automatically trim it. Also, some URIs [2] are 'recursively' encoded, and need multiple decoding pass before getting the right one. [1] http://geo.linkeddata.es/resource/Pozo/Moro%2C%20Pou%2047%20o%20del%20 [2] http://sioc-project.org/sioc/user/1%2523user Any opinions on how to correctly handle URis is welcome. It will be useful to have a document for best practices for correctly handling URIs in a RDF system. Best, -- Renaud Delbru On 17/01/11 15:51, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and b) in practice (e.g. in popular triplestores)? I did not test it yet, but I assume that not all implementations would treat http://purl.org/NET/c4dm/event.owl#Event HTTP://purl.org/NET/c4dm/event.owl#Event http://PURL.org/NET/c4dm/event.owl#Event http://purl.org:80/NET/c4dm/event.owl#Event as the same class. Any facts or opinions? Best Martin [1] http://www.ietf.org/rfc/rfc2616.txt martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: h...@ebusiness-unibw.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
Re: URI Comparisons: RFC 2616 vs. RDF
Better be a bit more specific.. in-line.. Nathan wrote: Kingsley Idehen wrote: On 1/17/11 10:51 AM, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html As per the percent encoding rules and the set of unreserved characters [1], percent encoded octets in certain ranges (see [1]) should not be created by URI producers, and when found in a URI should be decoded correctly, this includes %7E - also percent encoding is case insensitive so %7e and %7E are equivalent, thus you should not produce URIs like this, and when found you should fix the error, to produce: http://abc.com:80/~smith/home.html http://ABC.com/~smith/home.html http://ABC.com:/~smith/home.html The above URIs all use the generic syntax, so the generic component syntax equivalence rules always apply [2], so normalization after these rules would produce: http://abc.com:80/~smith/home.html http://abc.com/~smith/home.html http://abc.com:/~smith/home.html Then finally, scheme specific normalization rules can be applied which treat all the port values as being equivalent (for the purpose of naming and dereferencing, it's the specification for URIs with that scheme), which allows you to normalize to: http://abc.com/~smith/home.html http://abc.com/~smith/home.html http://abc.com/~smith/home.html [1] http://tools.ietf.org/html/rfc3986#section-6.2.2.1 [2] http://tools.ietf.org/html/rfc3986#section-2.3 [3] http://tools.ietf.org/html/rfc3986#section-6.2.3 Hope that helps refine my previous comments, Does this also hold for identifying RDF resources Yes, where an RDF resource is a Data Container at an Address (URL). Thus, equivalent results for de-referencing a URL en route to accessing data. No, when resource also implies an Entity (Data Item or Data Object) that is assigned a Name via URI. Logically, yes on both counts, we should/could be normalizing these URIs as we consume and publish using the syntax based normalization rules [1] which apply to all URI/IRIs with the generic syntax (such as the examples above) Any client consuming data, or server publishing data, can use the normalization rules, so it stands to reason that it's pretty important that we all do it to avoid false negatives. [1] http://tools.ietf.org/html/rfc3986#section-6.2.2 Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
Nuno Bettencourt wrote: Hi, Even though I'll be deviating the point just a bit, since we're discussing URI comparison in terms of RDF, I would like to request some help. I have a doubt about URLs when it comes to RDF URI comparison. Is there any RFC that establishes if http://abc.com:80/~smith/home.html https://abc.com:80/~smith/home.html or even ftp://abc.com:80/~smith/home.html should or not be considered the same resource? No, and no such rules can be written (as they are case specific, and all the above URIs could easily, and often do, point to differing resources) - if all URIs point to the same resource then it should be stated as such by some other means, which in RDF would mean owl:sameas. Best, Nathan
RE: URI Comparisons: RFC 2616 vs. RDF
Hi, Even though I'll be deviating the point just a bit, since we're discussing URI comparison in terms of RDF, I would like to request some help. I have a doubt about URLs when it comes to RDF URI comparison. Is there any RFC that establishes if http://abc.com:80/~smith/home.html https://abc.com:80/~smith/home.html or even ftp://abc.com:80/~smith/home.html should or not be considered the same resource? Best regards, Nuno Bettencourt -Original Message- From: public-lod-requ...@w3.org [mailto:public-lod-requ...@w3.org] On Behalf Of Nathan Sent: segunda-feira, 17 de Janeiro de 2011 16:53 To: Dave Reynolds; Sandro Hawke Cc: Martin Hepp; public-lod@w3.org Subject: Re: URI Comparisons: RFC 2616 vs. RDF Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. I'd suggest that it's a little more complex than that, and that this may be an issue to clear up in the next RDF WG (it's on the charter I believe). For example: When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI HTTP://www.EXAMPLE.com/ is equivalent to http://www.example.com/. - http://tools.ietf.org/html/rfc3986#section-6.2.2.1 However, that's only for URIs which use the generic syntax (which most URIs we ever touch do use). It would be great if a normalized-IRI with specific normalization rules could be drafted up as part of the next WG charter - after all they are a pretty pivotal part of the sem web setup, and it would be relatively easy to clear up these issues. Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
In the short term, it sounds like there's a gap in the code-ecosystem for a really lightweight tool which took a stream of N-Triples and just output a normalised stream of N-Triples ready for import. The examples below would make a good initial test set for it. I'd write it if I didn't have a bunch of code-bunnies biting my ankles and demanding to be created. As for triple stores; I know that the number of triples-per-second on import can be important, so if you already know you're data is clean you'd want to at least make normalise-on-input optional to improve performance. On 17/01/11 16:57, Nathan wrote: Kingsley Idehen wrote: On 1/17/11 10:51 AM, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources Yes, where an RDF resource is a Data Container at an Address (URL). Thus, equivalent results for de-referencing a URL en route to accessing data. No, when resource also implies an Entity (Data Item or Data Object) that is assigned a Name via URI. Logically, yes on both counts, we should/could be normalizing these URIs as we consume and publish using the syntax based normalization rules [1] which apply to all URI/IRIs with the generic syntax (such as the examples above) Any client consuming data, or server publishing data, can use the normalization rules, so it stands to reason that it's pretty important that we all do it to avoid false negatives. [1] http://tools.ietf.org/html/rfc3986#section-6.2.2 Best, Nathan -- Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248 / Lead Developer, EPrints Project, http://eprints.org/ / Web Projects Manager, ECS, University of Southampton, http://www.ecs.soton.ac.uk/ / Webmaster, Web Science Trust, http://www.webscience.org/
RE: URI Comparisons: RFC 2616 vs. RDF
Hi, The doubt just kept on because in all protocols we were still referring to the same URN. Thank you for your explanation, and we've been using the owl:sameAs property for this. Nuno Bettencourt -Original Message- From: Nathan [mailto:nat...@webr3.org] Sent: segunda-feira, 17 de Janeiro de 2011 17:34 To: Nuno Bettencourt Cc: 'Dave Reynolds'; 'Martin Hepp'; public-lod@w3.org Subject: Re: URI Comparisons: RFC 2616 vs. RDF Nuno Bettencourt wrote: Hi, Even though I'll be deviating the point just a bit, since we're discussing URI comparison in terms of RDF, I would like to request some help. I have a doubt about URLs when it comes to RDF URI comparison. Is there any RFC that establishes if http://abc.com:80/~smith/home.html https://abc.com:80/~smith/home.html or even ftp://abc.com:80/~smith/home.html should or not be considered the same resource? No, and no such rules can be written (as they are case specific, and all the above URIs could easily, and often do, point to differing resources) - if all URIs point to the same resource then it should be stated as such by some other means, which in RDF would mean owl:sameas. Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
Nuno Bettencourt wrote: Hi, The doubt just kept on because in all protocols we were still referring to the same URN. do you mean that there were RDF statements which linked each of the protocol specific URIs to a single URN via the same property? eg: http://... x:foo urn:here https://... x:foo urn:here ftp://... x:foo urn:here If so, then you could define the property (x:foo above) as an Inverse Functional Property which would take care of the sameness for you. Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
On Mon, 2011-01-17 at 16:52 +, Nathan wrote: Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. I'd suggest that it's a little more complex than that, and that this may be an issue to clear up in the next RDF WG (it's on the charter I believe). I beg to differ. The charter does state: Clarify the usage of IRI references for RDF resources, e.g., per SPARQL Query §1.2.4. However, I was under the impression that was simply removing the small difference between RDF URI References and the IRI spec (that they had anticipated). Specifically I thought the only substantive issue there was the treatment of space and many RDF processors already take the conservation position on that anyway. Replacing encoded string equality by deference-equivalence would be a pretty big change to RDF and I hadn't realized that was being considered. Could one of the nominated chairs or a W3C rep clarify this? For example: When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI HTTP://www.EXAMPLE.com/ is equivalent to http://www.example.com/. - http://tools.ietf.org/html/rfc3986#section-6.2.2.1 Sure but the later RDF-related specs such as GRDDL and RIF clarify the application of that in RDF. For example in RIF [1] we said: Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in Sections 6.2.2 and 6.2.3 of RFC-3986) are performed. A form of words that, I think, we lifted verbatim from GRDDL which in turn had chosen them to clarify how the original RDF URI References spec should be interpreted in the light of the updated URI/IRI RFCs. Changing RDF to require syntax or scheme based normalization would require changing at least RIF and GRDDL as well. If that was really on the cards I would have expected it to have been more broadly publicized. Dave [1] http://www.w3.org/TR/2010/PR-rif-dtb-20100511/#Relative_IRIs
Re: URI Comparisons: RFC 2616 vs. RDF
Dave Reynolds wrote: On Mon, 2011-01-17 at 16:52 +, Nathan wrote: I'd suggest that it's a little more complex than that, and that this may be an issue to clear up in the next RDF WG (it's on the charter I believe). I beg to differ. The charter does state: Clarify the usage of IRI references for RDF resources, e.g., per SPARQL Query §1.2.4. However, I was under the impression that was simply removing the small difference between RDF URI References and the IRI spec (that they had anticipated). Specifically I thought the only substantive issue there was the treatment of space and many RDF processors already take the conservation position on that anyway. Likewise, apologies as I should have picked my choice of words more appropriately, I intended to say that the usage of IRI references was up for clarification, and if normalization were deemed an issue then the RDF WG may be the place to raise such an issue, and address if needed. As for RIF and GRDDL, can anybody point me to the reasons why normalization are not performed, does this have xmlns heritage? Best, Nathan
Re: URI Comparisons: RFC 2616 vs. RDF
On 1/17/11 12:27 PM, Nuno Bettencourt wrote: Hi, Even though I'll be deviating the point just a bit, since we're discussing URI comparison in terms of RDF, I would like to request some help. I have a doubt about URLs when it comes to RDF URI comparison. Is there any RFC that establishes if http://abc.com:80/~smith/home.html https://abc.com:80/~smith/home.html or even ftp://abc.com:80/~smith/home.html should or not be considered the same resource? All of the above are Addresses (based on what I can infer via my visual senses). The URI abstraction enables multiple scheme data access. ftp: and http: are schemes. None of them isA resource. They simply provide access to data why may be serialized in a variety of formats to a user agent that de-references any of these Addresses. Basically, network aware pointers with data representation dexterity courtesy of URI abstraction and HTTP's content negotiation. Kingsley Best regards, Nuno Bettencourt -Original Message- From: public-lod-requ...@w3.org [mailto:public-lod-requ...@w3.org] On Behalf Of Nathan Sent: segunda-feira, 17 de Janeiro de 2011 16:53 To: Dave Reynolds; Sandro Hawke Cc: Martin Hepp; public-lod@w3.org Subject: Re: URI Comparisons: RFC 2616 vs. RDF Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. I'd suggest that it's a little more complex than that, and that this may be an issue to clear up in the next RDF WG (it's on the charter I believe). For example: When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URIHTTP://www.EXAMPLE.com/ is equivalent tohttp://www.example.com/. - http://tools.ietf.org/html/rfc3986#section-6.2.2.1 However, that's only for URIs which use the generic syntax (which most URIs we ever touch do use). It would be great if a normalized-IRI with specific normalization rules could be drafted up as part of the next WG charter - after all they are a pretty pivotal part of the sem web setup, and it would be relatively easy to clear up these issues. Best, Nathan -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: ICWE 2011: Second Call for Papers
I much recommend to visit the lenedary city of Pafos, the birthplace of Aphrodite. Not because of the mentioned routine conferences, but for better reason: the hosting corporation has initiated the world's first intelligent green city (to be located in Aphrodite's holy gardens!), where the intelligent internet of things with a cloud computing knowledge center is to become a key feature, http://www.neapolis.com (download the brochure). Azamat Abdoullaev http://www.eis.com.cy Pafos, Cyprus - Original Message - From: Sören Auer a...@informatik.uni-leipzig.de To: Linking Open Data public-lod@w3.org; SW-forum semantic-...@w3.org; okfn-discuss okfn-disc...@lists.okfn.org Sent: Monday, January 17, 2011 5:35 PM Subject: ICWE 2011: Second Call for Papers 11th International Conference on Web Engineering (ICWE 2011) http://icwe2011.webengineering.org June 20-24, 2011, Paphos, Cyprus *** Second Call for Papers *** The International Conference on Web Engineering (ICWE) aims at promoting scientific and practical excellence on Web Engineering, and at bringing together researchers and practitioners working in technologies, methodologies, tools, and techniques used to develop and maintain Web-based applications leading to better systems, and thus to enabling and improving the dissemination and use of content and services through the Web. A special focus of ICWE 2011 will be Web Data Engineering. *Topics of Interest* The conference fosters original submissions covering, but not restricted to the following topics of interest: Web application engineering * Processes and methods for Web application development * Conceptual modeling of Web applications * Model-driven Web application development * Domain-specific languages for Web application development * Component-based Web application development * Web application architectures and frameworks * Rich Internet Applications * Mashup development and end user Web programming * Patterns for Web application development and pattern mining * Web content management and data-intensive Web applications * Web usability and accessibility * I18N of Web applications and multi-lingual development * Testing and evaluation of Web applications * Deployment and usage analysis of Web applications * Performance modeling, monitoring, and evaluation * Empirical Web engineering * Web quality and Web metrics * Adaptive, contextualized and personalized Web applications * Mobile Web applications and device-independent delivery Web service engineering * Web service engineering methodologies * Web Service-oriented Architectures * Semantic Web services * Web service-based architectures and applications * Quality of service and its metrics for Web applications * Inter-organizational Web applications * Ubiquity and pervasiveness * Linked Data Services Web data engineering * Semantic Web engineering * Web 2.0 technologies * Social Web applications * Web mining and information extraction * Linked Data * Web data linking, fusion * Information quality assessment * Data repair strategies * Dataset dynamics * Dataset introspection * Linked Data consumption, visualisation and exploration * Deep Web * Web science and Future Internet applications *Submission instructions* Authors of the research and industrial papers track must explain the relationship of their work to the Web Engineering discipline in their submissions. Research papers must comprise substantial innovative discussion with respect to the related work and must be well motivated and presented. * Extension: Papers must not be longer than 15 (fifteen) pages. * Format: according to the LNCS guidelines. * Submission: http://www.easychair.org/conferences/?conf=icwe2011 *Publishing of accepted works* The conference proceedings will be published by Springer-Verlag as an LNCS volume. Official proceedings will include: full papers (15 pages), demonstration papers (4 pages) and posters (4 pages). Workshop papers and contributions to the doctoral consortium will be published separately. Final versions of accepted papers must strictly adhere to the LNCS guidelines and must include a printable file of the camera-ready version, as well as all source files thereof. No changes to such formatting rules are permitted. Authors of accepted papers must also download and sign a copyright form that will be made available on the Web site of the conference. Each paper requires at least one full registration to the main conference. Selected papers will be invited to submit an extended version to a special issue of the JCR-indexed Journal Of Web Engineering (pending agreement). *Important Dates* * Submission deadline: February 14, 2011 (23:59 Hawaii Time) * Notification of acceptance: April 14, 2011 * Camera-ready version: April 28, 2011
Re: Property for linking from a graph to HTTP connection meta-data?
* [2011-01-17 16:39:27 +0100] Martin Hepp martin.h...@ebusiness-unibw.org écrit: ] Does anybody know of a standard property for linking a RDF graph to a ] http:GetRequest, http:Connection, or http:Response instance? Maybe ] rdfs:seeAlso (@TBL: ;- ))? If you suppose that the name of the graph is the same as the request URI (it will not always be, of course) you can link in the other direction from http:Request using http:requestURI. I am not sure that http:requestURI has a standard inverse though. Cheers, -w -- William Waitesmailto:w...@styx.org http://eris.okfn.org/ww/ sip:w...@styx.org F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Re: URI Comparisons: RFC 2616 vs. RDF
On 2011-01 -17, at 16:37, Dave Reynolds wrote: On Mon, 2011-01-17 at 16:51 +0100, Martin Hepp wrote: Dear all: RFC 2616 [1, section 3.2.3] says that When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of /. Characters other than those in the reserved and unsafe sets (see RFC 2396 [42]) are equivalent to their % HEX HEX encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html Does this also hold for identifying RDF resources a) in theory and Yes this does hold for RDF systems. You can't guarantee that all RDF systems will do it, so RDF systems should in general exchange canonicalized URIs. There is a ladder of levels at which smarter and smarter systems are aware of more and more equivalences. Good to make your system smart and not end up with widow graphs about http://WWW.w3.org/foo. cwm for example canonicalizes URIs when it loads them into the store. No. RDF Concepts defines equality of RDF URI References [1] as simply character-by-character equality of the %-encoded UTF-8 Unicode strings. Note the final Note in that section: Note: Because of the risk of confusion between RDF URI references that would be equivalent if derefenced, the use of %-escaped characters in RDF URI references is strongly discouraged. which explicitly calls out the difference between URI equivalence (dereference to the same resource) and RDF URI Reference equality. BTW the more up to date RFC for looking at equivalence (as opposed to equality) issues is probably the IRI spec [2] which defines a comparison ladder for testing equivalence. Exactly. Dave [1] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-URIref [2] http://www.ietf.org/rfc/rfc3987.txt
Re: Property for linking from a graph to HTTP connection meta-data?
William Waites wrote: * [2011-01-17 16:39:27 +0100] Martin Hepp martin.h...@ebusiness-unibw.org écrit: ] Does anybody know of a standard property for linking a RDF graph to a ] http:GetRequest, http:Connection, or http:Response instance? Maybe ] rdfs:seeAlso (@TBL: ;- ))? If you suppose that the name of the graph is the same as the request URI (it will not always be, of course) you can link in the other direction from http:Request using http:requestURI. I am not sure that http:requestURI has a standard inverse though. And remember of course, that the headers are split in to different groups which relate to different things, many relate to the message (in relation to the request), some relate to the server, some relate to the entity (an encoded version of the representation for messaging) a few (really not many) relate to the representation itself, and a couple relate to the resource itself, the resource being the thing the URI identifies. Best, Nathan
Re: Property for linking from a graph to HTTP connection meta-data?
Dear Martin, All, Just a reminder that you are looking at an old, outdated editors draft of the HTTP-in-RDF Vocabulary. The latest Public Working Draft is here: - http://www.w3.org/TR/HTTP-in-RDF10/ I seem to recall updates to the vocabulary that allow more flexibility to support uses as the one described below by Martin (though I did not check back specifically for that case). Please note that the W3C/WAI Evaluation and Repair Tools Working Group welcomes comments and feedback on HTTP-in-RDF (despite the long passed deadline). Please send comments to public-earl10-comme...@w3.org. Best, Shadi On 17.1.2011 20:23, Nathan wrote: William Waites wrote: * [2011-01-17 16:39:27 +0100] Martin Hepp martin.h...@ebusiness-unibw.org écrit: ] Does anybody know of a standard property for linking a RDF graph to a ] http:GetRequest, http:Connection, or http:Response instance? Maybe ] rdfs:seeAlso (@TBL: ;- ))? If you suppose that the name of the graph is the same as the request URI (it will not always be, of course) you can link in the other direction from http:Request using http:requestURI. I am not sure that http:requestURI has a standard inverse though. And remember of course, that the headers are split in to different groups which relate to different things, many relate to the message (in relation to the request), some relate to the server, some relate to the entity (an encoded version of the representation for messaging) a few (really not many) relate to the representation itself, and a couple relate to the resource itself, the resource being the thing the URI identifies. Best, Nathan -- Shadi Abou-Zahra - http://www.w3.org/People/shadi/ | WAI International Program Office Activity Lead | W3C Evaluation Repair Tools Working Group Chair |
Re: URI Comparisons: RFC 2616 vs. RDF
On 1/17/11 4:54 PM, Nuno Bettencourt wrote: Hi, thank you for the suggestion. This had been a problem before, which in fact becomes easier to solve like that. In my current situation, we were dealing with public/private/protected resources (files), secured by https. So, if a person/agent has a private/protected resource (file) (that only shares with some specific individuals and is only accessible using https protocol) it would be hosted under https://server/abc.html. For this, I would have for example, the following triple: 1) http://server/#me dc:publisher https://server/abc.html Nevertheless, if afterwards I publically publish that resource (file), for technical reasons that same resource (file) would be given a new URI http://server/abc.html so that it would not require authentication and a new triple would be created (for terms of simplicity I'm omitting other triples that are generated): 2) http://server/#me dc:publisher http://server/abc.html In fact, both those resources (files) are the same, mapped for the same physical file but while the first required SSL credentials, the second does not. In order for those users who before had access to the private resource, to keep accessing the resource, since it is now public (but has been moved from protected), I would had a triple in order for the semantic system to be able to retrieve the same resource, since it is no longer available under its original location. 3) https://server/abc.html owl:sameAs http://server/abc.html But at this point your context has changed, you are now make an assertion in a deductive data space. Basically, a record that is also a proposition re. RDF (or any other) deductive system. Again, the moment you make a triple, you are making a propositional statement. And the moment you do that, in the context of HTTP based Linked Data, it has to be something like this: https://server/abc.html#this owl:sameAs http://server/abc.html#this . If you don't care about Linked Data via HTTP user agents following links etc. ; meaning you're happy with a local graph of propositions that is SPARQL queryable, for instance, then this works too: https://server/abc.html owl:sameAs http://server/abc.html . This unfortunately leads to a minimal and probably unrealistic problem like an open URI https://server/abc.html that might not have any content, since there's no need for it as it has become public and no authentication is needed for accessing it - but it is necessary to keep that triple 1) alive as others might be consuming that information. Triple 3) helps those in finding the resource again. One and more rich possible solution might be implementing time reasoning mechanisms over this, in order to eliminate those 'fake' URIs, but that would grow the triple store and make reasoning even more time consuming (for now). No need for fake URIs (I guess you might think the #this above == fake), it's just comes down to Name References and the need for them to resolve to something useful, which may or may not be useful (e.g. navigable) to an HTTP agent, or deliver factual basis for inference by a deduction oriented engine (logic reasoner). I hope this helps. Kingsley Nuno -Original Message- From: Nathan [mailto:nat...@webr3.org] Sent: segunda-feira, 17 de Janeiro de 2011 18:06 To: Nuno Bettencourt Cc: public-lod@w3.org Subject: Re: URI Comparisons: RFC 2616 vs. RDF Nuno Bettencourt wrote: Hi, The doubt just kept on because in all protocols we were still referring to the same URN. do you mean that there were RDF statements which linked each of the protocol specific URIs to a single URN via the same property? eg: http://... x:foourn:here https://... x:foourn:here ftp://... x:foourn:here If so, then you could define the property (x:foo above) as an Inverse Functional Property which would take care of the sameness for you. Best, Nathan -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)
Hi, First: Thanks for the kind clarification! In parallel, we can discourage people to use rdfs:seeAlso to point to non-RDF resources in the future. It can easily be substituted by foaf:depiction for images and foaf:page for HTML resources without RDFa. Yes, exactly. FYI: The W3C HTTP headers ontology at http://www.w3.org/2008/http-headers uses rdfs:isDefinedBy to point to non-RDF resources, e.g. RFCs in plain text: rdf:Description rdf:about=#content-encoding rdfs:isDefinedBy rdf:resource=http://www.rfc-editor.org/rfc/rfc2616.txt / dc:description xml:lang=enThe Content-Encoding header/ dc:description dc:title xml:lang=enContent-Encoding/dc:title rdf:type rdf:resource=http://www.w3.org/2006/http#HeaderName/ /rdf:Description Since rdfs:isDefinedBy is a subproperty of rdfs:seeAlso, this may also clash with existing FOAF client code, unless the lack of inferencing in a given environment isolates the problem. The same holds also for http://www.w3.org/2008/http-methods http://www.w3.org/2008/http-statusCodes If there is agreement to avoid rdfs:seeAlso for non-RDF resources, we should also avoid rdfs:isDefinedBy. Best Martin
Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)
On 1/17/11 5:32 PM, Martin Hepp wrote: Hi, First: Thanks for the kind clarification! In parallel, we can discourage people to use rdfs:seeAlso to point to non-RDF resources in the future. It can easily be substituted by foaf:depiction for images and foaf:page for HTML resources without RDFa. Yes, exactly. FYI: The W3C HTTP headers ontology at http://www.w3.org/2008/http-headers uses rdfs:isDefinedBy to point to non-RDF resources, e.g. RFCs in plain text: rdf:Description rdf:about=#content-encoding rdfs:isDefinedBy rdf:resource=http://www.rfc-editor.org/rfc/rfc2616.txt/ dc:description xml:lang=enThe Content-Encoding header/dc:description dc:title xml:lang=enContent-Encoding/dc:title rdf:type rdf:resource=http://www.w3.org/2006/http#HeaderName/ /rdf:Description Since rdfs:isDefinedBy is a subproperty of rdfs:seeAlso, this may also clash with existing FOAF client code, unless the lack of inferencing in a given environment isolates the problem. The same holds also for http://www.w3.org/2008/http-methods http://www.w3.org/2008/http-statusCodes If there is agreement to avoid rdfs:seeAlso for non-RDF resources, we should also avoid rdfs:isDefinedBy. +1 Kingsley Best Martin -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Property for linking from a graph to HTTP connection meta-data?
* [2011-01-17 23:09:01 +0100] Martin Hepp martin.h...@ebusiness-unibw.org écrit: ] # Link the graph to the HTTP header info from the data transformation ] foo:dataset rdfs:seeAlso foo:ResponseMetaData . Actually this seems like a use case for OPMV. So I think you'd do something like, foo:dataset opmv:wasGeneratedBy [ a opmv:Process; opmv:used foo:ResponseMetaData; opmv:used http://example.org/foo.xml ]. This would have the side-effect of making your graph an opmv:Artifact but that actually makes sense. Cheers, -w -- William Waitesmailto:w...@styx.org http://eris.okfn.org/ww/ sip:w...@styx.org F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Re: Property for linking from a graph to HTTP connection meta-data?
On 1/17/11 5:09 PM, Martin Hepp wrote: Hi All: Thanks for the very useful feedback! Just to clarify what I want to do: There are many valuable commerce data resources available in XML and CSV on the Web. It is fairly straightforward to translate them into RDF, e.g. using GoodRelations. Now, whenever I create an RDF representation of that data in a new namespace, I may want to store the meta-data of the original HTTP GET request with which I fetched the XML or CSV file, and attach that meta-data to the resulting RDF graph. This allows for (1) nice analytics and (2) data cleansing entirely in the SPARQL / RDF world later-on. So the subject to which the meta-data will be attached will not be the resource URI (because there can naturally be multiple HTTP GET requests for the same resource), but instead the resulting graph or dataset. Just double checking that you know the Virtuoso Sponger has always delivered the above. I typically disable this feature as many misunderstand these triples to be noise [1] :-( Links: 1. http://linkeddata.uriburner.com/c/DQ7MQ4 -- ODE session based on Groupon Offer transformation 2. http://uriburner.com/fct/facet.vsp?cmd=loadfsq_id=68 -- shows results for search on entities associated with pattern: application/rdf+xml [SNIP] -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen