Re: 200 OK with Content-Location might work
On Fri, Nov 5, 2010 at 4:55 PM, Nathan nat...@webr3.org wrote: Mike Kelly wrote: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 snipped and fuller version inserted: 4. If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). If a client wants to make a statement about the specific document then a response that includes a content-location is giving you the information necessary to do that correctly. It's complemented and further clarified in the entity body itself through something like isDescribedBy. I stand corrected, think there's something in this, and it could maybe possibly provide the semantic indirection needed when Content-Location is there, and different to the effective request uri, and complimented by some statements (perhaps RDF in the body, or Link header, or html link element) to assert the same. Covers a few use-cases, might have legs (once HTTP-bis is a standard?). Nicely caught Mike! +1 This is precisely what we need. Ian
Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Fri, Nov 5, 2010 at 5:28 PM, Nathan nat...@webr3.org wrote: URI resolution is essentially: dereference( uri.toAbsolute() ); Which gives us the simplicity and semantic indirection which we need. Use frags, forget HTTP, know that uri#frag is never going to be a document (unless you explicitly say it is). On a practical level using frags can be inefficient when your linked data output is backed by a triple store. If you use a slash URI then generating the data for html/xml/turtle output is just a simple describe uri. For hash URIs you need to describe all the resources with a common prefix because the fragment is not sent by the browser with the request. That might mean a filter with a regex or string functions which will be more inefficient. If you pick a standard fragment such as #this, #it etc then you can revert to the simple describe so the inefficiency only arises when there are multiple arbitrary fragments per document URI. The other downside of fragments is you can't say it exists but I have no description of it. With standard slash URIs you can 303 to a 404 to say that. You can 404 on the slash itself to say the resource does not exist. With my proposal to use 2xx responses you can return 204 No Content to indicate the resource exists but no description is available. With slashes you can use 410 on an individual resource to indicate that it has gone forever. You can also do this with the one frag per doc approach although you are really saying the description document has gone and the user is left to imply the secondary resource has also gone. With multiple frags per doc (i.e. a lot of schemas) you can't say just one of those resources has gone forever. In summary: Slash with 303: hard static publishing, efficient dynamic, can ack existence without description Hash, one resource per doc: easy static publishing, efficient dynamic, can't ack existence without description Hash, many resources per doc (the typical schema case): easy static publishing, less efficient dynamic, can't ack existence without description Slash with 2xx: easy static publishing, efficient dynamic, can ack existence without description Ian
Re: 200 OK with Content-Location might work
Ian Davis wrote: On Fri, Nov 5, 2010 at 4:55 PM, Nathan nat...@webr3.org wrote: Mike Kelly wrote: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 snipped and fuller version inserted: 4. If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). If a client wants to make a statement about the specific document then a response that includes a content-location is giving you the information necessary to do that correctly. It's complemented and further clarified in the entity body itself through something like isDescribedBy. I stand corrected, think there's something in this, and it could maybe possibly provide the semantic indirection needed when Content-Location is there, and different to the effective request uri, and complimented by some statements (perhaps RDF in the body, or Link header, or html link element) to assert the same. Covers a few use-cases, might have legs (once HTTP-bis is a standard?). Nicely caught Mike! +1 This is precisely what we need. The jury's still you on this one though, see: http://markmail.org/message/u4yctkaj2i3pms2o
Extended deadline IUI2011 Workshop: Visual Interfaces to the Social and Semantic Web (VISSW 2011)
apologies for cross-posting CALL FOR PAPERS 3rd International Workshop on Visual Interfaces to the Social and Semantic Web (VISSW 2011) In conjunction with the ACM Conference on Intelligent User Interfaces (IUI 2011) Stanford University, Palo Alto, US 13th February 2011 http://www.smart-ui.org/events/vissw2011/ *** Extended Deadline: 15th November 2010 *** INTRODUCTION The continued growth and importance of the Social Web has resulted in ever increasing volumes of data created, published and consumed by users. This vast amount of data takes many forms, including text, images, video and more recently streams of status information from applications such as Facebook and Twitter. Not only is this data accessible through more traditional means, such as desktop and laptop computers, but also via diverse platforms such as mobile devices and set-top boxes that bring unique constraints in terms of computing resources, interaction modes and user interfaces. Through the increasing availability of Web APIs, data that has traditionally been coupled with a specific application may now be exposed through novel interfaces developed by third parties, providing functionality not previously anticipated by data owners. In tandem with the growth of the Social Web, the Web at large has experienced a significant evolution into a Web not just of linked documents, but also of Linked Data. This development, which exploits the Semantic Web technology stack, allows relationships to be expressed between items in distributed data sets, paving the way for integration of raw data from multiple, heterogeneous sources. Coupled with the increasing availability of APIs that expose data from the Social Web, application developers have a wealth of data available to them upon which they can build compelling visual interfaces. Furthermore, in context of recent developments, such as Facebook introducing Open Graph Protocol, Twitter enabling tweets with annotations and Google moving into the Semantic Web with their acquisition of Metaweb, interactions on the Social and Semantic Web are gaining a larger audience. In this context, the ability to easily integrate vast amounts of data from across the Social and Semantic Web raises significant and exciting research challenges, not least of which how to provide effective access to and navigation across vast, heterogeneous and interconnected data sources. However, the need for intelligent and visual human interfaces to this evolving Web is not limited simply to the modalities of searching and browsing, important as these are. As the Web becomes increasingly populated with data, continues to evolve from a read-mainly to a read-write medium, and the level of social interaction supported on the Web increases, there is also a pressing need to support end-users who engage in a wide range of online tasks, such as publishing and sharing their own data on the Web. Exploring different aspects of those developments and their implications for visual interface research and development is one of the goals of the workshop. This workshop aims to bring together researchers and practitioners from diverse, complementary fields to discuss the latest research results and challenges in designing, implementing, and evaluating intelligent interfaces in the context of the Social and Semantic Web. The workshop will serve as an opportunity for researchers to gain feedback on their work, and to identify potential collaborations with their peers. We believe that the potential for fostering links between a variety of facets of the IUI community will help to ensure an exciting workshop program. Information about the previous workshops can be found at: http://www.smart-ui.org/events/vissw2010/ and http://www.smart-ui.org/events/vissw2009/ TOPICS OF INTEREST Topics of interest include, but are not limited to: * Interfaces o Novel interfaces for high-volume transient data, e.g. feeds, streams and sensors. o Novel interfaces supporting discovery of social data and richer interactions using Facebook's Open Graph Protocol, Twitter's Annotations for tweets, Google's Social Graph etc. o 'Living' interfaces to constantly evolving data, vocabularies, and emerging links between them. o Collaborative interfaces supporting social data analysis. o Adaptive user interfaces on the Web. o Lightweight components and processes for casual users to publish/share their own content on the Web. o Task-centric interfaces for structured and/or Linked Data. o Novel visualisation of structured, linked and aggregated data, originating from multiple sources. o Interface components for displaying/interacting with aggregated, heterogeneous Linked Data, e.g. components for displaying provenance information. o Ontology-based visualization of collections of data. * Interaction Paradigms o Novel
Re: 200 OK with Content-Location might work
On 11/6/10 8:11 AM, Ian Davis wrote: On Fri, Nov 5, 2010 at 4:55 PM, Nathannat...@webr3.org wrote: Mike Kelly wrote: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 snipped and fuller version inserted: 4. If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). If a client wants to make a statement about the specific document then a response that includes a content-location is giving you the information necessary to do that correctly. It's complemented and further clarified in the entity body itself through something like isDescribedBy. I stand corrected, think there's something in this, and it could maybe possibly provide the semantic indirection needed when Content-Location is there, and different to the effective request uri, and complimented by some statements (perhaps RDF in the body, or Link header, or html link element) to assert the same. Covers a few use-cases, might have legs (once HTTP-bis is a standard?). Nicely caught Mike! +1 This is precisely what we need. Ian All, So we have arrived at a destination that's mutually inclusive re. 303 indirection. Basically, an additional technique that uses Content-Location as the switch. Nice, simple, clean, and shouldn't break a thing, as long as people stop producing old school RDF resources. In addition, I think we've also triggered a POWDER fix that's been long overlooked. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
On 11/6/10 9:05 AM, Nathan wrote: Ian Davis wrote: On Fri, Nov 5, 2010 at 4:55 PM, Nathan nat...@webr3.org wrote: Mike Kelly wrote: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 snipped and fuller version inserted: 4. If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). If a client wants to make a statement about the specific document then a response that includes a content-location is giving you the information necessary to do that correctly. It's complemented and further clarified in the entity body itself through something like isDescribedBy. I stand corrected, think there's something in this, and it could maybe possibly provide the semantic indirection needed when Content-Location is there, and different to the effective request uri, and complimented by some statements (perhaps RDF in the body, or Link header, or html link element) to assert the same. Covers a few use-cases, might have legs (once HTTP-bis is a standard?). Nicely caught Mike! +1 This is precisely what we need. The jury's still you on this one though, see: http://markmail.org/message/u4yctkaj2i3pms2o Nathan, Aren't juries about peers? In this case, aren't the peers those that publish and consume Linked Data? I think practitioners make this call :-) Leigh: yes, indeed, Linked Data Practitioners :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
On 11/6/10 12:41 PM, Bill Roberts wrote: On 6 Nov 2010, at 17:25, Kingsley Idehen wrote: All, So we have arrived at a destination that's mutually inclusive re. 303 indirection. Basically, an additional technique that uses Content-Location as the switch. Nice, simple, clean, and shouldn't break a thing, as long as people stop producing old school RDF resources. In addition, I think we've also triggered a POWDER fix that's been long overlooked. +1. (just to clarify: what do you mean exactly by old school RDF resources?) Defining attributes: 1. missing isDefinedby, isDescribedBy, describedBy assertions 2. do not use resolvable URIs (in Subject or Predicate slots) :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Is 303 really necessary?
David, hello. On 2010 Nov 6, at 20:42, David Booth wrote: httpRange-14 requires that a URI with a 200 response MUST be an IR; ^^^ Not quite. The httpRange-14 decision says that the resource *is* an IR: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 Yes, when I phrased this, I did indeed mean it as an analytic-must rather than an rfc2119-synthetic-must (this is the distinction you're making, yes?) a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. To be clear, Ian's toucan URI *does* identify an information resource, whether or not it *also* identifies a toucan: Indeed, because the decision defines what an IR is, so that Ian's toucan is necessarily an IR in the sense in which that term is currently defined. Thus, Ian has created an ambiguity by returning a 200 response. (Ian can of course speak for himself, but...) I take it that Ian is suggesting resolving the ambiguity he has created, and thus the need for any heuristics, by extending the notion of IR in such a way that a URI with a 200 response *is* an IR, *unless* dereferencing it returns RDF which (authoritatively) declares that the URI is a NIR. However, for those applications that need to distinguish between the toucan and its web page, Ian is effectively suggesting the *heuristic* that if the content served in the 200 response says that the URI identifies a toucan, then the app should ignore the fact that the URI also identifies a web page, and treat the URI as though it *only* identifies the toucan. The suggestion does mean that the toucan URI, since it now identifies a toucan, cannot also identify the toucan's webpage, which is therefore unnamed. I don't know if that's a problem or not (maybe it is, if you want to be able to say I got this information about the toucan called /toucan from X). If it's a problem, then perhaps the /toucan URI could point towards a /toucan.rdf URI which contains the same RDF as /toucan, but which is still an IR. Then /toucan.rdf is the toucan's webpage. Best wishes, Norman -- Norman Gray : http://nxg.me.uk
Re: Is 303 really necessary?
On 11/6/10 4:42 PM, David Booth wrote: httpRange-14 requires that a URI with a 200 response MUST be an IR; ^^^ Not quite. The httpRange-14 decision says that the resource *is* an IR: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 a URI with a 303 MAY be a NIR. Ian is (effectively) suggesting that a URI with a 200 response MAY be an IR, in the sense that it is defeasibly taken to be an IR, unless this is contradicted by a self-referring statement within the RDF obtained from the URI. To be clear, Ian's toucan URI *does* identify an information resource, whether or not it *also* identifies a toucan: $ curl -I 'http://iandavis.com/2010/303/toucan' HTTP/1.1 200 OK Date: Sat, 06 Nov 2010 20:05:57 GMT Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_wsgi/1.3 Python/2.5.2 Content-Location: toucan.rdf Vary: negotiate TCN: choice Last-Modified: Fri, 05 Nov 2010 09:24:27 GMT ETag: 264186-403-4944ad745a8c0;4944ad754eb00 Accept-Ranges: bytes Content-Length: 1027 Content-Type: application/rdf+xml; qs=0.9 Thus, Ian has created an ambiguity by returning a 200 response. There is nothing fundamentally wrong with this, as ambiguity of resource identity is inescapable anyway, and we just have to learn to deal with it. However, for those applications that need to distinguish between the toucan and its web page, Ian is effectively suggesting the *heuristic* that if the content served in the 200 response says that the URI identifies a toucan, then the app should ignore the fact that the URI also identifies a web page, and treat the URI as though it *only* identifies the toucan. David, What about this: 1. a 200 OK response infers that a URI is a URL (an Address) since its an indication of that a Resource has been located 2. existence of a self-describing resource discovered via Content-Location header value (e.g. touscan.rdf) can result in an override if the data states that the URI is a Name. I really think we have to emphasize the Address and Name aspects of a generic URI, at every opportunity. Personally, I think it helps understand what the actual ambiguity is about. This option showcases good RDF dog-fooding, especially as the Semantic Web Project has always been about self-describing data :-) -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
POWDER Fix on wdrs:describedby (was Re: 200 OK with Content-Location might work)
On 06/11/2010 16:25, Kingsley Idehen wrote: [snip] In addition, I think we've also triggered a POWDER fix that's been long overlooked. And I'm grateful that it's come to my attention (wish I'd recognised the problem a lot earlier :-() I've made a proposal internally (at W3C) that I want to run past at least one or two of the former POWDER WG members to make sure they're happy (one in particular). If that goes as hoped then there could be an erratum published as soon as Monday (8th) that would be become part of an edited Recommendation before long (maybe in the new year). Bottom line is that wdrs:describedby was intended to be semantically identical to @rel describedby, i.e. with no range restriction. Since the Recommendation and namespace doc in the their present form are ambiguous it's clearly an error so making an entry on the errata page [1] is pretty straightforward. Once that's done there'll be a bit of outreach work to do on that. Getting the actual Rec edited takes a bit more 'process' but it's doable. (Fundamental rule about docs published in TR space at w3.org is that the bytes don't change. Editing means publishing a new version.) I think the chances of there being an implementation that infers that the object of a wdrs:describedby predicate is a wdrs:Document is vanishingly small but, on the off chance anyone knows of such an implementation, please let me know. (Incidentally, editing the Rec should also help us get the POWDER MIME type registered but that's orthogonal to the current discourse). Phil [1] http://www.w3.org/2007/powder/powder-errata -- Phil Archer W3C Mobile Web Initiative http://www.w3.org/Mobile http://philarcher.org @philarcher1
Re: wdrs:describedby
On 11/5/10 1:41 PM, Phil Archer wrote: The 303 debate has prompted me to re-look at the definition of wdrs:describedby - and it's obvious that the POWDER WG (which I chaired), made an error. I've begun the process of seeking to change the spec so that the range restriction on this property will be removed [1]. Therefore, wdrs:describedby, like the @rel link, will be able to point to any kind of descriptive resource and will not imply that the description is provided in POWDER. I hope, therefore, that there will be no need to define a new property of isDefinedBy. Cheers Phil. [1] http://lists.w3.org/Archives/Public/public-powderwg/2010Nov/0002.html Hopefully not :-) All the gaps are being plugged, our general narrative is getting clear by the second, re. Linked Data, Methinks! Dogfooding is a great thing re. tech QA. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Sat, 6 Nov 2010 12:33:34 +
Ian Davis li...@iandavis.com wrote:
On a practical level using frags can be inefficient when your linked
data output is backed by a triple store. If you use a slash URI then
generating the data for html/xml/turtle output is just a simple
describe uri. For hash URIs you need to describe all the resources
with a common prefix because the fragment is not sent by the browser
with the request. That might mean a filter with a regex or string
functions which will be more inefficient.
Not necessarily. If you take your ex:isDescribedBy predicate and add
that to a triple store where the non-Information-Resource resources are
identified using hash URIs, then the SPARQL query is just:
DESCRIBE uri ?res
WHERE { ?res ex:isDescribedBy uri . }
which needn't be very slow.
The other downside of fragments is you can't say it exists but I have
no description of it.
#foo a rdfs:Resource .
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
Fw: [foaf-dev] EON - event of note
Begin forwarded message... Date: Thu, 4 Nov 2010 00:32:50 + From: Toby Inkster t...@g5n.co.uk To: foaf-dev foaf-...@lists.foaf-project.org Subject: [foaf-dev] EON - event of note Let's do a bit of collaborative work to flesh out a FOAF-like lightweight vocabulary for describing events, suitable for embedding in RDFa to describe concerts, conferences, birthdays, anniversaries, national holidays and so on. Sure, we have the iCalendar RDF vocab, but I've come to the conclusion that that's more suited to representing calendar entries - not the events themselves. I'm thinking of a simple set of extensions for Yves Raimond's Event Ontology. Let's kickstart this with the class eon:Event which would be a trivial subclass of http://purl.org/NET/c4dm/event.owl#Event. Here's a sketch of how an event might look in Turtle: #this a eon:Event ; foaf:name Lewes Bonfire ; foaf:page http://www.lewesbonfirecouncil.org.uk/ ; eon:date 2010-11-05^^xsd:date ; eon:location [ foaf:name Lewes ; foaf:page wikipedia:Lewes ] . Properties that I think should be included: * eon:start and eon:end - which can be xsd:dateTime or xsd:date (if the latter, then the event starts/ends at an unspecified time on that day) * eon:date - a subproperty of both eon:start and eon:end with range xsd:date. * eon:location - range geo:SpatialThing Probably need an attendee property and an organizer/participant property. Maybe eon:cost, eon:details, eon:bookings. I've placed a sketch on my data wiki http://wiki.ontologi.es/. Feel free to edit; and add yourself as a foaf:maker if you do! -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
