RDFa DOM API input from non-RDF person

A short conversation between one of our Javascript/web engineers, who
has only a passing interest in RDF/RDFa. I had mentioned that RDFa DOM
API is shaping up, he asked for the link some time ago and started
randomly reading it today. Here's the conversation:

--------------------------------------------------------------------
[Fri 16:26] <dlehn> manu: rdfa dom api doc, 3.3.2 'get' description
looks wrong
[Fri 16:32] <manu> what's wrong with it?
[Fri 16:32] <manu> (I think I know, but I want to make sure what I think
is wrong is what you think is wrong)
[Fri 16:39] <dlehn> i know what it's trying to say, it just doesn't say
it. missing the words that say you are getting a sequence of values from
the projection for a property IRI that's equiv to name.
[Fri 17:00] <manu> got it
[Fri 17:00] <manu> thx
[Fri 17:10] <dlehn> the mapping api seems kind of odd. isn't there a
concern about conflicts with rdfa api names?
[Fri 17:11] <manu> fixed.
[Fri 17:11] <manu> mapping API conflicts - conflicts will lead to
programs failing, they won't last long.
[Fri 17:11] <manu> that's the theory, anyway.
[Fri 17:14] <dlehn> i figured that was the theory. doesn't seem very
future proof though. ie, api additions could conflict with deployed code.
[Fri 17:17] <manu> the api is supposed to stay very, very small
[Fri 17:17] <manu> likelyhood that there will be 3-4 character methods
on rdfa is very tiny.
[Fri 17:23] <dlehn> might be something to add a note about in 4.2.
mention it is using the same namespace as the api names so don't use
those or BOOM!
[Fri 17:25] <dlehn> also, in 4.2, is the 'set' description missing a
'value' parameter? it's refered to in the 'set' doc but is not in the
parameter list
[Fri 17:27] <manu> <p>IRI mappings are placed into the same namespace as
the RDFa API functions.
[Fri 17:27] <manu> Implementers must ensure that the RDFa API functions
are protected from being
[Fri 17:27] <manu> overwritten. If a RDFa API mapping is requested that
would overwrite a
[Fri 17:27] <manu> function name, the mapping must not be created.</p>
[Fri 17:30] <dlehn> no "BOOM!" text? i'm dissapointed.
[Fri 17:30] <manu> <p>IRI mappings are placed into the same namespace as
the RDFa API functions.
[Fri 17:30] <manu> Implementers must ensure that the RDFa API functions
are protected from being
[Fri 17:30] <manu> overwritten. If a RDFa API mapping is requested that
would overwrite a
[Fri 17:30] <manu> function name, the mapping must not be created. BOOM
MOTHERF#*(&ER!</p>
[Fri 17:30] <manu> how's that?
[Fri 17:31] <dlehn> perfect
[Fri 17:34] <dlehn> 4.4.3 and 4.5.2 have a tab in the examples code that
makes it look odd
[Fri 17:37] <dlehn> rdfa_dom_api.js has some space vs tab formatting
issues too. if that matters.
[Fri 17:38] <dlehn> the JSDoc API link is busted too
[Fri 17:39] <manu> replaced all tabs with two spaces
[Fri 17:39] <manu> there were /lots/ of tabs.
[Fri 17:39] <manu> We need to remove JSDoc API link
[Fri 17:44] <manu> JSDoc API link removed
[Fri 17:44] * manu thinks that both dlehn and he should be doing other
things rather than reviewing/editing this document.
[Fri 17:50] <manu> So, what do you think about the RDFa DOM API?
[Fri 18:00] <dlehn> ok i suppose. i'm not exactly sure what is needed,
so hard to say.
[Fri 18:00] <manu> Do you think you would have a hard time using it to
get data out of a web page?
[Fri 18:03] <dlehn> well... to get the low level data? not a problem. to
figure out how to process data you get is more difficult i imagine.
[Fri 18:03] <manu> how so?
[Fri 18:04] <manu> do you have an example?
[Fri 18:04] <dlehn> is the plan that people will use this on their own
pages or that things like firefox extensions could use it to process rdf
on every page you visit?
[Fri 18:04] <manu> both
[Fri 18:06] <dlehn> are things like sparql out of scope for this?
queries do seem easier to do with such languages.
[Fri 18:07] <manu> yes, sparql is out of scope. The idea is that people
could use the RDFa DOM API to build a SPARQL library.
[Fri 18:11] <dlehn> i haven't dealt with rdf enough to give useful feedback.
[Fri 18:12] <manu> If I asked you to get this subject from the page,
what would you do: "http://example.org/dave" ?
[Fri 18:14] <dlehn> rdfa.project("http://example.org/dave")
[Fri 18:15] <dlehn> err.. throw a new IRI() in there
[Fri 18:18] <dlehn> do you need to describe how to handle things like
the dom being manipulated while you are using a query result?
[Fri 18:19] <manu> yeah, probably.
[Fri 18:19] <manu> what would you expect to happen?
[Fri 18:19] <manu> if the DOM changes after you do an rdfa.project()?
[Fri 18:19] <dlehn> BOOM!
[Fri 18:19] <manu> could you be a bit less... uhh... terse.
[Fri 18:20] <dlehn> same problem for project/filter/iterate
[Fri 18:20] <manu> which is?
[Fri 18:21] <dlehn> DOM additions, removals, and modifications could all
effect the result set you are looking at
[Fri 18:22] <manu> would you expect the triples to disappear, or would
you expect the elements that they refer to to disappear? or something else?
[Fri 18:22] <manu> like, what would you expect to happen to that
rdfa.project() object?
[Fri 18:23] <manu> also, how would you retrieve all subjects that have
"http://xmlns.com/foaf/0.1/name" as a property?
[Fri 18:26] <dlehn> for project/filter i suppose i'd expect it to return
the results that existed at the point i called it. for iterate, i'm not
sure since the point is that implemntations don't have to collect all
results at once.
[Fri 18:37] <dlehn> rdfa.filter(null, rdfa.foaf.name, null, null, null),
then loop over results getting .subject. or forEach and use the func param.
[Fri 18:38] <dlehn> speaking of, filter() doesn't specify what null
means for element and filter params
[Fri 18:39] <dlehn> i guessed null element means whole doc, null filter
means accept everything

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Saturday, 1 May 2010 04:59:34 UTC