Re: ISSUE-29: Re: When is equal and when is it nonequal (eg, the IRI interface)

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