Semantic OMB

From StatusNet
Revision as of 07:46, 16 April 2010 by Stéphane Thibault (Talk | contribs)
Jump to: navigation, search

In order to use the OpenMicroBlogging protocol in the context of Semantic Web / Linked Data (SW/LD) - based applications, here is a proposal on updating the current OMB 0.1.1 specification to a "Semantic OMB" one, based on the experience on designing SMOB and previous work on applications using FOAF / SIOC, etc for open and distributed Social Networking.

The following document is based on the original OMB 0.1.1 document, mentioning its compliance / need for improvement regarding the design of an open-microblogging platform (based on the aforementioned standard), both in terms of terminology and data exchange. It also defines some mappings between common terms and operations of OMB and their related implementation using SW/LD technologies.

The idea is to provide an OMB spec that can be ready-to-use for people that want to implement a SW/LD microblogging service, while still being compliant with people using other technologies.

Notes about the proposed mappings / improvements are indicated as follows

STATUS - Related comments about the compliance

There are four type of STATUS that have been defined, namely:

  • TERMINOLOGY when there is a need to mention the terminology used in a SW/LD system implementing OMB
  • COMPLIANT for a direct compliance, no change required (besides the use of the updated TERMINOLOGY)
  • ADAPT when there is a need to adapt the spec
  • DISCUSS when it requires more discussion to identify compliance or not

Besides the DISCUSS ones, there are no major obstacles of having a "Semantic OMB" from the current OMB specification.


Contents

Enabling technologies

Depends on OAuth 1.0, OAuth Discovery 1.0, YADIS 1.0.

TERMINOLOGY It also depends on RDF, FOAF, SIOC SPARQL and a subset of the currently-standardized SPARQL-Update for a SW/LD implementation. Note that these dependencies are for the implementation point of view, as the higher level, i.e. the protocol, still remains on the HTTP layer only. However, all the URIs used in that "Semantic OMB" protocol MUST be dereferencable and follow the Linked Data principles.

Terminology

  • microblogging service: undefined
TERMINOLOGY - A microblogging service is an instance of the sioct:Microblog class or any of its subclass (e.g. smob:Hub in the SMOB case)
  • user: undefined
TERMINOLOGY - A user is an instance of sioc:User
  • listen: to allow a remote service to send notices to the user's local service on a remote user's behalf.
COMPLIANT
  • listener: the person listening.
ADAPT - listener: the user listening
TERMINOLOGY - A listener is an instance of sioc:User.
  • listenee: the user sending notices.
TERMINOLOGY - A listenee is an instance of sioc:User
  • remote service: the listenee's microblogging service.
TERMINOLOGY - A remote service is an instance of the sioct:Microblog class or any of its subclass (e.g. smob:Hub in the SMOB case)
  • local service: the listener's microblogging service.
TERMINOLOGY - A local service is an instance of the sioct:Microblog class or any of its subclass (e.g. smob:Hub in the SMOB case)
  • profile URL: "home" URL for the listener, typically their profile page on a microblogging site.
TERMINOLOGY - A profile URL is an instance of the sioc:User class
  • nickname: An alphanumeric short name for a person, 1-64 characters.
TERMINOLOGY - A nickname is the foaf:name / foaf:nick / sioc:name property of an instance of sioc:User. Note that rdfs:label could also be used, providing a higher level of interoperability between services that may use different properties from the three previous ones (while RDFS inference shall solve this in theory, we assume that some Microblogging service may not provide such inference capabilities)
  • identifier URI: A globally unique and unchanging identifying URI for a user. Need not be an URL. [*]
TERMINOLOGY - A identifier URI is the URI of an instance of the foaf:Person class. Note that it MUST be mapped to the user thanks to the ties between foaf:Person and sioc:User with the foaf:account property
  • notice URI: A unique and unchanging identifier for a notice. Need not be an URL. [†]
TERMINOLOGY - A notice URI is the URI of an instance of the sioct:MicroblogPost class, e.g. http://apassant.net/smob/post/2010-02-03T17:40:59+00:00.

Initiation

The user submits their profile URL [‡] to the remote service somehow -- for example, with an HTML form on the remote service's Web site.

ADAPT - The user submits their profile URI (see "identifier URI" in the previous section), from which the profile URL will be dereferenced, e.g. http://apassant.net/alex (user URI) redirects to http://apassant.net (profile URL, including RDFa attributes to define the previous URI)

Discovery

COMPLIANT

Authorization

The remote service must go through the OAuth 1.0 dance to get authorization to post notices and update profiles.

In all OAuth, the consumer key should be the root URL for the microblogging service, if available. The secret should be the blank string (), unless the remote server and local service have negotiated another key. Such negotiation is out-of-scope for this document, and we assume an "open" network of microblogging services. But if you want to have that kind of network, do it with this key.

The remote service MUST do OAuth for every new listener, regardless of whether they've already received authorization for posting to the given postNotice URL. See Posting a Notice below.

