Re: Comments on Data 3.0 manifesto

Hi Kingsley!

Reading between the lines, I think I grok where you are trying to go
with your "manifesto." For it to be an effective, stand-alone document
I think a few pieces are needed:

1. What is your GOAL? It should be clearly stated, something like, "to
promote best-practices for standards-compliant access to structured
data object (or entity) descriptors by getting data architects to do X
instead of Y," etc.

2. What is your MOTIVATION? I think this is implicit in your current
text --- your argument seems to be that TBL's "Four Principles" are
not enough --- but you need to make your motivations explicit and
JUSTIFY them. If TBL's principles are too nebulous, explain concisely
why and what the implications are. Keep in mind that they seem to be
"good enough" for many practitioners today. ;)

3. Be SPECIFIC about what practitioners must do moving forward. I
think you've made a good start on this, to the extent that you have
lots of "SHOULDS." I would argue that more specificity of a different
kind is needed; if data architects SHOULD be following more abstract
EAV conceptualizations, what exactly should they do in practice?

Finally, on the deeper question of motivation, I suggest that while a
historical argument can be made that RDF is likely a subset or special
case of EAV, the community has developed convenient and familiar
languages for expressing RDF (such as N3 and Turtle); practitioners
are much less familiar with EAV. Does the community really lose
anything by using RDF as its shorthand?

Perhaps you can suggest a pattern within current RDF practice that
more strongly enforces EAV principles?

John

On Sat, Apr 17, 2010 at 12:37 PM, Kingsley Idehen
<kidehen@openlinksw.com> wrote:
> Richard Cyganiak wrote:
>>
>> Hi Kingsley,
>>
>> Regarding your blog post at
>>
>> http://www.openlinksw.com/dataspace/kidehen@openlinksw.com/weblog/kidehen@openlinksw.com%27s%20BLOG%20%5B127%5D/1624
>>
>> Great job -- I like it a lot, it's not as fuzzy as Tim's four principles,
>> not as mired in detail as most of the concrete literature around linked
>> data, and on the right level of abstraction to explain why we need to do
>> certain things in linked data in a certain way. It's also great for
>> comparing the strengths and weaknesses of different data exchange stacks.
>
> Thanks, happy its resonating.
>
> RDF has inadvertently caused mass distraction away from the fact that a
> common Data Model is the key to meshing heterogeneous data sources. People
> just don't "buy" or "grok" the data model aspect of RDF, so why continue
> fighting this battle, when all we want is mass comprehension, however we get
> there.
>>
>> A few comments:
>>
>> 1. I'd like to see mentioned that identifiers should have global scope.
>
> Yes, will add that emphasis for sure. I guess "Network" might not
> necessarily emphasize that strongly enough.
>>
>> 2. I'd prefer a list of the parts of a 3-tuple that reads:
>>
>>     - an Identifier that names an Entity
>>     - an Identifier that names an Attribute
>>     - an Attribute Value, which may be an Identifier or a Literal (typed
>> or untyped).
>>
>>   This avoids using the new terms “Entity Identifier” and “Attribute
>> Identifier”.
>
> No problem.
>>
>> 3. “Structured Descriptions SHOULD be borne by Descriptor Resources” -- I
>> think this one is incomprehensible, because “to bear” is such an unusual
>> verb and has no clear connotations in technical circles. I'd encourage a
>> different phrasing.
>
> Will think about that, getting the right phrase here is is challenging, so I
> am naturally open to suggestions etc..
>
>>
>> 3b. Any chance of talking you into using “Descriptor Document” rather than
>> “Descriptor Resource”?
>
> No problem, "Descriptor Document" it is :-)
>>
>> 4. One thing that's left unclear: Can a Descriptor Resource carry multiple
>> Structured Entity Descriptions or just a single one?
>
> Descriptor Documents are compound in that they can describe a single Entity
> or a Collection.
>>
>> 5. Putting each term in quotes when first introduced is a good idea and
>> helps -- you did it for the first few terms but then stopped.
>
> Writers exhaustion I guess, will fix.
>
>>
>> 6. I'm tempted to add somewhere, “Descriptor Resources are Entities
>> themselves.” But this might be a purposeful omission on your part?
>
> Yes, this is deliberate because I am trying to say: "Referent" is the
> "Thing" you describe by giving it a "Name" so, anything can be a "Referent"
> including a "Document" (which has always been problematic in general RDF
> realm work e.g. the failure to make links between  a ".rdf" Descriptor
> Document and the actual "Entity Descriptions" they contain etc. via
> "primarytopic", "describedby", and other relations.
>>
>> 7. The last point talks about a “Structured Representation” of the
>> Referent's Structured Description. The term hasn't been introduced.
>> Shouldn't this just read “Descriptor Resource carrying the Referent's
>> Structured Description”?
>
> Yes, so basically this is: s/bear/carry/g  :-)
>>
>> What's your preferred name for the entire thing? I'm tempted to call it
>> “Kingsley's networked EAV model” or something like that. Do you insist on
>> “Data 3.0”?
>
> Well EAV is old, and one of my real inspirations for hamming its relevance
> to Linked Data is the fact that over the years I spoken with too many people
> that grok EAV but never connected it to the Semantic Web Project, or the
> more recent Linked Data meme.
>
> Imagine talking to founders of companies like Ingres, Informix, MySQL etc..,
> and witnessing them not making the EAV model connection; especially when you
> can't actually write a DBMS engine without comprehension of EAV,
> Identifiers, and Data representation (simple or complex data structure). How
> ironic!
>
>>
>> Best,
>> Richard
>
> Thanks for the great feedback, I think we're getting closer to the global
> epiphany we all seek !!
>
> --
>
> Regards,
>
> Kingsley Idehen       President & CEO OpenLink Software     Web:
> http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
>
>
>
>
>
>



-- 
John S. Erickson, Ph.D.
http://bitwacker.wordpress.com
olyerickson@gmail.com
Twitter: @olyerickson

Received on Saturday, 17 April 2010 19:31:01 UTC