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 :-)
>

Thanks Kingsley, I'll try out a few different options re incorporating
WebSocket URIs, let you know if I come up with anything interesting,

Richard

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

Received on Sunday, 20 November 2011 03:23:28 UTC