Hi Breton,
On Apr 12, 2006, at 6:50 PM, Breton Slivka wrote:
Ack, has it really been a month? Sorry, things got busy...
= The Problem =
perhaps a couple of examples of what would amount to extrinsic
metadata wouldn't be too far afield, and serve to sharpen the focus
of the problem a bit more.
Great idea! Added:
http://microformats.org/wiki/rest/property#The_Problem
I am in the process of trying to determine how much of this is
already accounted for, and dealt with in the RDF specification. I
can't say I fully understand RDF, but a lot of this is sounding
familiar from when I tried to understand it . From what I
understand, there are already mechanisms to link to RDF
descriptions from inside an HTML page. I think there might be URL
schemes for RDF properties already worked out as well. I'm not sure
though. Since we're talking about metadata, there needs to be some
form of metadata format we're dealing with. Perhaps it's RDF, or
some theoretical mf style equivalent (such as xmdp).
The part that I haven't seen is an *implementation* where
properties become readable/writable from within a simple URI schema.
Interesting. I think the challenge with RDF historically is *not* so
much its _lack_ of sufficiently powerful functionality, but more the
"embarrassment of riches." The goal of relProperty is to do
something that is:
a) brain-dead simple
b) trivially insert-able in vanilla, validate-able HTML
c) easily accessed/updated via standard HTTP methods
I made a note about that on the wiki:
http://microformats.org/wiki/rest/property#relProperty
It is conventional, but not mandatory, to use a semicolon (";") as
the first character of each property. This follows the convention
used in, e.g. [http://www.macromedia.com/cfusion/knowledgebase/
index.cfm?id=1c6b723 ColdFusion], and eases human-readability.
Are you talking about listing each property seperately in their own
link statement? Or a link to a file describing the URI schema in
use for the properties of that page?
The former, I think; otherwise, it becomes difficult to "identify
each individually update-able resource with its own URI." Clarified
at: http://microformats.org/wiki/rest/property#
= Open Issues =
* Can properties be chained together? If so, are they retrieved in
parallel, or would those be subproperties?
* Would we need to worry about [http://lists.evolt.org/archive/
Week-of-Mon-20020114/065707.html semicolon exploits]?
* Are there other conventions we should follow/avoid?
* Should the "Link:" tag itself be declared in HTTP "OPTIONS"?
issue 1: It depends on whether our metadata is going to be flat
or heirarchical I suppose. if it's the latter, semicolon may not be
the best choice for use in a URL schema, as it presents a number of
technical problems.
Well, I would recommend flat, at least to start with. However, I'm
not clear why ";" creates hierarchy problems? My gut-level
interpretation would be:
;prop1;prop2 are chained properties
;prop1/subprop1 is a "hierarchical" property
That is, we just reuse the existing HTML hierarchy separator. What
would be the problem with that?
Issue 2: Problems like this can be avoided through simple
precautions and good programming practice. if necessary, guidelines
for URL parsing could be drafted. The thing to avoid is using
unfiltered URL text directly as an SQL query. It is untrustworthy
data. Numerous functions exist to deal with this sort of thing
already. Security problems happen when coders don't know this, or
are too lazy to use them.
Issue 3: As mentioned above, it would probably be a good idea to
see how much overlap there is in RDF in dealing in this problem space.
Captured here:
http://microformats.org/wiki/rest/property#Open_Issues
Random Brainstorm: Since we're talking about giving URI's to
extrinsic metadata, is it crazy to think it would be useful to
create URI's for intrinsic /data/? That is to say, a server
provided way to deal directly with microformats. A little off topic
yes, but here's what I'm thinking:
Say for example this URI contains several hcards http://
www.example.org/contactpage
It's possible to then provide a server switch to automatically turn
this page into rest service:
GET http://www.example.org/contactpage/hcard/01;fn //
retrieve fn prop from first hcard
GET http://www.example.org/contactpage/hcard/02/adr;locality //
retrieve a subproperty from second hcard.
POST http://www.example.org/contactpage/hcard/new //
post url encoded properties to build a new hcard and place on
contactpage.
just as an example. but I think it's an idea with some potential,
even if it's a far off pipe dream.
Well, I worry that we're really treading into the space of HTML
anchors. I would think a more appropriate/general service might be
something called "server side fragments", where a client somehow
tells the server it wants it to *extract* that fragment, instead of
(merely) jumping to it client side.
We could, I suppose, hypothesize appropriate syntaxes for it. I'd
vote for "?#", as in "query fragment":
Client-side: http://www.example.org/contactpage#hcard
Server-side: http://www.example.org/contactpage?#hard
But, that would be innovating in a vacuum. Best to let someone
(you?) try to implement it first and see how it actually works, then
document it here later. :-)
Thanks for all the feedback!
-- Ernie P.
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
