Richard Cyganiak wrote:
Hi Kingsley,
Regarding your blog post at
http://www.openlinksw.com/dataspace/[email protected]/weblog/[email protected]%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
