Re: Best Practice for Renaming OWL Vocabulary Elements

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<glenn@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

Received on Thursday, 19 May 2011 16:54:23 UTC