Re: ANN: geometry2rdf software library

2011-01-17 Thread Boris Villazón Terrazas

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

2011-01-17 Thread Giovanni Tummarello
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

2011-01-17 Thread Chris Bizer
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)

2011-01-17 Thread Stephane Fellah
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

2011-01-17 Thread Sören Auer

  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

2011-01-17 Thread Chris Bizer
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?

2011-01-17 Thread Martin Hepp

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)

2011-01-17 Thread Christopher Gutteridge
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

2011-01-17 Thread Martin Hepp

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

2011-01-17 Thread Kingsley Idehen

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

2011-01-17 Thread Dave Reynolds
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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Kingsley Idehen

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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Renaud Delbru

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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Nuno Bettencourt
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

2011-01-17 Thread Christopher Gutteridge
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

2011-01-17 Thread Nuno Bettencourt
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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Dave Reynolds
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

2011-01-17 Thread Nathan

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

2011-01-17 Thread Kingsley Idehen

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

2011-01-17 Thread AzamatAbdoullaev
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 Thread William Waites
* [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

2011-01-17 Thread Tim Berners-Lee

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?

2011-01-17 Thread Nathan

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?

2011-01-17 Thread Shadi Abou-Zahra

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

2011-01-17 Thread Kingsley Idehen

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?)

2011-01-17 Thread Martin Hepp

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?)

2011-01-17 Thread Kingsley Idehen

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 Thread William Waites

* [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?

2011-01-17 Thread Kingsley Idehen

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