Re: LinkedData != RDF ?

On 5/19/11 7:20 PM, Sandro Hawke wrote:
> On Thu, 2011-05-19 at 17:11 -0400, Kingsley Idehen wrote:
>> 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.
> Says you.
>

Yes, I say :-)

>> That's the truth,
> In your mind, perhaps.

Absolutely !

>> 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.
> When Tim minted the new term, "Linked Data", and began to popularize it,
> he avoid an explicit mention of RDF because there were a lot of people
> who were rejecting RDF without having a clue what it was.

So you say, and of course your are entitled to deem that to be true.

Methinks, TimBL always understood that using Links for whole data 
representation via graphs didn't require RDF syntax. He also always 
understood that you can represents graphs using a variety of Syntaxes.  
He never (at least initially) opted to make RDF a sole option.

Please do understand, and this is extremely important, the case against 
RDF re. Linked Data is that it is very very obstructive during the early 
uptake phase. As I've stated repeatedly, RDF has its own genuine 
virtues. The problem with RDF is making a power grab for Linked Data is 
a negative. Linked Data and RDF are not inextricably linked, RDF 
provides an optional route to the Linked Data destination.

At this juncture, we just want Linked Data to takeoff. I want it to 
regain the moment it had in 2007 during its first critical bootstrap.

Continuing a quest to make RDF the sole option for Linked Data is a 
fatal flaw.

>   He thought
> people might come to understand and accept the concepts if they come to
> them from a different direction.  Once they got the idea, they'd realize
> RDF itself wasn't a problem.

And what happened to that hope/expectation/assumption ?


> At some point, I noticed some people using the term "Linked Data" to
> refer to some non-RDF data.

Yes, cos Linked Data structures have existed for eons in computing. The 
ingenuity of URIs allows this to happen at InterWeb scale via Links.

> I pointed this out to Tim, asking if he
> really meant to allow non-RDF data as part of his idea of "Linked Data".
> He said he meant it to be RDF-only, and at that point, to clarify, he
> added the reference to RDF.

Well, there's really no harm in dropping the RDF option since:

1. Linked Data Structures have always existed
2. Linked Data Structures at InterWeb scale via Links simply accentuate 
the ingenuity inherent in his creations .

>> RDF didn't invent the triple.
> Indeed.   Triples are pretty basic.
>
>> 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.
> What "RDF Overhead"?    RDF is just triples, with a few simple

RDF overhead is about inertia that it injects into the following re. 
Linked Data meme:

1. Comprehension
2. Uptake at WWW scales.

> clarifications:
>    - objects can optionally have ids
>    - when they do, those ids are URIs
>    - some objects can be data values (literals), with types, if you want
>    - some objects can be text with language tags, if you want
>    - the relationships/properties are identified with URIs
>
> What's weird or complex or non-obvious about that, aside from the use of
> URIs, which is clearly part of Linked Data?

Even as of today, the behavioral expectations of URIs aren't clearly 
defined in RDF with regards to Linked Data. You've described the 
components of Graph construction but overlooked operation mechanics of 
the URI in this context:

1. de-reference (indirection)  -- Names that resolve
2. address-of -- how you access the Graph (representation format 
negotiable) .

Simply saying "URIs" is the root of the problem re. Linked Data and were 
the RDF distraction aspect starts.

>
>
> I mean, maybe the language tags are a bit weird, but people who work on
> multilingual systems tell me they are very important.

They are very very important. But they aren't front door items.

>    Given I've
> spent the last two weeks in Luxembourg and Bilbao, each of which seems
> to have two primary languages which I don't really speak, I'm especially
> sympathetic.

Yes. No disagreement here. RDF is very very good in this regard.
> (Yeah, and, okay, the handling of sequences in RDF is pretty awkward,
> but there are some workarounds, and maybe one of them will become
> standards soon.)
>
>> RDF is about Syntax for expressing Semantics. Trouble is that mangled
>> narratives inadvertently project RDF as being the very progenitor of
>> Semantic Graphs
> I'll certainly agree mangled narratives are a problem.....
>
>> or the sole option for InterWeb scale Linked Data graphs.
> I know I'm biased, but I think if you're going to propose something
> that's a lot like RDF, but subtly different, it has to be *extremely*
> well motivated.    This seems a bit like proposing your own version of
> ASCII with a few characters different.

Motivation: let TimBL's original meme bootstrap. Its mega defensible, 
and extremely ingenious across many dimensions (technical and marketing 
wise).

At the right time (post bootstrap) RDF itself will emerge and enable 
players differentiate themselves. Sadly, none of this will happen if we 
insist on RDF at the front door. We can simply erase 12+ years like it 
didn't happen. RDF has a stigma attached to it.
>> I am hoping JSON-LD arrives at syntax for EAV graphs pronto. It should
>> be dead simple modulo RDF.
> I'm all for dead simple.  RDF, especially if you use it in certain
> styles (what I've called "page mode" or "simplified RDF") is dead
> simple.

Let's just rewind, we'll all arrive at the desired destination plus some 
unexpected benefits like RDF comprehension and appreciation. For now, 
let's get it out of the way and focus on whole data representation using 
Links :-)


Kingsley
>      -- Sandro
>
>> 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 23:58:43 UTC