Re: Combining Linked Data HTTP URIs and HTML5 WebSocket URIs

On 11/19/11 5:05 PM, richard.hancock@3kbo.com wrote:
> 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?
Linked Data is implicitly dynamic, courtesy of indirection. The key here 
is indirection delivered by Names that resolve (by act of de-reference) 
to actual resource (data object) locations from which data is retrieved. 
In addition, Linked Data exploits fundamental Object Theory [1] without 
programming language specificity. Thus, using URIs in a manner where 
de-referencable Names and Addresses are disjoint leads to an ability to 
expose and exploit the fidelity of equivalence via relation semantics 
i.e., ability to express equality between two objects in a relation by 
Name (owl:sameAs for instance) or Values (when a relation 
predicate/property is designated as being owl:inverseFunctional).

Contrary to popular Linked Data misconception, you can't actually 
explain what Linked Data actually is without some basic understanding of 
relation semantics as expressed in eav/spo triple patterns.

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

You don't. The property is part of a relation.
>
> 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.

A Linked Data browser would have some degree of cache invalidation built 
in. For instance, when its de-referenced it would use a local cached 
version of the property's description (a graph) or de-reference the 
latest description from source.

>
> To my mind HTML5 WebSockets have the potential to provide that dynamic
> functionality (though currently only via logic specific to a custom
> browser).

Basic HTTP makes this possible when its the URI scheme of choice for 
Names re. Linked Data.
>
> 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?

In Linked Data realm, if using HTTP scheme for URI based Names, they are 
dynamic courtesy of in-built cache awareness of HTTP.

To conclude, if you use HTTP scheme URIs for Names re. Linked Data, you 
get all of the benefits of HTTP gratis, on the publisher side. On the 
client side of things, browsers simple need to behave like browsers 
i.e., leverage HTTP response metadata for cache invalidation.


BTW Our browsers [1] [2] all exploit HTTP re. cache invalidation 
schemes. Ditto our Linked Data transformation middleware [3] also known 
as the Virtuoso Sponger - which is built into Virtuoso's SPARQL 
implementation.

Links:

1. http://ode.openlinksw.com - browser extensions for Chrome, Safari, 
Firefox, Opera, and IE.
2. 
http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtFacetBrowserInstallConfig 
-- DBMS hosted faceted browser.
3. http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtSponger -- 
Virtuoso Sponger (transforms data from a variety of sources into Linked 
Data) .

Kingsley
>
> 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
>>>
>>>
>>>
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  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