COMPLIANT
TERMINOLOGY - The following / follower information SHOULD be loaded in two distinct graphs, e.g. "<local_service/followings>" and "<local_service/followers>" and that relationship between the user and each following / follower MUST be represented using the sioc:follows property. This information can be saved using SPARQL/Update INSERT, e.g. "INSERT INTO <local_service/followings> { <omb_listener> sioc:follows <omb_listenee> } " and "INSERT INTO <local_service/followers> { <omb_listennee> sioc:follows <omb_listener> }


Request token

The remote service uses the defined requestToken URL to get a request token.

In the request token HTTP request, the remote service MUST send the following additional parameter(s):

  • omb_listener The identifier URI for the listener.

In the results for the request token request, the local service MUST send the following additional parameters:

COMPLIANT

User authorization

In requesting user authorization, the remote service must send the following parameters:

COMPLIANT
  • omb_listener: The identifier URI for the listener.
COMPLIANT
  • omb_listenee: The identifier URI for the listenee.
COMPLIANT
  • omb_listenee_profile: The profile URL of the listenee.
ADAPT - Not needed as a mandatory parameter as omb_listenee_profile MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI.
  • omb_listenee_nickname: The nickname of the listenee.
ADAPT - Not needed as a mandatory parameter as omb_listenee_nickname MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI.
TERMINOLOGY - This information MUST be provided using the nickname terminology defined in the Terminology section of this document
  • omb_listenee_license: The default license URL for the listenee's stream. Typically the URL of a Creative Commons license, with the Attribution license being heavily encouraged. CC0 quitclaim also pretty good. The local service MAY reject listenees if their licenses are incompatible with the service.
ADAPT - Not needed as a mandatory parameter as omb_listenee_license MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI.
TERMINOLOGY - This information MUST be provided using the dc:licence from DublinCore or using cc:licence from the CreativeCommons vocabulary. If using a CC license, that license URI MUST be one of the ones provided by the CC vocabulary.

The remote service should send as many of the following parameters as possible. This will help the user decide if they really want to allow the listening to happen, and allow the local service to store a copy of the listenee's profile.

ADAPT - The data obtained when dereferencing omb_listenee URI should provide as many of the following parameters as possible. This will help the user decide if they really want to allow the listening to happen, and allow the local service to store a copy of the listenee's profile.
  • omb_listenee_fullname: The full name of the listenee. Up to 255 chars.
ADAPT - If one wants to pass this information, omb_listenee_fullname SHOULD be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the foaf:name property from FOAF.
  • omb_listenee_homepage: The home page of the listenee (may be distinct from the profile URL).
ADAPT - If one wants to pass this information, omb_listenee_homepage SHOULD be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the foaf:homepage property from FOAF.
  • omb_listenee_bio: A brief biography of the listenee; less than 140 chars.
ADAPT - If one wants to pass this information, omb_listenee_bio MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the rdfs:comment property (unless the domain of bio:olb property from Bio Vocabulary changes to an open domain).
  • omb_listenee_location: Physical location of the listenee; less that 255 chars. No fixed structure, but "Locality, Region, Country" or "Locality, Country" or "Locality, Region" recommended.
ADAPT - If one wants to pass this information, omb_listenee_location MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the geonames:locatedIn property from GeoNames ontology, and SHOULD link to a URI identifying the location.
  • omb_listenee_avatar: URL of a 96px by 96px image in PNG, GIF or JPEG format representing the listenee.

The local service, in a successful response, must return the following additional parameters:

ADAPT - If one wants to pass this information, omb_listenee_avatar MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the sioc:avatar property from SIOC.

The local service, in a successful response, must return the following additional parameters:

COMPLIANT
  • omb_listener_nickname: A nickname for the listener.
DISCUSS - I am not sure the creation of omb_listener_nickname is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
  • omb_listener_profile: The profile URL for the listener, possibly cleaned up or canonicalized. It should return as many of the following as possible:
DISCUSS - I am not sure the creation of omb_listener_profile is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
  • omb_listener_fullname : The full name of the listener. Up to 255 chars.
DISCUSS - I am not sure the creation of omb_listener_fullname is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
TERMINOLOGY - This information MUST be provided using the foaf:name property from FOAF.
  • omb_listener_homepage: The home page of the listener (may be distinct from the profile URL).
DISCUSS - I am not sure the creation of omb_listener_homepage is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
TERMINOLOGY - This information MUST be provided using the foaf:homepage property from FOAF.
  • omb_listener_bio: A brief biography of the listener; less than 140 chars.
DISCUSS - I am not sure the creation of omb_listener_bio is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
TERMINOLOGY - This information MUST be provided using the rdfs:comment property (unless the domain of bio:olb property from Bio Vocabulary changes to an open domain).
  • omb_listener_location: Physical location of the listener; less that 255 chars. No fixed structure, but "Locality, Region, Country" or "Locality, Country" or "Locality, Region" recommended.
DISCUSS - I am not sure the creation of omb_listener_location is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
TERMINOLOGY - This information MUST be provided using the geonames:locatedIn property from GeoNames ontology, and SOULD link to a URI identifying the location.
  • omb_listener_avatar: URL of a 96px by 96px image in PNG, GIF or JPEG format representing the listener.

This will allow the remote service to display information about the listener in the listenee's "listeners" or "subscribers" list.

