Call for Papers - Semantic Cities at AAAI 2012 - Extended Deadline
Apologies for cross-postings. Call for Papers: The AAAI 2012 Workshop on Semantic Cities Toronto, Ontario, Canada; July 22-26, 2012 http://research.ihost.com/semanticcities12/index.html Description: Cities around the world aspire to provide superior quality of life to their citizens. An increasing number have realized that opening access to their data, and building semantic models to abstract as well as interconnect them; can unleash economic growth while addressing sustainability issues. We call cities that enable such capabilities as, semantic cities. In a Semantic City, available resources are harnessed safely, sustainably and efficiently to achieve positive, measurable economic and societal outcomes. Enabling City information as a utility, through a robust (expressive, dynamic, scalable) and (critically) a sustainable technology and socially synergistic ecosystem could drive significant benefits and opportunities. Data (and then information and knowledge) from people, systems and things is the single most scalable resource available to City stakeholders to reach the objective of semantic cities. Two major trends are supporting semantic cities: open data and semantic web. Open data is the idea that certain data should be freely available to everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control. A number of cities and government have made their data publicly available, prominent being London (UK), Chicago (USA), Washington DC (USA), Dublin (Ireland). Semantic web as the technology to inter-connect heterogeneous data has matured and it is being increasing used in the form of Linked Open Data and formal ontologies. Thus, a play-field for more AI research-driven technologies for cities has emerged. In this context, the aims of the workshop are to: 1. Draw the attention of the AI community to the research challenges and opportunities in semantic cities. 2. Draw the attention on the multi-disciplinary dimension and its impact on semantic cities e.g., transportation, energy, water management 3. Identify unique issues of this domain and what new techniques may be needed. As example, since governments and citizens are involved, data security and privacy are first-class concerns. 4. Promoting more cities to become semantic cities 5. Elaborating a (semantic data) benchmark for testing AI techniques on semantic cities 6. Provide a platform for sharing best-practices and discussion We encourage submissions that show the relevance or application of AI technologies for computational sustainability domains. Apart from focus on foundational technologies for semantic cities (information management, knowledge management, ontology, inference model, data integration), we want to promote illustrative use-cases using the semantic cities foundation. Examples are transportation (traffic prediction, personal travel optimization, carpool and fleet scheduling), public safety (suspicious activity detection, disaster management), healthcare (disease diagnosis and prognosis, pandemic management), water management (flood prevision, quality monitoring, fault diagnosis), food (food traceability, carbon-footprint tracking), energy (smart grid, carbon footprint tracking, electricity consumption forecasting) and buildings (energy conservation, fault detections). We also encourage submissions that address unique characteristics of standard AI enabling sustainability problems, like optimization, reasoning, planning and learning. Outside AI, we encourage submission from communities engaged in open data and corresponding standardization efforts, to make their work available at this AI forum. Topics of interest include, but not restricted to, are: 1. Process to open city (government) data 2. Platforms to manage government data 3. Provenance, access control and privacy-preserving issues in open data 4. Data cities interoperability 5. Semantic models, especially those built collaboratively and evolving 6. Data integration and organization in semantic cities (social media feeds, sensor data) 7. Internet of Things in semantic cities 8. Robust inference models for semantic cities 9. Semantic Event detection and classification 10. Applications in semantic cities 11. Spatio-temporal analysis and visualization 12. User interaction in exploring semantic data of cities 13. Knowledge representation and reasoning challenges 14. Knowledge acquisition, evolution and maintenance 15. Challenges with managing and integrating real-time and historical data 16. Managing big data 17. Integrated systems 18. Applied AI models for semantic cities 19. Issues in scaling out AI techniques for semantic cities 20. Case Studies, successes, lessons learnt 21. Public datasets and competitions Workshop Plan: Workshop Format: The workshop will consist of papers and poster presentations, a panel, an invited talk, and discussion sessions, in a one full day schedule. The invited talk will invite a
Re: NIR SIDETRACK Re: Change Proposal for HttpRange-14
Hello Jonathan, On Sun, Apr 01, 2012 at 05:05:10PM +0200, Jonathan A Rees wrote: Hmm... so from a 200 statuscode and HR14, I can conclude that I have a representation of it, that is is an IR and therefor has a representation that conveys the essential characteristics of it (definition of IR at http://www.w3.org/2001/tag/doc/uddp-20120229/), but not that the representation I got actually is a representation that conveys the essential characteristics of it ? Well not necessarily. The problem is that 'representation' has at least three different meanings in these discussions. There's (1) the REST / AWWW glossary / HTTPbis definition, the record of the state of something, which I take to mean that descriptions, as well as depictions, content, etc. are representations. There's (2) the usage where it means expression or encoding of information, similar to what I call instance or TimBL calls content, which would be a special case of (1). (2) shows up in RFC 2616 and in parts of AWWW. Then there's 'representation' as (3) whatever you get in a 200 response, what I call nominal representation. (1)=(3) if the manner of 'representing' can be idiosyncratic to each resource. So you have to be careful which sense you mean. Most of the specs are pretty murky on this, and that's part, maybe most, of the reason why the conversation is so incredibly painful. I meant 2) but that is not relevant because if you take what is written in http://www.w3.org/2001/tag/doc/uddp-20120229/ as granted, my statement not only holds for the special case 2), but also for the general case 1). I thought current representation of in http://www.w3.org/2001/tag/doc/uddp-20120229/ refers to something more like 2) and definitely not to mere descriptions but when I look at it there seems to be nothing to back this. But whatever representation means exactly, I would rephrase the sentence that the identified resource is an information resource (see below). in http://www.w3.org/2001/tag/doc/uddp-20120229/ to that the identified resource has a representation that conveys it's essential characteristics (see below). This makes it clearer what conclusions you cannot draw and avoids the term information resource in the important sentence while basically saying the same. Regards, Michael Brunnbauer -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail bru...@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: NIR SIDETRACK Re: Change Proposal for HttpRange-14
Hello Jonathan, On Tue, Apr 03, 2012 at 02:05:29PM +0200, Michael Brunnbauer wrote: I thought current representation of in http://www.w3.org/2001/tag/doc/uddp-20120229/ refers to something more like 2) and definitely not to mere descriptions but when I look at it there seems to be nothing to back this. BTW: If it is true that nothing backs this interpretation, then the IR stuff in http://www.w3.org/2001/tag/doc/uddp-20120229/ would be the only thing that stops somebody from calling his homepage a representation of himself and using it's URI for denoting himself. Regards, Michael Brunnbauer -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail bru...@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
NISO/DCMI Webinar with Dan Brickley: Schema.org and Linked Data
***Please excuse the cross-posting*** === NISO/DCMI Webinar: Schema.org and Linked Data: Complementary Approaches to Publishing Data PRESENTER: Dan Brickley DATE: April 25, 2012 TIME: 1:00pm - 2:30pm Eastern (17:00-18:30 UTC) INFORMATION REGISTRATION: http://www.niso.org/news/events/2012/dcmi/linked_data/ === ABOUT THE WEBINAR Schema.org--a collaboration of the Google, Yahoo!, and Bing search engines--provides a way to include structured data in Web pages. Since its introduction in June 2011, the Schema.org vocabulary has grown to cover descriptive terms for content such as movies, music, organizations, TV shows, products, locations, news items, and job listings. The goal of Schema.org is to improve the display of search results, making it easier for people to find the right web pages. The Schema.org initiative has emerged as a focal point for publishers of structured data in Web pages, especially but not exclusively in the commercial sector. This webinar will explore how the publication methods of Schema.org relate to the methods used to publish Linked Data. Must data providers commit to one or the other, or can the two approaches exist side-by-side, even reinforcing each other? TOPICS AND SPEAKERS Dan Brickley is best known for his work on Web standards in the W3C community, where he helped create the Semantic Web project and many of its defining technologies. Dan is currently working on outreach activities related to the Schema.org initiative. Previous work included six years on the W3C technical staff, establishing ILRT's Semantic Web group at the University of Bristol, and more recently at Joost, an Internet TV start-up, and at the Vrije University Amsterdam. He has been involved with resource discovery metadata since 1994 when he published the first HTML Philosophy guide on the Web, and has been exploring distributed, collaborative approaches to finding stuff ever since. Thomas Baker, Chief Information Officer of the Dublin Core Metadata Initiative, has recently co-chaired the W3C Semantic Web Deployment Working Group and the W3C Incubator Group on Library Linked Data. REGISTRATION Registration is per site (access for one computer) and closes at 12:00 pm Eastern (16:00 UTC) on April 25, 2012. Discounts are available for NISO and DCMI members and students. Can't make it on the webinar date/time? Register now and gain access to the recorded archive for one year. NISO/DCMI are holding four joint webinars in 2012. Register for three and receive the 4th for free. For more information and to register, visit the event webpage: http://www.niso.org/news/events/2012/dcmi/linked_data/
Re: Datatypes with no (cool) URI
On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: Datatypes with no (cool) URI
Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Re: Datatypes with no (cool) URI
On 03/04/2012 15:53, John Erickson wrote: On Tue, Apr 3, 2012 at 10:38 AM, David Boothda...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? What shall we do? Start a petition? Go on a march through Geneva? (it's nice there this time of year). Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl Yep, that would do the job certainly. Hmmm... unless Crossref could mint URIs out of, say, ISO/IEC 5218:2004 ?? I'm sure it could but is the demand sufficient and would ISO allow it? -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
RE: Datatypes with no (cool) URI
I am a researcher working on some Demographic Social Simulation Models. In the simple models, I distinguish people classed male at birth and people classed female at birth and gender ambiguity, reassignment (sex change) and gender recalssification are not modelled. In more complicated models these things might be modelled and if I were modelling that, I would consider storing a list of changes and have more classes or somehow quantify maleness and femaleness. The point I am making here is that the assignment of gender (or sex depending on what word you prefer) could be time dependent. In an attempt to make my data storage and retrieval work better I implemented two main data stores for people: those classed female at birth; those classed male at birth. In my models, even if current gender were re-assigned data for that individual would still be stored in the same data store. I suspect that in ambiguous cases in reality what is done in terms of gender classification might be different for different countries. BTW: gender ambiguity was topical in the mainstream media in the Autumn in the UK [1]. It is not as uncommon as you might think... So, gender is a fuzzy thing. Maybe we all belong to male and female classes to a degree and for most of us this distinction is binary. In terms of encoding, in my implementations I've used 0 for female and 1 for male as I find that easy to remember and computationally it makes sense. Andy [1] http://www.bbc.co.uk/news/health-14459843 From: Phil Archer [ph...@w3.org] Sent: 03 April 2012 14:33 To: public-lod@w3.org Subject: Datatypes with no (cool) URI I'm hoping for a bit of advice and rather than talk in the usual generic terms I'll use the actual example I'm working on. I want to define the best way to record a person's sex (this is related to the W3C GLD WG's forthcoming spec on describing a Person [1]). To encourage interoperability, we want people to use a controlled vocabulary and there are several that cover this topic. ISO 5218 has: 0 = not known; 1 = male; 2 = female; 9 = not applicable. and Eurostat offers F = female M = male OTH = other UNK = unknown NAP = not applicable IMO, the spec should not dictate which one to use (there are others too of course). What I *do* want to do though is to encourage publishers to state which vocabulary they're using. Sounds like a job for a datatype - and for that you need a URI for the vocabulary. Something like: schema:gender 1^^http://iso.org/5218/ . Except I made that iso.org URI up. The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? Given that the identifier for the ISO standard is ISO/IEC 5218:2004 how about urn:iso/iec:5218:2005? For Eurostat, the internal identifier for the vocabulary is SCL - Sex (standard code list) so would urn:eurostat:scl:sex be appropriate? Anyone done anything like this in the real world? All advice gratefully received. Thank you Phil. [1] https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1
Re: Datatypes with no (cool) URI
The ideal thing would be if ISO, Eurostat produced concise resolvable URIs of course. But while we wait for them to do that, why doesn't W3C mint and support URIs for the most commonly used code lists, that resolve to relevant documentation and/or links to the definitive documents from ISO etc. Cheers Bill On 3 Apr 2012, at 15:58, Phil Archer wrote: Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Re: Datatypes with no (cool) URI
Okay, then maybe a PURL would help? purl.org now supports partial redirects: http://purl.org/docs/faq.html#toc1.9 That may not quite work with your ISO URIs though. Personally, I don't think you should worry too much about a machine expecting to be able to dereference the datatype URI to get data back. I would expect most datatype URIs would lead to human-oriented information, though that could gradually change. David On Tue, 2012-04-03 at 15:58 +0100, Phil Archer wrote: Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Re: Datatypes with no (cool) URI
There are just some things outside of the Web's bailiwick, and the properties of people in that class. The problem is that you are never sure if you are naming the property on rudely calling the property holder names. ISO declines to play, the LOC declines differently http://id.loc.gov/authorities/subjects/sh91003756 and simple classes don't exist. I think you've hit a limit, not on Cool Uri's necessarily, but maybe on philosophy. From: John Erickson olyerick...@gmail.com To: David Booth da...@dbooth.org Cc: Phil Archer ph...@w3.org; public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 9:53 AM Subject: Re: Datatypes with no (cool) URI On Tue, Apr 3, 2012 at 10:38 AM, David Booth da...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson
Re: Datatypes with no (cool) URI
Gannon raises a valid point, BUT it is important to remember that ISO is a *publisher* and DOI is fundamentally a publishing industry thing. So while they might not be inclined to support Cool URIs for their own sake, they might be DOI adopters for the sake of The Bottom Line... On Tue, Apr 3, 2012 at 11:19 AM, Gannon Dick gannon_d...@yahoo.com wrote: There are just some things outside of the Web's bailiwick, and the properties of people in that class. The problem is that you are never sure if you are naming the property on rudely calling the property holder names. ISO declines to play, the LOC declines differently http://id.loc.gov/authorities/subjects/sh91003756 and simple classes don't exist. I think you've hit a limit, not on Cool Uri's necessarily, but maybe on philosophy. From: John Erickson olyerick...@gmail.com To: David Booth da...@dbooth.org Cc: Phil Archer ph...@w3.org; public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 9:53 AM Subject: Re: Datatypes with no (cool) URI On Tue, Apr 3, 2012 at 10:38 AM, David Booth da...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson
Re: Datatypes with no (cool) URI
So David's solution (using PURLs) provides a bit of transparency and manageablity, but it has the disadvantage of having no official status. Maybe (probably) I'm missing something here? On Tue, Apr 3, 2012 at 11:19 AM, David Booth da...@dbooth.org wrote: Okay, then maybe a PURL would help? purl.org now supports partial redirects: http://purl.org/docs/faq.html#toc1.9 That may not quite work with your ISO URIs though. Personally, I don't think you should worry too much about a machine expecting to be able to dereference the datatype URI to get data back. I would expect most datatype URIs would lead to human-oriented information, though that could gradually change. David On Tue, 2012-04-03 at 15:58 +0100, Phil Archer wrote: Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer. -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson
Re: Datatypes with no (cool) URI
As Bill suggests: If you use a URI from an authoritative source that serves the terms, you don't have to wait for ISO to start doing it themselves. This has been done to some extent in several efforts in the bio area, in chronological order: http://bio2rdf.org/ A framework of federated PURLs was set up at http://sharednames.org and the latest and greatest: (Bio2RDF supports) http://identifiers.org In the above schemes, an example URI would be shorter and served by a third party. See http://identifiers.org/examples -Scott On Tue, Apr 3, 2012 at 5:10 PM, Bill Roberts b...@swirrl.com wrote: The ideal thing would be if ISO, Eurostat produced concise resolvable URIs of course. But while we wait for them to do that, why doesn't W3C mint and support URIs for the most commonly used code lists, that resolve to relevant documentation and/or links to the definitive documents from ISO etc. Cheers Bill On 3 Apr 2012, at 15:58, Phil Archer wrote: Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Re: Datatypes with no (cool) URI
If it helps, gender would be a subclass of http://purl.org/pii/terms/marks If you show me where to point, I'll create the PURL's. It may take me an hour to remember my passwords :o) From: John Erickson olyerick...@gmail.com To: David Booth da...@dbooth.org Cc: Phil Archer ph...@w3.org; public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 10:26 AM Subject: Re: Datatypes with no (cool) URI So David's solution (using PURLs) provides a bit of transparency and manageablity, but it has the disadvantage of having no official status. Maybe (probably) I'm missing something here? On Tue, Apr 3, 2012 at 11:19 AM, David Booth da...@dbooth.org wrote: Okay, then maybe a PURL would help? purl.org now supports partial redirects: http://purl.org/docs/faq.html#toc1.9 That may not quite work with your ISO URIs though. Personally, I don't think you should worry too much about a machine expecting to be able to dereference the datatype URI to get data back. I would expect most datatype URIs would lead to human-oriented information, though that could gradually change. David On Tue, 2012-04-03 at 15:58 +0100, Phil Archer wrote: Hi David, Yes, one could use URL shorteners and that's probably the only sane way to go but it's still not ideal because: 1. Both Bitly and Tinyurl come with no guarantee of service (and a lot of tracking) - Google's goo.gl is all wrapped up with their services too - not the kind of thing public administrations will be happy about using. Yves Lafon's http://kwz.me is a pure shortener with no tracking of any kind but it's a one man project so, again, it won't be 'good enough' for public sector data. 2. Neither a shortened URL nor the long form tell a human reader a lot whereas something (non-standard I know) like urn:iso/iec:5218:2004 tells you that it's an ISO standard that a human can look up. The ISO catalogue URLs point to Web pages or PDFs available from those Web pages so you still need to be a human to get the information. The danger would be that a machine would look up the datatype URI and expect to get data back, not ISO's paywall :-) So, not ideal, but still the best (practical) solution? On 03/04/2012 15:38, David Booth wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer. -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson
Re: Datatypes with no (cool) URI
On 12-04-03 02:33 PM, Phil Archer wrote: I'm hoping for a bit of advice and rather than talk in the usual generic terms I'll use the actual example I'm working on. I want to define the best way to record a person's sex (this is related to the W3C GLD WG's forthcoming spec on describing a Person [1]). To encourage interoperability, we want people to use a controlled vocabulary and there are several that cover this topic. ISO 5218 has: 0 = not known; 1 = male; 2 = female; 9 = not applicable. and Eurostat offers F = female M = male OTH = other UNK = unknown NAP = not applicable IMO, the spec should not dictate which one to use (there are others too of course). What I *do* want to do though is to encourage publishers to state which vocabulary they're using. Sounds like a job for a datatype - and for that you need a URI for the vocabulary. Something like: schema:gender 1^^http://iso.org/5218/ . Except I made that iso.org URI up. The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? Given that the identifier for the ISO standard is ISO/IEC 5218:2004 how about urn:iso/iec:5218:2005? For Eurostat, the internal identifier for the vocabulary is SCL - Sex (standard code list) so would urn:eurostat:scl:sex be appropriate? Anyone done anything like this in the real world? All advice gratefully received. Thank you Phil. [1] https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html Perhaps I'm looking at your problem the wrong way, but have you looked at the SDMX Concepts: http://purl.org/linked-data/sdmx/2009/code#sex -Sarven
Re: Datatypes with no (cool) URI
Again, thanks everyone for the quick and useful responses. @Gannon, @Andy - you are right that the issue of sex/gender is far from straightforward (they're not even the same thing I've learned!) However, I need to offer 'something' even if it's not ideal and then work on the longer term. @Sarven - SDMX looks very useful indeed, hadn't seen that they cover gender - great. But it doesn't answer the more general point (I was using sex/gender as an example - there are other terms for which the value space should be a controlled vocabulary that doesn't necessarily have a URI). Here's my plan of action: Short term: the limitation here is that all I'm chartered/empowered to do is to define the terms (actually I'm planning to use schema:gender). I am not, and I don't believe the EU (current project paymasters) or the GLD WG/W3C more generally is not, in a position to set up some sort of de-referencing system. Even setting up Purls means that we're in effect condoning a value space (and I have at least 3 on my radar for just this term alone - Gannon pointed to some useful info from LoC which might make 4, plus SDMX makes 5). So I'm going to have to fudge it for now and say 'provide an identifier' and may leave it at that. I'd like to offer more guidance but it may not be sensible to do so (and btw. these vocabularies have to work in XML as well as RDF). Longer term... I think I'll drop a line to Norman Paskin at the DOI Foundation... Phil. On 03/04/2012 16:22, John Erickson wrote: Gannon raises a valid point, BUT it is important to remember that ISO is a *publisher* and DOI is fundamentally a publishing industry thing. So while they might not be inclined to support Cool URIs for their own sake, they might be DOI adopters for the sake of The Bottom Line... On Tue, Apr 3, 2012 at 11:19 AM, Gannon Dickgannon_d...@yahoo.com wrote: There are just some things outside of the Web's bailiwick, and the properties of people in that class. The problem is that you are never sure if you are naming the property on rudely calling the property holder names. ISO declines to play, the LOC declines differently http://id.loc.gov/authorities/subjects/sh91003756 and simple classes don't exist. I think you've hit a limit, not on Cool Uri's necessarily, but maybe on philosophy. From: John Ericksonolyerick...@gmail.com To: David Boothda...@dbooth.org Cc: Phil Archerph...@w3.org; public-lod@w3.orgpublic-lod@w3.org Sent: Tuesday, April 3, 2012 9:53 AM Subject: Re: Datatypes with no (cool) URI On Tue, Apr 3, 2012 at 10:38 AM, David Boothda...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Re: Datatypes with no (cool) URI
Not so fast, young man ... The general point is indeed a minefield. see also: http://www.rustprivacy.org/2011/cnpii.xml (Common Names of Personally Identifiable Information) I think, but I doubt anyone else in the universe does, that you can fix the problem by looking at RDF Lists a bit differently. In particular, rdf:nil / should be a fallback to generality, not empty of truth. This is the Sherlock Holmes Method ... ... when you have eliminated the impossible, whatever remains, however improbable, must be the truth. That said, good plan. --Gannon From: Phil Archer ph...@w3.org To: public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 10:58 AM Subject: Re: Datatypes with no (cool) URI Again, thanks everyone for the quick and useful responses. @Gannon, @Andy - you are right that the issue of sex/gender is far from straightforward (they're not even the same thing I've learned!) However, I need to offer 'something' even if it's not ideal and then work on the longer term. @Sarven - SDMX looks very useful indeed, hadn't seen that they cover gender - great. But it doesn't answer the more general point (I was using sex/gender as an example - there are other terms for which the value space should be a controlled vocabulary that doesn't necessarily have a URI). Here's my plan of action: Short term: the limitation here is that all I'm chartered/empowered to do is to define the terms (actually I'm planning to use schema:gender). I am not, and I don't believe the EU (current project paymasters) or the GLD WG/W3C more generally is not, in a position to set up some sort of de-referencing system. Even setting up Purls means that we're in effect condoning a value space (and I have at least 3 on my radar for just this term alone - Gannon pointed to some useful info from LoC which might make 4, plus SDMX makes 5). So I'm going to have to fudge it for now and say 'provide an identifier' and may leave it at that. I'd like to offer more guidance but it may not be sensible to do so (and btw. these vocabularies have to work in XML as well as RDF). Longer term... I think I'll drop a line to Norman Paskin at the DOI Foundation... Phil. On 03/04/2012 16:22, John Erickson wrote: Gannon raises a valid point, BUT it is important to remember that ISO is a *publisher* and DOI is fundamentally a publishing industry thing. So while they might not be inclined to support Cool URIs for their own sake, they might be DOI adopters for the sake of The Bottom Line... On Tue, Apr 3, 2012 at 11:19 AM, Gannon Dickgannon_d...@yahoo.com wrote: There are just some things outside of the Web's bailiwick, and the properties of people in that class. The problem is that you are never sure if you are naming the property on rudely calling the property holder names. ISO declines to play, the LOC declines differently http://id.loc.gov/authorities/subjects/sh91003756 and simple classes don't exist. I think you've hit a limit, not on Cool Uri's necessarily, but maybe on philosophy. From: John Ericksonolyerick...@gmail.com To: David Boothda...@dbooth.org Cc: Phil Archerph...@w3.org; public-lod@w3.orgpublic-lod@w3.org Sent: Tuesday, April 3, 2012 9:53 AM Subject: Re: Datatypes with no (cool) URI On Tue, Apr 3, 2012 at 10:38 AM, David Boothda...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
ANN: LDIF - Linked Data Integration Framework Version 0.5 'Quality and Fusion' released.
Hi all, the Web-based Systems Group and our industry partner mes |semantics are happy to announce the release of the LDIF Linked Data Integration Framework Version 0.5 'Quality and Fusion'. LDIF can be used within Linked Data applications to translate heterogeneous data from the Web of Linked Data into a clean local target representation while keeping track of data provenance. LDIF translates data from the Web into a consistent target vocabulary, includes an identity resolution component which translates URI aliases into single target URI and fuses data of instances to resolve value conflicts. Version 0.5 includes the following new features: - a data quality assessment and fusion module (Sieve) for cleansing data according to user-provided quality assessment policies and conflict resolution methods; - a more flexible Integration workflow: single phases can now be executed or skipped; - a REST based status monitor; - improvements in the Output module: QuadStore and intermediate results outputs are now supported; - improvements in the Data Access module: RDF/XML and Turtle formats are now supported and - several bug fixes. LDIF is provided under the terms of the Apache Software License. LDIF can be downloaded from the project webpage which also provides detailed information about the features and the configuration of the framework: http://ldif.wbsg.de/ The development of LDIF is supported in part by Vulcan Inc. as part of its Project Halo and by the EU FP7 project LOD2 (Grant No. 257943). Cheers, Andreas Schultz, Andrea Matteini, Robert Isele, Pablo N. Mendes, Chris Bizer and Christian Becker
Re: Datatypes with no (cool) URI
oops. http://www.rustprivacy.org/2011/pii/cnpii.xml From: Gannon Dick gannon_d...@yahoo.com To: Phil Archer ph...@w3.org; public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 11:46 AM Subject: Re: Datatypes with no (cool) URI Not so fast, young man ... The general point is indeed a minefield. see also: http://www.rustprivacy.org/2011/cnpii.xml (Common Names of Personally Identifiable Information) I think, but I doubt anyone else in the universe does, that you can fix the problem by looking at RDF Lists a bit differently. In particular, rdf:nil / should be a fallback to generality, not empty of truth. This is the Sherlock Holmes Method ... ... when you have eliminated the impossible, whatever remains, however improbable, must be the truth. That said, good plan. --Gannon From: Phil Archer ph...@w3.org To: public-lod@w3.org public-lod@w3.org Sent: Tuesday, April 3, 2012 10:58 AM Subject: Re: Datatypes with no (cool) URI Again, thanks everyone for the quick and useful responses. @Gannon, @Andy - you are right that the issue of sex/gender is far from straightforward (they're not even the same thing I've learned!) However, I need to offer 'something' even if it's not ideal and then work on the longer term. @Sarven - SDMX looks very useful indeed, hadn't seen that they cover gender - great. But it doesn't answer the more general point (I was using sex/gender as an example - there are other terms for which the value space should be a controlled vocabulary that doesn't necessarily have a URI). Here's my plan of action: Short term: the limitation here is that all I'm chartered/empowered to do is to define the terms (actually I'm planning to use schema:gender). I am not, and I don't believe the EU (current project paymasters) or the GLD WG/W3C more generally is not, in a position to set up some sort of de-referencing system. Even setting up Purls means that we're in effect condoning a value space (and I have at least 3 on my radar for just this term alone - Gannon pointed to some useful info from LoC which might make 4, plus SDMX makes 5). So I'm going to have to fudge it for now and say 'provide an identifier' and may leave it at that. I'd like to offer more guidance but it may not be sensible to do so (and btw. these vocabularies have to work in XML as well as RDF). Longer term... I think I'll drop a line to Norman Paskin at the DOI Foundation... Phil. On 03/04/2012 16:22, John Erickson wrote: Gannon raises a valid point, BUT it is important to remember that ISO is a *publisher* and DOI is fundamentally a publishing industry thing. So while they might not be inclined to support Cool URIs for their own sake, they might be DOI adopters for the sake of The Bottom Line... On Tue, Apr 3, 2012 at 11:19 AM, Gannon Dickgannon_d...@yahoo.com wrote: There are just some things outside of the Web's bailiwick, and the properties of people in that class. The problem is that you are never sure if you are naming the property on rudely calling the property holder names. ISO declines to play, the LOC declines differently http://id.loc.gov/authorities/subjects/sh91003756 and simple classes don't exist. I think you've hit a limit, not on Cool Uri's necessarily, but maybe on philosophy. From: John Ericksonolyerick...@gmail.com To: David Boothda...@dbooth.org Cc: Phil Archerph...@w3.org; public-lod@w3.orgpublic-lod@w3.org Sent: Tuesday, April 3, 2012 9:53 AM Subject: Re: Datatypes with no (cool) URI On Tue, Apr 3, 2012 at 10:38 AM, David Boothda...@dbooth.org wrote: On Tue, 2012-04-03 at 14:33 +0100, Phil Archer wrote: [ . . . ] The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? It's helpful to be able to click on the URI to figure out what exactly was meant. How about just using a URI shortener, such as tinyurl.com or bit.ly? David's good point raises an even bigger point: why isn't ISO minting DOI's for specs? Or, at least, why can't ISO manage a DOI-equivalent space that would rein-in bogusly-long URIs, make them more manageable, and perhaps more functional e.g. CrossRef's Linked Data-savvy DOI proxy http://bit.ly/HcStYl -- John S. Erickson, Ph.D. Director, Web Science Operations Tetherless World Constellation (RPI) http://tw.rpi.edu olyerick...@gmail.com Twitter Skype: olyerickson -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Re: Datatypes with no (cool) URI
On 03/04/12 16:38, Sarven Capadisli wrote: On 12-04-03 02:33 PM, Phil Archer wrote: I'm hoping for a bit of advice and rather than talk in the usual generic terms I'll use the actual example I'm working on. I want to define the best way to record a person's sex (this is related to the W3C GLD WG's forthcoming spec on describing a Person [1]). To encourage interoperability, we want people to use a controlled vocabulary and there are several that cover this topic. ISO 5218 has: 0 = not known; 1 = male; 2 = female; 9 = not applicable. and Eurostat offers F = female M = male OTH = other UNK = unknown NAP = not applicable IMO, the spec should not dictate which one to use (there are others too of course). What I *do* want to do though is to encourage publishers to state which vocabulary they're using. Sounds like a job for a datatype - and for that you need a URI for the vocabulary. Something like: schema:gender 1^^http://iso.org/5218/ . Except I made that iso.org URI up. The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? Given that the identifier for the ISO standard is ISO/IEC 5218:2004 how about urn:iso/iec:5218:2005? For Eurostat, the internal identifier for the vocabulary is SCL - Sex (standard code list) so would urn:eurostat:scl:sex be appropriate? Anyone done anything like this in the real world? All advice gratefully received. Thank you Phil. [1] https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html Perhaps I'm looking at your problem the wrong way, but have you looked at the SDMX Concepts: http://purl.org/linked-data/sdmx/2009/code#sex -Sarven I was going to suggest that :) Actually looking at that I see that I've failed to datatype the skos:notation entries in those code lists. There should probably be a http://purl.org/linked-data/sdmx/2009/code#sexDT datatype to go with the notation on those skos:Concepts. Phil, if that's important to you then raise it as an issue on the tracker [1] and, if no one objects, then I can get it fixed. Dave [1] http://code.google.com/p/publishing-statistical-data/issues/list
Re: Datatypes with no (cool) URI
For a comprehensive overview of gender vs sex and other challenges in representing the reality underlying demographic data see this paper http://ceur-ws.org/Vol-833/paper20.pdf Describing the The Ontology of Medically Related Social Entitie (OMRSE) http://code.google.com/p/omrse/ . The URI for the Female Gender = http://purl.obolibrary.org/obo/OMRSE_0009 (subclass of Gender Role and Human Social Role) Regards @kerfors 2012/4/3 Andy Turner a.g.d.tur...@leeds.ac.uk I am a researcher working on some Demographic Social Simulation Models. In the simple models, I distinguish people classed male at birth and people classed female at birth and gender ambiguity, reassignment (sex change) and gender recalssification are not modelled. In more complicated models these things might be modelled and if I were modelling that, I would consider storing a list of changes and have more classes or somehow quantify maleness and femaleness. The point I am making here is that the assignment of gender (or sex depending on what word you prefer) could be time dependent. In an attempt to make my data storage and retrieval work better I implemented two main data stores for people: those classed female at birth; those classed male at birth. In my models, even if current gender were re-assigned data for that individual would still be stored in the same data store. I suspect that in ambiguous cases in reality what is done in terms of gender classification might be different for different countries. BTW: gender ambiguity was topical in the mainstream media in the Autumn in the UK [1]. It is not as uncommon as you might think... So, gender is a fuzzy thing. Maybe we all belong to male and female classes to a degree and for most of us this distinction is binary. In terms of encoding, in my implementations I've used 0 for female and 1 for male as I find that easy to remember and computationally it makes sense. Andy [1] http://www.bbc.co.uk/news/health-14459843 From: Phil Archer [ph...@w3.org] Sent: 03 April 2012 14:33 To: public-lod@w3.org Subject: Datatypes with no (cool) URI I'm hoping for a bit of advice and rather than talk in the usual generic terms I'll use the actual example I'm working on. I want to define the best way to record a person's sex (this is related to the W3C GLD WG's forthcoming spec on describing a Person [1]). To encourage interoperability, we want people to use a controlled vocabulary and there are several that cover this topic. ISO 5218 has: 0 = not known; 1 = male; 2 = female; 9 = not applicable. and Eurostat offers F = female M = male OTH = other UNK = unknown NAP = not applicable IMO, the spec should not dictate which one to use (there are others too of course). What I *do* want to do though is to encourage publishers to state which vocabulary they're using. Sounds like a job for a datatype - and for that you need a URI for the vocabulary. Something like: schema:gender 1^^http://iso.org/5218/ . Except I made that iso.org URI up. The actual URI for it is http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36266 (or rather, that's the page about the spec but that's a side issue for now). That URI is just horrible and certainly not a 'cool URI'. The Eurostat one is no better. Does the datatype URI have to resolve to anything (in theory no, but in practice? Would a URN be appropriate? Given that the identifier for the ISO standard is ISO/IEC 5218:2004 how about urn:iso/iec:5218:2005? For Eurostat, the internal identifier for the vocabulary is SCL - Sex (standard code list) so would urn:eurostat:scl:sex be appropriate? Anyone done anything like this in the real world? All advice gratefully received. Thank you Phil. [1] https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org @philarcher1
[CFP] 1st International Workshop on Artificial Intelligence meets the Web of Data (AImWD-2012)
Apologies for cross-posting Please, acknowledge this message to your colleagues -- CALL FOR PAPERS 1st International Workshop on Artificial Intelligence meets the Web of Data (AImWD-2012) co-located with European Conference on Artificial Intelligence (ECAI-2012) ( http://sites.google.com/site/aimwd12/ ) -- WORKSHOP DESCRIPTION -- The Linked Data initiative aims at improving data publication on the Web, thereby creating a Web of Data: an interconnected, distributed, global data space. The Web of Data enables people to share structured data on the Web as easily as they can currently share documents on the Web of Documents (WWW). The basic assumption behind the Web of Data is that the value and usefulness of data increases with the amount of interlinking with other data. The emerging Web of Data includes datasets as extensive and diverse as DBpedia, Flickr, and DBLP. A tip of the iceberg representation of its content is behind maintained at http://lodcloud.net The availability of this global data space creates new opportunities for the exploitation of Artificial Intelligence techniques in relation with knowledge representation, information extraction, information integration, and intelligent agents. Two approaches can emerge: (i) using AI techniques to address the problems the Web of Data faces or, (ii) using the design principles of the Web of Data to improve knowledge representation within AI techniques. The workshop aims at bringing together researchers and practitioners working on the Web of Data and/or Artificial Intelligence to discuss the union of these two research areas. Several core challenges, such as the interconnection of heterogeneous datasets, the provenance of the information and trust issues will be at the centre of the discussion. With this workshop, our goal is to contribute to the birth of a community having a shared interest around publishing data on the Web and exploring it using AI technologies â or the inverse, developing and improving AI technologies which use tools from the Web of Data. -- WORKSHOP CHAIRS -- + Christophe Gueret (Vrije Universiteit Amsterdam) E-mail: c.d.m.gue...@vu.nl + Dino Ienco (IRSTEA) E-mail: dino.ie...@teledetection.fr + Francois Scharffe (LIRMM) E-mail: francois.schar...@lirmm.fr + Serena Villata (INRIA Sophia Antipolis) E-mail: serena.vill...@inria.fr -- TOPICS -- We solicit original and high quality submissions addressing all aspects of this field. The topics of interest include, but are not limited to the following: * Use of machine learning algorithms for linking in the Web of Data * Inference techniques for answering questions using the Web of Data * Exploiting rich knowledge bases in the Web of Data * Intelligent agents exploiting the Web of Data * Use data mining techniques to schemas alignment in the Web of Data * Privacy and access control in the Web of Data * Licensing and provenance issues in the Web of Data * User interaction and usability issues in the Web of Data * Crawling, caching and querying the Web of Data * Web of Data search engines * Web of Data and Artificial General Intelligence * Case-Based Reasoning in the Web of Data * Natural language processing applied to the Web of Data -- INVITED SPEAKER -- We are thrilled to have Jerome Euzenat (Research Director at INRIA Lab. of Grenoble) and Philippe Cudr-Mauroux (Massachusetts Institute of Technology) as our confirmed invited speakers. -- IMPORTANT DATES -- - May 28, 2012 - Full paper submission deadline - June 28, 2012 - Notification of acceptance - July 10, 2012 - Camera-ready paper due - August 27-31, 2012 - ECAI Conference -- PAPER SUBMISSION -- The guidelines for paper submission are the following: - The paper should be written in English. - The maximum length of a paper is 12 A4-sized pages in LNCS format (format download: http://www.springer.de/comp/lncs/authors.html ). - The paper should be in PDF format. - Please submit via the online paper submission system ( https://www.easychair.org/conferences/?conf=aimwd2012 ) - A selection of papers will be published in a
Re: From Open Database Connectivity to Open Data Connectivity
On 3/30/12 5:47 PM, Barry Norton wrote: On 30/03/2012 22:37, Kingsley Idehen wrote: On 3/30/12 5:08 PM, Barry Norton wrote: I'd like to see something like saves you from having to re-invent keys. Linked Data does just that. Precisely. But I wouldn't (with my old ODBC developer hat on) have got it from your text. (I understand that it's a different thing you were aiming at with the mention of URIBurner, and...) What I didn't go into (deliberately) in the post is the ability to build Linked Data views over relational data sources using R2RML [3]. Also true. In this context that could be a lot more comprehensible and relevant (not putting down URIBurner and similar services). Barry I've just published a little howto that showcases how to query the Linked Open Data cloud via any ODBC compliant application across Windows (any version), Mac OS X (any version even Mac Classic), Linux, Solaris, FreeBSD etc.. Much more to come ... Links: 1. http://goo.gl/olvLf -- how to query the LOD cloud via any ODBC compliant application using Virtuoso's wire-protocol style of ODBC Driver. -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposal to amend the httpRange-14 resolution
Hi Kingsley, On Tue, 2012-04-03 at 15:01 -0400, Kingsley Idehen wrote: On 4/3/12 1:46 PM, David Booth wrote: [ . . . ] This use of URI definitions helps to anchor the meaning of the URI, so that it does not drift uncontrollably. [ . . . ] But once on the Web the user really [loses] control. There is not such thing as real stability per se. Only when you have system faults can one at least pivot accordingly. Thus, you only get the aforementioned behavior in the context of a specific system and its associated rules. I think you're right that we can never get total semantic stability in an absolute sense. But if we establish a commonly followed convention in which the URI owner's URI definition is used when making statements involving a URI, then the semantic drift will at least be substantially limited. Again, this does not require *everyone* to follow the convention. But the more that do follow it, the more effective it becomes in making the web a sort of self-describing dictionary. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
