On 24 Nov 2006, at 01:44, Henri Sivonen wrote:
On Nov 23, 2006, at 22:42, Henry Story wrote:
This is very nice, in that it opens up the possibility of placing
good RDF descriptions of these links at the http://www.iana.org/
assignments/relation/,
How could new link relations be described in RDF to such a degree
that the description would actually be useful for software
processing but simple enough to actually be implemented? Is it
realistic to have UAs whacking IANA server effectively performing a
DDoS on it?
Just some interesting uses of this beyond your question:
- The RDF file would serve as a useful machine readable description
of the relation, and so serve as documentation.
- This would simply make those terms re-useable in other rdf
vocabularies, which could be very useful. Do you have an RDF file
that needs the notion of an alternate link? Well just use elements
from that vocabulary.
But to get to your point:
The description on the server would probably not be very advanced. It
would probably be very simple, like the Dublin Core vocabulary
( http://dublincore.org/ ). And so you are right this would probably
not say much more than that :alternate is a relation. Perhaps one
could even specify the Domain and the Range of the relation to be
documents.
Not much that one could automate. The default relations would rarely
change, so User Agents would never query the server directly, and so
you would not have a DDoS on them.
On the other hand, clients wanting to define new relations (as URLs)
could place the definitions of these relations on their server, and
say some more interesting things such as
<http://my.eg.com/rel#entry> rdfs:subPropertyOf <http://iana.org/
assignments/relation/alternate> .
The user agent would now know that this new entry relation is also an
alternate relation. Perhaps this could save having to place both
relations inside of every document.
as well as making the link relation very extensible (people who
want to try out new link relations, can just use their own,
unambiguous url).
How are full URIs distinguished from strings that need to be
appended to "http://www.iana.org/assignments/relation/"; to obtain
the full URI? Are UAs supposed to look for a colon as with XForms
input methods? Where is this specified?
This is specified in the atom syntax document.
[[
The value of "rel" MUST be a string that is non-empty and matches
either the "isegment-nz-nc" or the "IRI" production in [RFC3987].
Note that use of a relative reference other than a simple name is not
allowed. If a name is given, implementations MUST consider the link
relation type equivalent to the same name registered within the IANA
Registry of Link Relations (Section 7), and thus to the IRI that
would be obtained by appending the value of the rel attribute to the
string "http://www.iana.org/assignments/relation/";. The value of
"rel" describes the meaning of the link, but does not impose any
behavioral requirements on Atom Processors.
]] http://www.atompub.org/rfc4287.html#rfc.section.4.2.7.2
In practice people seem to want to use one-word link relations even
when they are coming up with their own.
Yes. My guess is that this is because
1. They probably don't think of the issue of name clashes
2. There is no shorthand way of saying something like iana:alternate
3. There is no behavior associated with the name
If the relation pointed to a document that could have some behavioral
impact on the browser with the user could adjust by doing something
at the url of the relation, then there would be an immediate
understanding of the value of using URIs.
I would recommend you adopt that too. Perhaps you can even adopt
the iana name space. If we could get them to put the appropriate
rdf document at that location, people who created/coined new link
relations could describe these relations as being superproperties
or subroperties of relations the browser already knows, which
would allow the browser to partially interpret those.
Well, RDF is not viewed that favorably by the WHATWG. Also, the
barrier for entry for the IANA registration process is likely too
high. (It certainly is for MIME types.) As for using the same
namespace, the HTML5 definitions for the link types don't
necessarily match the Atom definitions.
I believe I have a good explanation for why people may have good
reasons to dislike RDF/XML.
see: http://blogs.sun.com/bblfish/entry/crystalizing_rdf
Recently, a WHATWG-managed registry for HTML5 rel values has been
discussed informally. The idea was that conformance checkers could
consult an online registry instead of only allowing a fixed list of
values or allowing everything. RDF is an overkill for this. Even
XMDP isn't the simplest thing that could possibly work. The
simplest thing that could possibly work is a GETtable text/plain;
charset=utf-8 resource at a well-known URI with one rel value per
LF-separated line.
Look at the Turtle notation for RDF. It is very simple to parse.
The advantage of using RDF is that it you don't have to re-invent a
semantics. Even if simple it would be helpful to help people get
familiar with the technology.
Henry
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
