Re: LinkedData != RDF ?

On 5/19/11 4:37 PM, Gregg Kellogg wrote:
> 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
>
>
>
Gregg,

Yes, LinkedData != RDF.

That's the truth,

That was the state of affairs when TimBL penned his initial AWWW 
oriented Linked Data meme. Sadly, the meme was revised  and has 
regressed ever since, courtesy of RDF and SPARQL insertion as mandatory 
standards rather than optional implementation details.

RDF didn't invent the triple.

All we need is a simple Graph Pictorial for expressing relations using 
3-tuples (EAV/SPO).

The schema is Conceptual and based on Logic. Nothing to do with Syntax.

The logic is basic: Observation Subjects are Qualified by Names. Their 
descriptions take the form of Attribute=Value pairs that coalesce around 
a Qualified Subject. Observations Subjects exist in Quantifies.

JSON can be used to express Linked Data without any RDF overhead. That's 
always been the case.

RDF is about Syntax for expressing Semantics. Trouble is that mangled 
narratives inadvertently project RDF as being the very progenitor of 
Semantic Graphs or the sole option for InterWeb scale Linked Data graphs.

I am hoping JSON-LD arrives at syntax for EAV graphs pronto. It should 
be dead simple modulo RDF.


Links:

1. 
http://www.openlinksw.com/dataspace/kidehen@openlinksw.com/weblog/kidehen@openlinksw.com%27s%20BLOG%20%5B127%5D/1624 
-- my old Data 3.0 manifesto (basically back to the original AWWW based 
Linked Data meme without RDF distractions)

2. http://www.slideshare.net/kidehen/iss-1 -- John F. Sowa presentation 
about Semantics that really clarifies this subject matter

3. http://graph.facebook.com/kidehen -- Profile Data Object from FB (a 
JSON graph)

4. 
http://linkeddata.uriburner.com/about/html/http/graph.facebook.com/kidehen 
-- Linked Data rendition of the FB Data Object

5. 
http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen 
-- Linked Data Object (actual description of Entity: kidehen, a Person)  
extracted from the FB Object (by tweaking their graph using Links as 
basis for the Description Graph)

6. http://uriburner.com/c/EW2ONJ -- example JSON representation of the 
above .



-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Thursday, 19 May 2011 21:11:37 UTC