RE: QNames in attributes yet?

> > What is the feeling of the RDF community about this, particularly
> > those implementing systems?
> 
> Obviously, the working group is very open to feedback -- are 
> there people out there who really want this feature? Are 
> developers interested in implementing it?
> 
> I haven't heard much so far, but if there's a significant 
> response, I will take that information back to the Working Group.

Well, the reason why it seemed to me that there was strong motivation 
for adoption of QNames within attribute values is that every RDF tool
I've used or even looked at includes the non-standard extension of
allowing one to use QNames pretty much anywhere so you don't have to
type long URIs. And the fact that N3 adopts such a usage further shows
IMO that this is considered the way things should be done.

Not to mention the precident set by XML Schema for such syntactic
conveniences.

Obviously, an RDF engine itself wouldn't care one way or another as
it is working with the URIs and machines don't care about long URIs
versus short QNames.

I was mostly interested in views from folks who have been deploying
RDF in contexts where "regular" people may be manually defining RDF
statements.

From my own experience, when I try to convince folks that they need
to write stuff like 

   <mars:language
rdf:resource="http://metia.nokia.com/MARS/2.1/Language/en"/>

instead of

   <mars:language rdf:resource="lang:en"/>

or 

   <mars:language rdf:value="en"/>

let's just say the response is one where full body armor would not be
out of place ;-)

And the latter example is IMO more trouble than it's worth as the literal
must either be transformed to a resource reference during preprocessing
before getting to an RDF parser, or applications have to include alot of
extra unnecessary logic to process the literal and apply knowledge of the
literal which otherwise would be defined simply using RDF.

Yes, ideally, real humans would be interacting with glitzy graphical user
interfaces and all of the messy reality of RDF would be hidden from them,
but living as we do in a less-than-perfect world, any conveniences that can
be found in the RDF serialization itself are worth their weight in gold.

Relieving knowledge authors from the burden of long cryptic URIs would IMO
go a long way towards making RDF serialization a bit more attractive to
folks who have to do-it-in-the-raw, per se. It's definitely a "marketing"
issue, not technical at all, and such a change as you point out is not
"fixing" anything insofar as the nuts-n-bolts of RDF are concerned, but as
the marketing gurus keep telling us, packaging and presentation often count 
more than the product itself when striving for public acceptance...

If no'one else really cares one way or another about this, then nevermind...
it just seemed to me that this was a popular expectation and I was surprised
to hear that it was not under serious consideration.

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Monday, 24 September 2001 02:32:17 UTC