David Booth wrote:
On Wed, 2010-06-30 at 14:30 -0400, Kingsley Idehen wrote:
Nathan wrote:
Pat Hayes wrote:
[ . . . ]
Surely all of the subjects as literals arguments can be countered with
'walk round it', and further good practise could be aided by a few
simple notes on best practise for linked data etc.
IMHO an emphatic NO.
RDF is about constructing structured descriptions where "Subjects" have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An "Identifier" != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
Can you explain *why* you think literals should not be permitted as
subjects? The rationale you have given above sounds like it is saying
that literals should not be subjects because RDF does not permit
literals to be subjects.
IMHO, RDF should allow "anyone to say anything about anything" -- not
"anyone to say anything about anything . . . except a literal".
However, if you see some specific harm in permitting statements about
literals, please tell us what that harm would be.
Harm isn't of the "breaks anything variety". It just adds ambiguity to
the process of producing structured descriptions within Web realm.
I could flip this around and ask: what makes a pure URN or other
identification schemes (that may or may not resolve to anything)
problematic?
I am of the assumption that we are seeking globally unambiguous names
(which may or may not resolve) re. Web of Linked Data aspect of Semantic
Web continuum.
RDBMS engines support literal identifiers, and the consequences are:
1. Distributed RDBMS tedium -- due to object ambiguity across
Qualifier/Schema/Database, Owner, and actual Object Name (Tables, Views,
Procedures) names
2. Security problems -- users are Identified using literals instead of
proper identifiers (as demonstrated by FOAF+SSL [3] WebIDs you can
provide blockers to socially engineered RDBMS vulnerability via
verifiable identity + data access policies).
Links:
1. http://en.wikipedia.org/wiki/Identifier
2. http://en.wikipedia.org/wiki/Unique_identifier
3. http://esw.w3.org/Foaf%2Bssl
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
