Proposal: Replace Key with Identifier & Title

[scottw]

One thing that proved very difficult in translating APML-XML into RDF
models was the "key" property, mainly because its value is sometimes
that of an opaque identifier such as a URI, and sometimes a human-
readable label, depending on where and when it was being used.

I'd like to propose for 1.0 that "key" is replaced by two elements:
identifier, and title.

A concept must have either an identifier (which must be a URI), a
title (which is any valid string literal), or both.

A source must have an identifier (which must be a URL) and may have a
title.

As both identifier and title are already defined within the Dublin
Core namespace we can then just reference those definitions from
within the APML spec.

[gdupont]

UP !

[Mason Lee]

Makes sense, Scott. I'd second that. In your view, are both
'Identifier' and 'Title' required attributes? That is, would you ever
expect people to do attention analysis ignoring one or the other?

Using human language keys (the "titles", or essentially, "tags") to do
attention analysis has always seemed problematic to me. I'd think
you'd at least want a "language" qualifier somewhere to distinguish
the French key "pain" from the English key "pain". But then that
language qualifier is essentially a namespace, and then you're pretty
much back to having URIs.

On the other hand, I remember that Chris months ago had expressed
interest in keeping everything super simple, whereby you have
basically one single key space that is APML. This was the argument
against URIs. If that's still a popular view, what about just
prefixing all those "simple keys" with something like "urn:apml.org:"
to make them into forever-neutral identifiers, never resolving (via
http) to anything more than the original simple strings. That would
force ad hoc interpretation of these keys whenever they are used, and
would possibly make implementation of APML easier for sites that use
only simple tags and want to use tags as keys (e.g. Flickr photo tags,
and millions of tag cloud sites). So for example, the semantically
ungrounded tag "pain" becomes this URI: "urn:apml.org:pain"

At any rate, going with Scott's suggestion, I would think the
"identifier" (uri) should be a required attribute and the "title"
optional, lest APML inadvertently promotes two independent systems of
attention analysis, URIs vs. Tags.

So I think we have the following ideas on the table:

1. All keys must be URIs.
2. However, not all keys must be URLs. (network resolvable)
2. It might be nice to have a very human-readable "title" attribute to
go along with keys.

--Mason

[gdupont]

> Using human language keys (the "titles", or essentially, "tags") to do  
> attention analysis has always seemed problematic to me.  I'd think  
> you'd at least want a "language" qualifier somewhere to distinguish  
> the French key "pain" from the English key "pain".  But then that  
> language qualifier is essentially a namespace, and then you're pretty  
> much back to having URIs.

Agree on that, especially as a french reader ;-)

> On the other hand, I remember that Chris months ago had expressed  
> interest in keeping everything super simple, whereby you have  
> basically one single key space that is APML.  This was the argument  
> against URIs.  If that's still a popular view, what about just  
> prefixing all those "simple keys" with something like "urn:apml.org:"  
> to make them into forever-neutral identifiers, never resolving (via  
> http) to anything more than the original simple strings.  That would  
> force ad hoc interpretation of these keys whenever they are used, and  
> would possibly make implementation of APML easier for sites that use  
> only simple tags and want to use tags as keys (e.g. Flickr photo tags,  
> and millions of tag cloud sites).  So for example, the semantically  
> ungrounded tag "pain" becomes this URI: "urn:apml.org:pain"

Two things :
- using such URN does not resolve the problem because I'll have "pain"
in french in my APML and you will have "pain" is english. Both of them
are resolved to "urn:apml.org:pain"... So we are not saved. We could
prefix the URN with a APML id like "urn:apml.org:myid.pain"
"urn:apml.org:yourid.pain" but then what everithing is unique for each
APML... not saved again.
- what is the point of having key that are build on APML structure ?
keep the key simple and buil the URN when you need it.

> At any rate, going with Scott's suggestion, I would think the  
> "identifier" (uri) should be a required attribute and the "title"  
> optional, lest APML inadvertently promotes two independent systems of  
> attention analysis, URIs vs. Tags.

I fully agree that having a URI based system is better than tags. But
you should at least have one tag to present the data to user if we
want to keep the system open too. If we stick on URI (and not always
URL), what will you present to the user when he want to see its APML ?
With tags is easy : you present a tagCloud. If your URI are URL, you
still can present tagcloud based on URL content or thumbnail of pages.

So keep at least one key (or title tor tag or label or whatever) for
presentation and have unique URI (either a link to RDf source or APML
urn if needed)

What do you think ?


gd

[TSchultz55]

gd,

RE:

> - using such URN does not resolve the problem because I'll have "pain"
> in french in my APML and you will have "pain" is english.

At the URI level, this can be differentiated - ex: http://dbpedia.org/resource/Pain
and http://dbpedia.org/resource/Bread

RE:

> I fully agree that having a URI based system is better than tags. But
> you should at least have one tag to present the data to user if we
> want to keep the system open too. If we stick on URI (and not always
> URL), what will you present to the user when he want to see its APML ?

Not always necessary - ideally, you'd use the rdf:label property as
the concept's "tag". You'd use the "rdf:description" property
(there's LOTS of languages supported) for a textual description of
what the concept URI represent.

In theory, all the information you need SHOULD be accessible from
making an HTTP request to the "/resource/<CONCEPT>" and pulling down
the metadata which clearly differentiates one thing from another
thing.

Maybe an actual demo of how I envision this happening would be
beneficial?

Cheers,

Tim

[gdupont]

UP for a demo of course.

I agree that if you have a valid URI then everything is ok and you may
find all the information you need to present in the RDF. However, I
think it may be useful to provide a first level usability of APML
without having to make any HTTP request. For instance I see some
benefits in having my own APML manager on my desktop : I'll be able to
manipulate it offline to add my interests (or they will be computed
from my desktop behaviour ?) and then when I'll go online, the manage
will propose URI to disambiguate the terms in my APML.

Do you see what I want to present ?

[scottw]

It is possible for the processing system to go and collect additional
metadata for each item, but I think pragmatically there will be plenty
of APML processors that won't be doing this, and so having a human-
readable label (whether dc:title or rdf:label or whatever) for
rendering for users (e.g. in a tag cloud) seems like a pretty strong
requirement.