DISCUSS - I am not sure the creation of omb_listener_avatar is needed remotely, as ideally such information would be distributed and linked from the remote service using the listener URI (cf distributed profiles in SMOB)
TERMINOLOGY - This information MUST be provided using the sioc:avatar property from SIOC.

Access token

COMPLIANT

Posting a Notice

To post a notice to the local service, the remote service sends an HTTP POST message to the postNotice URL discovered above. The message must use OAuth authorization. The message must also include the following parameters:

TERMINOLOGY - The message SHOULD be loaded in the local service using SPARQL/Update LOAD operator, simply loading the notice in the local store, e.g. "LOAD <omb_notice> "
COMPLIANT
  • omb_listenee: The identifier URI for the listenee.
COMPLIANT
  • omb_notice: The notice URI.
COMPLIANT
  • omb_notice_content The content of the notice. No maximum, but 140 chars is recommended.
ADAPT - Not needed as a mandatory parameter as omb_notice_content MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI

The message may include the following parameters:

  • omb_notice_url: The URL of the notice, if the notice is retrievable.
ADAPT - If one wants to pass this information, omb_notice_url MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
  • omb_notice_license: The URL of the license for the notice, if different from the listenee's default license.
ADAPT - If one wants to pass this information, omb_notice_license MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
TERMINOLOGY - This information MUST be provided using the dc:licence from DublinCore or using cc:licence from the CreativeCommons vocabulary. If using a CC license, that license URI MUST be one of the ones provided by the CC vocabulary.
  • omb_seealso: URL of additional content for the notice; for example, an image, video, or audio file.
ADAPT - If one wants to pass this information, omb_seealso MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
TERMINOLOGY - This information MUST be provided using the rdfs:seeAlso property.
  • omb_seealso_disposition: One of 'link' or 'inline', to recommend how the extra data should be shown. Default 'link'.
ADAPT - If one wants to pass this information, omb_seealso_disposition MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
  • omb_seealso_mediatype: Internet Media Type of the see-also data. Advisory, probably shouldn't be trusted.
ADAPT - If one wants to pass this information, omb_seealso_mediatype MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
  • omb_seealso_license: License for the attached data. May be distinct from the notice's license (if they're passing along someone else's content).
ADAPT - If one wants to pass this information, omb_seealso_license MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_notice" URI
TERMINOLOGY - This information MUST be provided using the dc:licence from DublinCore or using cc:licence from the CreativeCommons vocabulary (to differentiate from omb_notice_licence, that property shall not be attached to the licence itself, but to the URI identifying the attached data). If using a CC license, that license URI MUST be one of the ones provided by the CC vocabulary.

The local service should include the following parameters in its response:

COMPLIANT

Updating a profile

If the listenee's profile information changes, the remote service MAY send an HTTP POST message to to the updateProfile URL to tell the local service about the change.

TERMINOLOGY - The listenee profile SHOULD be loaded in the local service using SPARQL/Update LOAD operator, simply loading the notice in the local store, e.g. "LOAD <omb_listenee>"
COMPLIANT
  • omb_listenee: The identifier URI for the listenee.
COMPLIANT

The message may include any of the following parameters:

  • omb_listenee_profile: The profile URL of the listenee.
ADAPT - If one wants to pass this information, omb_listenee_profile MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
  • omb_listenee_nickname: The nickname of the listenee.
ADAPT - If one wants to pass this information, omb_listenee_nickname MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the nickname terminology defined in the Terminology section of this document
  • omb_listenee_license: The default license URL for the listenee's stream. A change in the default license only applies to future notices; notices previous to the update SHOULD be treated as under the old license.
ADAPT - If one wants to pass this information, omb_listenee_license MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the dc:licence from DublinCore or using cc:licence from the CreativeCommons vocabulary. If using a CC license, that license URI MUST be one of the ones provided by the CC vocabulary.
  • omb_listenee_fullname: The full name of the listenee. Up to 255 chars.
ADAPT - If one wants to pass this information, omb_listenee_fullname MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the foaf:name property from FOAF.
  • omb_listenee_homepage: The home page of the listenee.
ADAPT - If one wants to pass this information, omb_listenee_homepage MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the foaf:homepage property from FOAF.
  • omb_listenee_bio: A brief biography of the listenee; less than 140 chars.
ADAPT - If one wants to pass this information, omb_listenee_bio MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the rdfs:comment property (unless the domain of bio:olb property from Bio Vocabulary changes to an open domain).
  • omb_listenee_location: Physical location of the listenee; less that 255 chars.
ADAPT - If one wants to pass this information, omb_listenee_location MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the geonames:locatedIn property from GeoNames ontology, and SHOULD link to a URI identifying the location.
  • omb_listenee_avatar: URL of a 96px by 96px image in PNG, GIF or JPEG format representing the listenee.
ADAPT - If one wants to pass this information, omb_listenee_avatar MUST be contained in the description provided in the RDF data retrieved when dereferencing the "omb_listenee" URI
TERMINOLOGY - This information MUST be provided using the sioc:avatar property from SIOC.
Personal tools
Namespaces
Variants
Actions
Navigation
Status.net
Toolbox