Re: Combining Linked Data HTTP URIs and HTML5 WebSocket URIs

On 11/19/11 7:55 PM, richard.hancock@3kbo.com wrote:
> Thanks Kingsley,
>
> appreciate what you are saying but for me the fact that WebSocket
> implementations are now appearing is an indication that for today's web
> HTTP alone is not enough.

I am not saying HTTP is the sole option. I am saying via HTTP you have 
low-cost access to some key features.

>   For some information you can only guess at how
> long it is going to be valid so while cache invalidation works having the
> server push out a change when it happens is more immediate.
>
> I totally agree with not being programming language specific and part of
> what I am trying to work through is to find a way to generically describe
> dynamic information that could be accessed via WebSockets such that it
> could be combined with other Linked Data.

You can use any kind of de-referencable URI re. Linked Data. They most 
important this is understanding that Names are distinct from Addresses. 
Thus, the underlying mechanics of using Names for indirect access to 
Data at an Address will vary depending on your choice of URI scheme.

You can use whatever scheme you like as long as the fundamental 
principles of Linked Data are intact :-)


Kingsley
>
> Cheers,
>
> Richard
>
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>
>
>


-- 

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