On 5/19/11 4:39 AM, Martin Hepp wrote:
Hi all:
GoodRelations uses English keywords as concept identifiers, same as most programming languages
except for machine code and most markup languages (e.g. "h1" in HTML,
"property" in RDFa) use English keywords. The main reason is that as soon as the raw
identifiers need to be handled by humans, at least sometimes, then ergonomic considerations
recommend human-readable identifiers.
By the way, the question whether keys/identifiers in computer systems should be
human-readable is a freshmen's topic in Information Systems,
and the textbook knowledge is that
- cryptic keys are usually shorter and it is easier to avoid collisions (in the
sense of accidental duplicate assignment)
- human readable keys are much more productive for humans to handle.
The textbook recommendation in Information Systems is:
1. Use cryptic keys when the key is used ONLY by machines.
2. Use human-readable keys when key is, at least sometimes, used by HUMANS and
machines.
I see the point in using cryptic identifiers for conceptual elements in very
large vocabularies that will never be handled manually.
But for broadly used Web vocabularies, cryptic identifiers are as inadequate as
replacing all HTML element keys by hexadecimal codes.
By the way: Keep in mind that "you can write URIs on a bus". If
human-readability of URIs was irrelevant, why do business pay a lot of money for short or
catchy domain names?
Yes, but to whom do you speak when using the term: URI ? It is this usage that continues
to shape what I describe as the "elephant in the room" problem re. Linked Data
adoption. Basically, Linked Data adoption can be a smooth and coherently continuous
experience for Web users and developers.
I see quality Web users and developers as being comprised of the following
profiles:
1. Browser users - open and bookmark pages primarily via URLs
2. Web 1.0 developers -- works with HTTP as data access mechanism with HTML as
data representation format via URLs
3. Web 2.0 developers-- ditto with the addition of RESTful interaction
(client-server) patterns with XML and/or JSON as formats for data
representation.
To be frank - and sorry for offending people in here: If the opinions
dominating this discussion are representative of the community, then the
Semantic Web is bound to failure, because you seem to completely ignore
1. adoption issues, in particular ergonomics and cognitive aspects,
2. the economics of diffusion, and the
3. typical development environment of Web developers outside of research labs
(in terms of skills and tools).
Now what's still alienated from the larger conversation (that I am seeking to
smoke out) is this:
URLs should be hackable and human comprehensible as you already outline very
clearly. At the same time, URIs can be synthetic and opaque in the pure sense
too, the issue boils down to a warped Linked Data narrative that prefers a
pattern that skews the fundamental computer science in play re. data access by
reference.
Using Initial Entity Names and Representation Address examples from DBpedia as
an example, the browser driven sequence that drives experience is as follows:
1. http://dbpedia.org/resource/Paris --- DBpedia Name for the Entity: Paris
2. http://dbpedia.org/page/Paris -- HTML resource that delivers a Human
oriented description Paris (the Attribute=Value graph constructed around the
Subject: http://dbpedia.org/resource/Paris is sorta human discernible)
3. http://dbpedia.org/data/Paris.n3 -- N3 based machine oriented description of
Paris
4. http://dbpedia.org/data/Paris.rdf -- RDF/XML ditto
5. http://dbpedia.org/data/Paris.ntriples (will be .nt soon) -- N-Triples ditto.
Items 2-5 covers all about the Address (URL) aspect/function. Item 1 covers
the generic de-referencable Name aspect/function .
The problem with the pattern above is that it uses convenience to obscure the
underlying data access by reference concept (de-reference/indirection +
address-of) that's in play.
Most basic example (looking through end-user and Web 1.0 and 2.0 developer
lenses): I enter: http://dbpedia.org/resource/Paris into the *Address bar* of
any browser and right before my eyes I see:
1. http://dbpedia.org/page/Paris -- in the address bar
2. HTML document describing 'Paris'.
Immediate quandary: what do I bookmark? Remember, users bookmark resource
addresses (URLs).
Now imagine an alternative sequence:
1. http://dbpedia.org/page/Paris -- user knows this is a page (document) about
Paris and also knows it can be bookmarked
2. http://dbpedia.org/resource/Paris --- confined to @href which is associated with
relevant portion of "About: Paris" text
3. http://dbpedia.org/data/Paris.n3 -- discovered by footer links (human),<link/> (web
1.0 or 2.0 developer), or "Link:" header responses (web 2.0 and 3.0 developers)
4. http://dbpedia.org/data/Paris.rdf -- ditto
5. http://dbpedia.org/data/Paris.ntriples (will be .nt soon) -- ditto.
The bookmark confusion matter is resolved. Entity Name / Representation
Address ambiguity matter (inherent to HTTP URI usage) slightly reduced.
Now here's the bigger problem. What happens when my Entity Names have to be
synthetically generated (old school identifier style) but I seek human oriented
resources (documents) addresses with human interaction in minde? Can I
introspectively discern an Entity Name from its Representation accessed via an
Address? The answer to this question is Yes, but it means you really have to
accept that the DBpedia Linked Data URI/URL pattern isn't the gold standard,
its just a style that works for the DBpedia usecase.
Here is another sequence, this time leveraging .well-known/host-meta (Web
Linking) pattern:
1. http://dbpedia.org/.well-known/host-meta -- this is a Web 2.0 developer
step re. discovering URI template patterns for an given data space that's
unimportant to end-users
2. http://dbpedia.org/describe/?uri=http://dbpedia.org/resource/Paris --
end-user oriented URL that's bookmark friendly and hack-able
3. http://dbpedia.org/resource/Paris --- confined to @href which is associated with
relevant portion of "About: Paris" text
4. http://dbpedia.org/data/Paris.n3 -- discovered by footer links (human),<link/> (web
1.0 or 2.0 developer), or "Link:" header responses (web 2.0 and 3.0 developers)
5. http://dbpedia.org/data/Paris.rdf -- ditto
6. http://dbpedia.org/data/Paris.ntriples (will be .nt soon) -- ditto.
Comments:
We have URLs as the focus, bookmark pattern preserved, plus data mobility i.e.,
DBpedia data objects can reside in multiple data spaces without an DNS
heuristics re. delivering on Linked Data goals re. data access across Linked
Data Spaces, that's also decoupled from DNS.
Here is a sequence that showcases my point:
1.
http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Fdbpedia.org%2F.well-known%2Fhost-meta&useragentheader=&acceptheader=
-- discover templates offered by the dbpedia.org data space
2.
http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Flod.openlinksw.com%2F.well-known%2Fhost-meta&useragentheader=&acceptheader=
-- ditto for LOD cloud cache data space
3. http://dbpedia.org/describe/?uri=http://dbpedia.org/resource/Paris --
description of 'Paris' from DBpedia
4. http://lod.openlinksw.com/describe/?uri=http://dbpedia.org/resource/Paris --
ditto from LOD cloud cache.
There are two functions (not one) in play when dealing with Hyperdata Links or
Hyperlinks used as mechanism for Whole Data Representation re. AWWW based
Linked Data meme. If there are two functions in play, and one is already widely
used by the target users ( i.e., the Address function - URL), why do we
instinctively speak about the de-reference (indirection) based Name function
irrespective of target audience?
If what I am pushing against is so wrong, then tell me why this old time tested
pattern is so difficult to comprehend by broader audiences, once AWWW based
Linked Data fronts the narrative?
Here is my final example, this time using Facebook Data Object URL:
http://graph.facebook.com/kidehen .
Note I get the following data from the Facebook URL:
{
"id": "605980750",
"name": "Kingsley Uyi Idehen",
"first_name": "Kingsley",
"middle_name": "Uyi",
"last_name": "Idehen",
"link": "https://www.facebook.com/kidehen";,
"username": "kidehen",
"gender": "male",
"locale": "en_US"
}
Note that "id" is literal and so is its value. This chunk of data (resource)
doesn't have a Name it just has an access Address. Of course, this isn't the case within
Facebook's internal setup etc..
If I tweak the "id" value and replace it with a Link, I've added some Web scale
introspection that also delivers a Name to this erstwhile anonymous data object.
{
"id": http://www.facebook.com/kidehen#this,
"name": "Kingsley Uyi Idehen",
"first_name": "Kingsley",
"middle_name": "Uyi",
"last_name": "Idehen",
"link": "https://www.facebook.com/kidehen";,
"username": "kidehen",
"gender": "male",
"locale": "en_US"
}
Repeat what I've stated above for each Attribute=Value pair and you soon have a
Linked Data graph i.e. data representation using Links delivered via a JSON
based Graph.
Finished product (courtesy of our Linked Data middleware aka Sponger):
1. http://linkeddata.uriburner.com/about/html/http/graph.facebook.com/kidehen
-- HTML based Data Container (Data Source) Description Doc
2.
http://linkeddata.uriburner.com/about/html/http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
-- HTML based Profile Doc
3.
http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
-- Proxy Linked Data URI for Profile Page Subject (me in this case)
4.
http://linkeddata.uriburner.com/describe/?uri=http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
- alternative Entity Description page using pattern from example above .
Conclusion: it isn't about synthetic vs natural identifiers. It's about accentuating the
mechanics of Linked Data with clarity so that we can introduce this concept to a broader
community of people, including those that have long mastered the fundamental mechanics of
"data access by reference" in other realms of applied computer science.
We shouldn't attempt to carve out an Island from the continent sized continuum
of computer science.
Loose use of URI as Linked Data narrative driver hasn't cut it to date, and
that won't change anytime soon re., moving forward :-)
Kingsley
Best wishes
Martin
PS: I assume you are not proposing to use cryptic class names in Java
programming, hexadecimal parameter names in REST interfaces, numeric e-mail
addresses, hash values as twitter user identifiers, skype account identifiers,
and replacing top-level domains by a two-digit hex number.
Outlook into the simply wonderful future that you are proposing:
- My e-mail address, as suggested by the SW community: AE0FD5678F@AAEE101F.0F
- HTML, revisited by the Semantic Web Community
<F7E3>
<03ED>Page</03ED>
<0709>Paragraph</0709>
<03EE>
<77FF>
<87ED>blabla<87ED>
<87ED>blabla<87ED>
<87ED>blabla<87ED>
</77FF>
</03EE>
</F7E3>
- Python, revisited by the Semantic Web Community
class EE77E303(BB1233.AAB012):
"""Returns an RDF/XML dump of the ontology classes"""
def 0936123(self, A34D=True):
""" Dump page handler - returns one single RDF/XML representation of the
ontology """
if 'Accept' in self.B345.B7934:
ABCD = self.B345.B7934['Accept']
else:
ABCD = ""
self.B345.B7934['Content-Type'] = "application/rdf+xml"
self.B345.B7934['Access-Control-Allow-Origin'] = "*" # CORS
if A34D:
- Python, revisited by the Semantic Web Community in collaboration with the
Pedantic Web Movement (enforcing the consistent implementation of a bad idea ;-)
001A EE77E303(BB1233.AAB012):
"""Returns an RDF/XML dump of the ontology classes"""
B123 0936123(0000, A34D=FFFF):
""" Dump page handler - returns one single RDF/XML representation of the
ontology """
AA 'Accept' in 0000.B345.B7934:
ABCD = 0000.B345.B7934['Accept']
BB:
ABCD = ""
0000.B345.B7934['Content-Type'] = "application/rdf+xml"
0000.B345.B7934['Access-Control-Allow-Origin'] = "*" # CORS
AA A34D:
PPS: I wrote some kilobytes of Z80 programs in pure machine code without having
an assembler at hand back in the 1980s. I know what I am talking about ;-)
On May 18, 2011, at 10:14 PM, Michael F Uschold wrote:
see below.,
On Wed, May 18, 2011 at 12:55 PM, glenn mcdonald<gl...@furia.com> wrote:
I agree wholeheartedly that URIs should be pure identifiers, with no embedded
semantics or assumptions of readability. And I agree with Kingsley that there's
an elephant in the room. I might even agree with Kingsley about what the
elephant is.
But to say it from my point of view: machines need to think in ids, people need to think
in names. The RDF/SPARQL "stack", such as it is, has not internalized the
implications of this duality, and thus isn't really prepared to support both audiences
properly.
Very well put, Glenn!
Almost all the canonical examples of RDF and SPARQL avoid this issue by using
toy use-cases with semi-human-readable URIs, and/or with literals where there
ought to be nodes. If you try to do a non-trivial dataset the right way, you'll
immediately find that writing the RDF or the SPARQL by hand is basically
intractable. If you try to produce an human-intelligible user-interface to such
data, you'll find yourself clinging to rdfs:label for dear life, and then
falling, falling, falling...
In fact, there's almost nothing more telling than the fact that rdfs:label is
rdfS! This is in some ways the most fundamental aspect of human/computer
data-interaction, and RDF itself has essentially nothing to say about it.
--
Michael Uschold, PhD
Senior Ontology Consultant, Semantic Arts
LinkedIn: http://tr.im/limfu
Skype, Twitter: UscholdM
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
