Re: RDFa API thoughts

On 04/02/2011 07:51 PM, Nathan wrote:
> I've went through the RDFa API document and spent the last few hours

Looks like a good set of enhancements.

> interface RDFaDocument {
> 
> readonly attribute DocumentData data;
> 
> NodeList   getElementsByType(in DOMString type); NodeList
> getElementsBySubject(in DOMString subject); NodeList
> getElementsByProperty(in DOMString? property, in optional DOMString?
> value);
> 
> };

+1

> interface DocumentData {
> 
> attribute RDFEnvironment? rdf;
> 
> sequence<DOMString>   getSubjects() sequence<DOMString>
> getSubjects( in DOMString? property, in optional DOMString? value ) 
> sequence<DOMString>   getProperties( in optional DOMString? subject
> ) sequence<DOMString>   getValues( in DOMString? subject, in
> DOMString property )

+1

> Projection            getItem( in DOMString subject ) 
> sequence<Projection>  getItems() sequence<Projection>  getItems( in
> DOMString? property, in optional DOMString? value )

Gonna rename this to getProjection* - Microdata API uses getItems and
the more I think about it, the more I think that we should be talking
about "Projections" because they're a fairly new way of looking at this
RDF data. It may be /the/ way that we want to look at RDF data in the
future.... with only reasoning applications caring about the
datatype/language/etc.

> sequence<RDFTriple>   getTriples();

-1 - If people want to deal w/ triples, they can use the RDF API.

> - fleshed out the data.getSubjects and getProperties to be (dare I
> say) more useful, also added a complement getValues which could be v
> useful

Agreed.

> - dropped the 3 argument version of getItems*

Good, it took a great deal of convincing myself to take that direction.
It's more powerful, but harder for folks to grasp, IMHO. I like the
version above.

> - added a getTriples which returns an array of RDFTriples, I dare
> say this is needed and easy to implement without the full RDF API.

I don't think it's needed because the RDF API would provide this
functionality. We should try to stay away from triples as much as
possible in the RDFa API. We may not be able to do it in the end, but we
should focus on a simpler data model that is easier for JavaScript
developers to understand.

> - added getElementsByType back in, it seems v useful for DOM-devs
> (not so for those working with the data and easy replicable w/
> getItems).

Sure - like this approach better than the one proposed yesterday.

> I can't for the life of me give any strong thoughts wrt .query, 
> generally it makes me uncomfortable and there are just so many
> possible approaches that I don't feel comfortable (personally) trying
> to define a single one as being the primary query mechanism for
> RDFa.

Whether or not we feel comfortable doing this, we are the group that is
responsible for creating /something/ that provides this functionality. I
know there are lots of ways of doing querying over this data, but we
need to pick one. After talking w/ Mark and Benjamin over the past year,
this seems to be the version that is winning out over everything else.

> BlankNode identifiers are worrying me a little.. - what does
> projection.getSubject return for a BlankNode?

It returns the blank node identifier assigned by the underlying
implementation, for example: "_:bnode1".

> - can I then use that on data.getItem or getElementsBySubject?

Yes (as long as the underlying data has not changed since the last
call). If it has, you're SOL.

> - are blank node identifiers in the document reliable, so they can
> be used in data.getItem and getElementsBySubject?

Yes, as long as new items haven't been added to the document since then.
It's not a perfect solution, but I think that it'll work for 95% of the
apps out there.

> The getElements* methods in general are worrying me.. - does
> @rev+@resource/@href set a subject that you can use to 
> getElementsBySubject (assume yes)?

yes, I think so.

> - are the methods fine to return back node lists which include head 
> elements?

Yes.

> - when the subject is set by the base, what is returned for 
> getElementsBySubject, the head, the doc, the?

Good question, I'd say the HEAD is returned instead of <base>.

> - will getElementsByProperty confuse people (namewise) since we have
> a @property but @rel also sets the property?

Probably at first yes. I don't think it'll cause devs to get thoroughly
confused, though.

> - chaining...! for example what would be returned for the method
> call document.getElementsByProperty("dbp-owl:residence") with this
> RDFa? <div about="http://dbpedia.org/resource/Albert_Einstein" 
> rel="dbp-owl:residence"> <span
> about="http://dbpedia.org/resource/German_Empire"></span> <span
> about="http://dbpedia.org/resource/Switzerland"></span> </div>

The <div> would be returned.

> and this RDFa? <div
> about="http://dbpedia.org/resource/Albert_Einstein"> <span
> rel="dbp-owl:residence" 
> resource="http://dbpedia.org/resource/German_Empire"></span> <span
> rel="dbp-owl:residence" 
> resource="http://dbpedia.org/resource/Switzerland"></span> </div>

The spans would be returned.

> and this RDFa? <div
> about="http://dbpedia.org/resource/Albert_Einstein" 
> rel="dbp-owl:residence"> <span
> resource="http://dbpedia.org/resource/German_Empire"></span> <span
> rel="dbp-owl:residence" 
> resource="http://dbpedia.org/resource/Switzerland"></span> </div>

The div and the last span would be returned.

> CURIE/Term Maps: Is the RDFa API internal map pre-populated w/
> prefixes and terms defined in the doc?

No - there MUST NOT be any sort of pre-population of RDFa prefixes based
on the contents of the document in the RDFa API. The mapping set via the
.setMapping() call is for application developers only. That also means
that library writers that use the RDFa API MUST NOT modify the mappings
w/ .setMapping() unless they're careful to reset it to its previous
state after using the call.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Payment Standards and Competition
http://digitalbazaar.com/2011/02/28/payment-standards/

Received on Sunday, 3 April 2011 17:40:36 UTC