W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2011

Re: JSON-LD Telecon Minutes for 2011-07-04

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Tue, 5 Jul 2011 18:10:15 -0400
To: Bradley Allen <bradley.p.allen@gmail.com>
CC: Kingsley Idehen <kidehen@openlinksw.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-ID: <A3D288F0-0650-4732-968E-52DB085BC4DB@kellogg-assoc.com>
On Jul 5, 2011, at 10:23 AM, Bradley Allen wrote:

> Allow me to jump into the breach here with a reworded set of points
> that attempt to capture Kingsley's feedback:
> 1. Linked Data is a set of documents, each containing a representation
> of a linked data graph.
> 2. A linked data graph is a labeled directed graph, where nodes are
> subjects or objects, and edges are properties.
> 3. A subject is any node in a linked data graph with at least one outgoing edge.
> 4. A subject MAY be labeled with an IRI.
> 5. A property is an edge of the linked data graph.
> 6. A property SHOULD be labeled with an IRI.
> 7. An object is a node in a linked data graph with at least one incoming edge.
> 8. An object MAY be labeled with an IRI.
> 9. An IRI that is a label in a linked data graph SHOULD be
> dereferencable to a Linked Data document describing the labeled
> subject, object or property.
> Bradley P. Allen
> http://bradleypallen.org

This is a great re-formulation of what I believe we were trying to attempt in the original definition and in the revision from the telecon. As is, I don't believe that any explicit mention of unlabled nodes is required, as it is implicit in the definition.

Where we didn't get on the telecon, and what isn't mentioned here, is the ability to have object nodes representing scalar values such as strings, dates, times, or anything else. To re-use a term, we might define such nodes a "literals". A _literal_ might be considered to be any labeled node where the label is not an IRI. We could then leave to subsequent definitions if a literal may have a datatype or a language.


> On Tue, Jul 5, 2011 at 10:12 AM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
>> Kingsley, thanks for the feedback.
>> If you're requiring as a basic precept that every URI used in an LD graph be de-referencable, this would leave out statements of the set of URIs that are not de-referencable. This would seem to also include URNs. I don't think it's appropriate to limit JSON-LD to use only de-referencable URIs. However, I do believe that a best practice (where feasible) is to use de-referencable URIs, where a suitable representation is returned.
>> Otherwise, can you suggest a re-wording of the LD points in [1] that would be more accurate?
>> Gregg
>> [1] http://json-ld.org/requirements/latest/#linked-data
>> On Jul 5, 2011, at 1:45 AM, Kingsley Idehen wrote:
>>> On 7/5/11 7:09 AM, Manu Sporny wrote:
>>>> Topic: Formal Definition of Linked Data
>>> First assertion about Linked Data reads:
>>> Linked Data is used to represent a directed graph .
>>> Sorry, but that's back to front, at best.
>>> A directed graph used to represent (describe) an object can be
>>> constructed in such a way that subject name, subject attributes, and
>>> subject attribute values take the form of de-referencable URIs.
>>> In the case of Linked Data, specifically, a URI de-references to a
>>> representation of its Referent. It does this because an Object has
>>> Identity distinct from its Representation. Thus, an Object has a Name
>>> that's distinct from the EAV/SPO graph pictorial that delivers its
>>> description (representation). Naturually, on the Web (as is the case
>>> with a computer's local OS), said representation exists as the content
>>> of a Resource at a location (Address).
>>> Of course, you don't have to accept my definition of Linked Data. But
>>> note this, bar different turn of phrase, I've just outlined the very
>>> essence of TimBL's original Linked Data meme prior to the regressive
>>> tweak that added "(RDF* and SPARQL)" to its later revision. The day
>>> "(RDF* and SPARQL)" are dropped from the meme or described as
>>> implementation details is the day that meme returns to its GOLDEN status
>>> IMO.
>>> At this juncture, the JSON-LD definition of Linked Data is inaccurate.
>>> You can make graphs that aren't Linked Data purveyors. Thus, don't
>>> conflate graphs and linked data, let alone application of the linked
>>> data concept to a global data space such as the WWW. The specific use of
>>> URIs as part of graph construction is integral to what linked data is
>>> about.
>>> From RDF to JSON-LD conflation remains a problem. Conflation ultimately
>>> breeds confusion.
>>> The pieces of the puzzle:
>>> 1. Graphs -- an effective data structure fine grained data representation
>>> 2. de-referencable URIs -- critical data structure tapestry (remember a
>>> URI isn't implicitly de-referencable, the URL subClassOf URI is)
>>> 3. Resources -- data (collections of eav/spo triples) containers
>>> accessible from addresses.
>>> Current list of conflation examples:
>>> 1. Resources -- everything is a resource meme is inaccurate since it
>>> dangerous ignores perception media (WWW and Real World are related but
>>> distinct media)
>>> 2. Graphs -- RDF is the only mechanism for graph representation or that
>>> graph means RDF rather than RDF being an option for graph based data
>>> representation
>>> 3. Linked Data -- to the RDFer Linked Data and RDF are one and the same
>>> 4. JSON-LD -- Linked Data is either a subset of RDF or its used to
>>> represent directed graphs.
>>> Sincerely hoping these comments are digested. I have but a single goal:
>>> kill off conflation so we can make progress re. InterWeb scale Linked
>>> Data without forcing syntax or data serialization formats on anyone.
>>> Openness isn't as easy as folks assume. To be truly open you have to
>>> invest heavily in the significant costs associated with choice.
>>> --
>>> 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 Tuesday, 5 July 2011 22:11:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:30 UTC