Re: Best Practice for Renaming OWL Vocabulary Elements

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?

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).

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
>

Received on Thursday, 19 May 2011 08:42:58 UTC