suggestion: define a recommended RDF vocabulary

[msladecek]

Hi, I'd like to suggest that the cloudevents spec should include an RDF vocabulary for the cloudevent attributes.
It seems to me that the goals of the cloudevents specification and of RDF are aligned - standardization and maintenance of semantic relationships of data that's being communicated across multiple services.

I believe it would be a good fit for the /formats section of the specification.

The json-ld format would be a good fit for representing cloudevents, as it bridges the zone between plain json and linked data ecosystems.
A document describing how to represent cloudevents in the json-ld format could be included in the specification.

If there is interest in this, I'd be happy to contribute a draft and to participate in further discussions.

References

• json-ld https://json-ld.org/
• json-ld w3c recommendation https://www.w3.org/TR/json-ld/
• RDF primer https://www.w3.org/TR/rdf12-primer/
• RDF concepts https://www.w3.org/TR/rdf12-concepts/
• OWL (web ontology language) primer https://www.w3.org/TR/2012/REC-owl2-primer-20121211/

[duglin]

Not looking for you to do a lot of work in case we don't want to head this direction, however, since a CE is such a small snippet of json, perhaps you could quickly write down what you think the minimal json-ld/RDF CE would look like. I think that would help people get a good sense of what you're thinking of.

[duglin]

@msladecek - we have a weekly call tomorrow (thursday - 12pm ET) and I would love to add this topic to the agenda. Any chance of you doing ^^^ by then?

[msladecek]

I'm sorry, work is killing me this week. I'll probably be able to prepare something for next week, but definitely not tomorrow

[duglin]

No worries. Get to it when you can...

[deissnerk]

Thanks @msladecek for bringing this up. I am also interested in an example and a joint discussion. You might also be interested in our other project, xRegistry. I could imagine that the data in an xRegistry could also be represented as RDF, and this could lead to some interesting thought experiments.

[msladecek]

I'm thinking there are a couple of way to establish a recommended vocabulary.

First would be to create a context from some established vocabularies and map their best-fitting properties to the cloudevent fields:

{
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "dc": "http://purl.org/dc/terms/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "reg": "https://www.w3.org/ns/assignments/reg#",
    "cnt": "https://www.w3.org/2011/content#",

    "specversion": {"@id": "dc:conformsTo", "@type": "@id", "@context": {"@base": "https://github.com/cloudevents/spec/tree/"}},
    "type": {"@id": "dc:type"},
    "source": {"@id": "dc:creator"},
    "subject": {"@id": "dc:subject"},
    "id": {"@id": "dc:identifier"},
    "time": {"@id": "dc:issued", "@type": "xsd:dateTime"},
    "datacontenttype": {"@id": "cnt:doctypeName", "@type": "@id", "@context": {"@base": "https://www.w3.org/ns/iana/media-types/"}},
    "data": {"@id": "rdf:value"}
}

Just a draft, not exactly sure about some of it, and some of it is not actually correct, eg. specversion value expands to https://github.com/cloudevents/spec/tree/1.0 which is not a correct url.
For the specversion especially, it would be great to have a permalink for the cloudevents specification, maybe hosted on purl.org.

Maybe instead it could be schema:softwareVersion from schema.org.

I'm not sure that there is some dedicated vocabulary specifically for events in the computery sense of the word, cursory google search finds a couple which are for describing events like concerts.

With that context, the example from docs expands to the following structure:

{
    "specversion" : "1.0",
    "type" : "com.example.someevent",
    "source" : "/mycontext",
    "subject": null,
    "id" : "B234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/xml",
    "data" : "<much wow=\"xml\"/>"
}

expands to

[
  {
    "http://www.w3.org/1999/02/22-rdf-syntax-ns#value": [
      {
        "@value": "<much wow=\"xml\"/>"
      }
    ],
    "https://www.w3.org/2011/content#doctypeName": [
      {
        "@id": "https://www.w3.org/ns/iana/media-types/application/xml"
      }
    ],
    "http://purl.org/dc/terms/identifier": [
      {
        "@value": "B234-1234-1234"
      }
    ],
    "http://purl.org/dc/terms/creator": [
      {
        "@value": "/mycontext"
      }
    ],
    "http://purl.org/dc/terms/conformsTo": [
      {
        "@id": "https://github.com/cloudevents/spec/tree/1.0"
      }
    ],
    "http://purl.org/dc/terms/issued": [
      {
        "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
        "@value": "2018-04-05T17:31:00Z"
      }
    ],
    "http://purl.org/dc/terms/type": [
      {
        "@value": "com.example.someevent"
      }
    ]
  }
]

or, as a table

