- From: <richard.hancock@3kbo.com>
- Date: Sat, 19 Nov 2011 16:05:14 -0600
- To: "Patrick Logan" <patrickdlogan@gmail.com>
- Cc: richard.hancock@3kbo.com, public-lod@w3.org
Thanks David, Kingsley and Patrick for the answers so far. maybe I should restate my question as follows: With the current specs and definitions of Linked Data currently available, what is the best way to indicate that parts of the information being returned are dynamic? For the server examples below I could create an owl model with server status as a property, but how do I indicate that the value of status is a dynamic property which may change in the near future? What I would like is a Linked Data browser similar to Tabulator that can generically read my Linked Data and having discovered that a particular property is dynamic provide live updates of that property. To my mind HTML5 WebSockets have the potential to provide that dynamic functionality (though currently only via logic specific to a custom browser). So, (leaving aside HTML5 websockets for the moment) my initial question comes down to what is the best way to indicate that the values of some properties are dynamic? Cheers, Richard > The problem I am having coming to terms with your question is that the > web socket protocol is "full custom" once the two endpoints have > established that they are indeed using web sockets. > > The http protocol defines all kinds of details that continue from > connection through disconnection (e.g. what kind of data is being > exchanged). > > This seems kind of like designing for a gate array (http) vs. a full > custom IC. That's probably what you expect, and that's fine - it's > just you've created an ASIC -- an Application-Specific Integrated > Circuit. > > And so along the lines of what Kingsley wrote in his response, it > seems to me you could: > > * Design a vocabulary for describing servers and performance metrics > using any URL scheme. > > * Design (at least) two access mechanisms, one based on http and the > other based on web sockets. Clients of the latter would just have to > understand your application-specific protocol designed to transmit web > socket data frames to be formatted and parsed as you see fit. > > Either access mechanism could be used to communicate (subsets of) the > same graph. > > Potentially confused, I am... > -Patrick > > On Fri, Nov 18, 2011 at 6:22 PM, <richard.hancock@3kbo.com> wrote: >> Hi All, >> >> I have a couple of questions re combining Linked Data HTTP URIs and >> HTML5 >> WebSocket URIs. >> >> There are a couple of applications that I would like to build which have >> a >> mix of static and dynamic data. For the dynamic data I am planning to >> use >> HTML5 WebSockets [1][2] which uses the ws:// and wss:// prefixes. >> >> As an example I want to report the runtime status of the servers in a >> Weblogic cluster. Using JMX monitoring to get the actual status I could >> use >> >> >> ws://www.3kbo.com:9090/servers/1/status >> ws://www.3kbo.com:9090/servers/2/status >> >> to display the current status of each server in my monitoring app. >> >> I am also planning to display LinkedData[3] about each server using the >> URIs >> >> <http://www.3kbo.com:8080/servers/1> and >> <http://www.3kbo.com:8080/servers/2>. >> >> It would seem logical to use owl:sameAs to combine the HTTP URIs and the >> Websocket URIs to assert that they are referring to the same >> individuals, >> but is that valid? >> >> I.e. can the following two statements be made in OWL? >> >> <http://www.3kbo.com:8080/servers/1> owl:sameAs >> <ws://www.3kbo.com:9090/servers/1> . >> >> <http://www.3kbo.com:8080/servers/2> owl:sameAs >> <ws://www.3kbo.com:9090/servers/2> . >> >> Does the forth LinkedData[3] principal >> >> "4. Include links to other URIs. so that they can discover more things." >> >> implicitly include links to Websocket URIs ? >> >> Cheers, >> >> Richard Hancock >> >> >> 1. http://en.wikipedia.org/wiki/WebSockets >> 2. http://dev.w3.org/html5/websockets/ >> 3. http://www.w3.org/wiki/LinkedData >> >> >> >
Received on Saturday, 19 November 2011 22:05:43 UTC