LinkedData != RDF ?

Thinking about Manu's suggestion that JSON-LD might not necessarily need to be RDF I came up with some thoughts about what an alternative Linked Data representation might look like.

Given that the RDF WG is really just doing minor tweaks to RDF, and not addressing the problems with greater adoption of RDF in the web development community, this might indeed be the way to go. A new Linked Data model could really address the needs of developers without necessarily being constrained by the formalism of RDF and OWL. If people are interested in this, it would be good to discuss. Here are some of my ideas for an alternative to RDF:

* The model should be based on the notion of graphs, similar to RDF, but where the semantics are more Class/Object based, rather than predicate based. (i.e., I define a class definition with specific properties and class inheritance/implements more similar to Ruby/Python, rather then being predicate based.

* The model should be naturally be processed in web-like languages (JavaScript, Ruby, Python, etc.).

* The need to manage multiple ontologies/vocabularies is a real problem for adoption of RDF in many areas. Something that allows a local definition of a vocabulary where equivalence to OWL ontologies might also be defined, would work better with the actual practice of vocabularies in the wild. In JSON-LD, @vocab allows for local definition of these vocabularies, and the RDFa @profile mechanism might provide a way to define these remotely.

* RDFS/OWL entailment along with other entailment regimes can be difficult for people to master, and can be computationally expensive. A way to define property type and cardinality constraints directly within the vocabulary definition could also make this simpler for real world applications. Ruby on Rails ActiveRecord::Associations has_many, has_one, belongs_to type are probably sufficient for cardinality, and the @coerce semantics a reasonable way of defining type constraints. Other type identities might be defined by expressing equivalence with native language types (e.g., Integer, DateTime, etc.) or to a user-defined class. Properties of these classes would be defined using WebIDL.

* Do away with blank nodes by defining a process for generating hash references relative to @base. BNodes are really a bad idea, in my mind. In SPARQL, they're overloaded with non-distinguished variables. It would be better to define a mechanism for generating anonymous nodes when necessary, as frags off of @base. For example:

	{ "@context":	{ "@genid":	"#_[a-z]{3}[0-9]+" } }

Could be a way to define a regular expression used to recognize and/or generate anonymous nodes (recognition might not be important for any new data model).

* I've promoted a different notion of lists myself for some time, something similar to the OrderedList ontology [1]. The fact is that graphs simply don't provide a way to define properties of edges (such as ordering). In many systems, the way to do this is through a helper class. For example, in ActiveRecord, consider the following:

	has_many	:orderings
	has_many	:ordered_elements, :through => :orderings

is a way of defining that an "orderings" class is used to define the properties of "ordered_elements", such as an "order" attribute. We could potentially do this using the proposed list syntax, but leave the definition of the list semantics to something defined within @context:

{
	"@context":	{
		"@base": "..",
		"olo":	"http://purl.org/ontology/olo/core#",
		"ex":	"http://example.com/",
		"@list": {
			"@through":	"olo:Slot",
			"@index":	"olo:index",
			"@item":		"olo:item",
			"@property":	["ex:playlist"]
		},
		"@coerce": { "xsd:anyURI":	"ex:playlist" }
	},
	"@":		"",
	"dc:title":	"My Album",
	"ex:playlist":	[[ "#track1", "#track2" ]]
}

This might provide some semantic for how the elements of a list are to be defined, the result could be something like the following:

	<> dc:title "My Album";
		ex:playlist
			[a olo:Slot; olo:index 1; olo:item <#track1>],
			[a olo:Slot; olo:index 2; olo:item <#track2>] .

Without defining @list on a property, the semantics to devolve to  RDF List, for example. Conceivably, other list vocabularies could also be used, and we could define more properties on the list edges by adding property definitions to the join class definition.

RDF's formalism and logic-based roots are a double-edged sword. Finding a middle-ground between a rigorous definition and a common-sense Linked Data definition will be difficult, but may be what's required to make these principle relevant to a wider community.

Gregg

[1]: http://smiy.sourceforge.net/olo/spec/orderedlistontology.html

Received on Thursday, 19 May 2011 20:38:05 UTC