Subject	Predicate	Object	Datatype
_:b0	http://purl.org/dc/terms/conformsTo	https://github.com/cloudevents/spec/tree/1.0
_:b0	http://purl.org/dc/terms/creator	/mycontext	http://www.w3.org/2001/XMLSchema#string
_:b0	http://purl.org/dc/terms/identifier	B234-1234-1234	http://www.w3.org/2001/XMLSchema#string
_:b0	http://purl.org/dc/terms/issued	2018-04-05T17:31:00Z	http://www.w3.org/2001/XMLSchema#dateTime
_:b0	http://purl.org/dc/terms/type	com.example.someevent	http://www.w3.org/2001/XMLSchema#string
_:b0	http://www.w3.org/1999/02/22-rdf-syntax-ns#value	<much wow="xml"/>	http://www.w3.org/2001/XMLSchema#string
_:b0	https://www.w3.org/2011/content#doctypeName	https://www.w3.org/ns/iana/media-types/application/xml

(specversion doesn't actually work, it would be nice to have a permalink to the spec 1.0 using something like purl.org maybe)

Another way would be to specify a simple cloudevents ontology using rdfs and owl and host it within the specification, possibly proxied by purl.org to something like http://purl.org/cloudevents/1.0/ns#

@prefix : <http://cloudevents-ontology-permalink.com/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dc: <http://purl.org/dc/terms/> .

:# a owl:Ontology ;
    dc:source <https://github.com/cloudevents> ;
    dc:title "The RDF Cloudevents vocabulary (draft 1)" .

:Cloudevent a rdfs:Resource ;
    rdfs:label "Cloudevent" ;
    rdfs:comment: "An object conforming to the Cloudevents specification." .

:specversion a rdf:Property ;
    rdfs:comment "The version of the CloudEvents specification which the event uses. This enables the interpretation of the context." ;
    rdfs:range xsd:string .

:type a rdf:Property ;
    rdfs:comment "This attribute contains a value describing the type of event related to the originating occurrence. Often this attribute is used for routing, observability, policy enforcement, etc. The format of this is producer defined and might include information such as the version of the type - see <https://github.com/cloudevents/spec/blob/v1.0/primer.md#versioning-of-attributes> for more information." ;
    owl:sameAs dc:type .

:datacontenttype a rdf:Property ;
    rdfs:comment "Content type of data value. This attribute enables data to carry any type of content, whereby format and encoding might differ from that of the chosen event format. For example, an event rendered using the JSON envelope format might carry an XML payload in data, and the consumer is informed by this attribute being set to `application/xml`. The rules for how data content is rendered for different datacontenttype values are defined in the event format specifications; for example, the JSON event format defines the relationship in <https://github.com/cloudevents/spec/blob/v1.0/json-format.md#31-handling-of-data>" ;
    dc:conformsTo <https://datatracker.ietf.org/doc/html/rfc2046> .

:dataschema a rdf:Property ;
    rdfs:comment "Identifies the schema that data adheres to. Incompatible changes to the schema SHOULD be reflected by a different URI. See <https://github.com/cloudevents/spec/blob/v1.0/primer.md#versioning-of-attributes> for more information. for more information." ;
    rdfs:type xsd:anyURI .

:subject a rdf:Property ;
    rdfs:comment "This describes the subject of the event in the context of the event producer (identified by source). In publish-subscribe scenarios, a subscriber will typically subscribe to events emitted by a source, but the source identifier alone might not be sufficient as a qualifier for any specific event if the source context has internal sub-structure." .

:time a rdf:Property ;
    rdfs:comment "Timestamp of when the occurrence happened. If the time of the occurrence cannot be determined then this attribute MAY be set to some other time (such as the current time) by the CloudEvents producer, however all producers for the same source MUST be consistent in this respect. In other words, either they all use the actual time of the occurrence or they all use the same algorithm to determine the value used." ;
    rdfs:type xsd:dateTime ;
    dc:conformsTo <https://datatracker.ietf.org/doc/html/rfc3339> ;
    dc:sameAs dc:issued .

:data a rdfs:Property ;
    rdfs:comment "The event payload. This specification does not place any restriction on the type of this information. It is encoded into a media format which is specified by the datacontenttype attribute (e.g. application/json), and adheres to the dataschema format when those respective attributes are present." ;
    rdfs:type rdf:value .

Few open questions:

• Does it make sense to make specversion a link to a specific document, or keep it as a value field?
• Go with the small, "recommended context" route, or create and publish a full ontology?
• Where to host any permalinks that may be needed (for the vocabulary itself, specversion, ...); github, cloudevents.io, maybe kick the rock down the road and use purl.org?

[duglin]

@msladecek can you create a PR for the RDF doc you're thinking that we need? Then we can review that on a future call

[duglin]

@msladecek any update on this?