RealTimeCapacity and compatibility with RSP

[pietercolpaert]

The RDF stream processing community relies on data streams as being triples contained within a graph, and the graph being annotated with a prov:generatedAtTime. I like this general approach.

In mobivoc, the “real-time capacity” needs to be an entity on its own, and needs to be annotated with a mobivoc specific way using http://schema.mobivoc.org/currentValue.

Can we allow to not reify the object of mv:capacity and annotate this instead via a named graph? E.g., as follows:

{ 
  "@context": {
     "mv": "http://schema.mobivoc.org/",
     "bikes_available": "mv:capacity",
     "name": "http://schema.org/name",
     "capacity": "mv:totalCapacity",
     "nearby" : {
        "@id": "http://www.geonames.org/ontology#nearby",
        "@type": "@id"
      },
      "generatedAtTime" : {
        "@id": "http://www.w3.org/ns/prov#generatedAtTime",
        "@type": "xsd:date"
      }
   },
   "generatedAtTime": "2018-12-19T11:13:29.435Z",
   "@graph": {
        "@id": "#1",
        "@type": "http://schema.org/ParkingFacility",
        "name": "Boechout P+R Capenberg",
        "bikes_available": 5,
        "capacity": 6,
        "nearby": "http://irail.be/stations/NMBS/008821634"
      }
}

[np00]

Thanks for the pointer and the example. MobiVoc indeed needs certainly a more solid foundation to represent real-time data. The existing solution might work for experiments in research projects, but I have doubts myself that it will hold for fast-changing real-time data in a production system.

While your proposal looks interesting, it forces the user to manage two graphs if I understood it correctly. I am not sure if that added complexity pays off at the end. But I am not an expert in this myself.

There seems to be quite some documentation on how to model data which changes over time. I will review it when the need arises. A good start: http://blog.iandavis.com/2009/08/representing-time-in-rdf-part-1/ I might also remove it entirely in the review which is going to happen now.

[pietercolpaert]

While your proposal looks interesting, it forces the user to manage two graphs if I understood it correctly. I am not sure if that added complexity pays off at the end. But I am not an expert in this myself.

Indeed, after giving it some thought, it might be better to describe the time of the observation in the ontology itself instead of using a reification-like approach through named graphs. It might be interesting to see an ontology mapping to SSN/SOSA in the future of this though, but closing this idea for now!