- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 05 Aug 2010 09:02:26 -0400
- To: W3C RDFa WG <public-rdfa-wg@w3.org>
On 08/02/2010 11:28 PM, Nathan wrote: > Manu Sporny wrote: >> On 08/01/2010 10:20 PM, Nathan wrote: >>> Now - apologies in advance for this... >>> >>> What's the use-case for having the origin/source? >> >> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-api-20100801/#the-source-pointer > > I follow and see the need :) - questions and notes: > > 1: note that given: > var ivan = document.getItemBySubject("http://www.ivan-herman.net/foaf#me"); > var val = ivan.get("foaf:name"); > > then 'val' won't have any way to get back to the DOMNode to do anything > with it if you move the source property to the triple. Right, which is why we had placed the 'info' object on the "atomic" RDF classes. We could place a "parent" property on PlainLiteral, TypedLiteral: plainLiteral.parent.info.objectSource but that doesn't seem very elegant. > side point: am I to assume that a subject can only appear once in the > subject position in a document - getItemBySubject() seems to infer this > whereas with my limited RDFa knowledge I'd assumed that I could have > several elements all @about the same thing - used 'ass'ume because I may > be making an ass of myself with this aside! No, it's a very valid question - I don't think we've answered that in the document yet. My assumption, and I use 'ass' in the same manner that you do, was to allow the subject.info.source to point to different parts of the document. .source was meant to be a very low-level mechanism to access the DOM. You can have @about refer to the same subject in multiple places in the DOM - I thought that we would want to have that translate directly into the data model, so that you could determine every single instance of @about re: the same subject in the DOM. The other issue that having .source for subjects that point to the first time @about was specified for a subject creates is that the RDFa Processor would have to track when the first instance of a particular subject was created via @about or @typeof and track that DOM element in the RDFa Processor. It would be an added burden without a clear benefit - complicating the RDFa Processor more than it is at present. > 2: I was genuinely surprised when I saw the definition of > getElementsByProperty(property,value), and that value is not optional - > I perhaps foolishly assumed that I would be able to simply specify the > property/predicate only. hmm, interesting. I thought we had that in there. Seems to be a good idea. Any objections to allowing value to be optional? If we put this feature in there, it would allow people to just specify a property and get back all triples with that particular property. > 3: Would a simple method on the document to return elements by filtering > not suffice > document.getElementsByFilter( subject, predicate, object ); > where each param is optional and where at least one is required. This method is on DataStore: document.data.store.filter( subject, predicate, object, ... ); Would that address this use caes? > document.getElementByTriple( RDFTriple triple ); > again where 1 or more properties of the triple would need to be set. You can specify a RDFTripleFilter to DataStore.filter(): http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/#widl-DataStore-filter Does that address your use case, or are you stating that you would like to see this method exposed on the Document interface? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: WebApp Security - A jQuery Javascript-native SSL/TLS library http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/ http://blog.digitalbazaar.com/2010/07/20/javascript-tls-2/
Received on Thursday, 5 August 2010 13:02:57 UTC