ISSUE-29: Proposal to resolve DOM origin generalization

On 08/09/2010 12:17 AM, Manu Sporny wrote:
> 3) ISSUE-29: DOM origin generalization (on Manu)
>    http://www.w3.org/2010/02/rdfa/track/issues/29
>
> We need to re-think how .origin is exposed via the RDFa API as well
> as what it means for a triple to have an origin. .origin also doesn't
> make sense if the RDFa API is not implemented in a DOM environment.

In a previous spec, the .origin property was specified for the subject,
predicate, and object for a triple. This had three problems:

1. .origin didn't make sense in a non-DOM environment.
2. Just specifying the .origin wasn't very flexible when it came to
   carrying other data that may be important to developers.
3. The name "origin" could be confused with the Origin property in
   HTTP.

This resulted in several changes to the editors draft spec:

1. .origin was renamed to .source and placed in a dictionary called
   .info for each subject, predicate and object in a triple.
2. .source was optional, so non-DOM environments would still be able
   to be compliant with the RDFa API.
3. .info could be used to carry any arbitrary developer information.
4. .source would not be easily confused with other DOM/HTTP concepts.

Both Ivan and Nathan raised concerns that comparing triples would cause
confusion because of the .info property on each subject, predicate,
object in a triple. Toby mentioned that adding the .info property to the
triple would solve that issue. Ivan and Nathan stated that it would
still make triple-to-triple comparison difficult.

I had mentioned that we can state that default comparisons should ignore
the .info property altogether unless the developer specifically overrode
the comparison operator to take the .info property into account.

Mark suggested removing the .info property from subjects, predicates,
objects and triples and migrating it to the Property Group object. This
way, comparison wouldn't be affected and the developer could specify
whether or not they wanted to retrieve the DOM node associated with a
particular part of a Property Group. I forgot that we had already done
this, but hadn't explained how the .info gets populated and what type of
information it can store. However, we may want to remove .info entirely
and replace it with a method and leave the implementation of how to
track .info up to developers. More on this below...

Mark also mentioned modifying the Data Query interface such that a
developer could specify whether or not they wanted to include DOM
information or not. This is the current select() interface on DataQuery:

   Sequence<PropertyGroup> select (in Object? query,
                                   in optional Object template);

We would change that interface to this:

   Sequence<PropertyGroup> select (in Object? query,
                                   in optional Object template,
                                   in optional array options);

'options' could be an array of string options that should be used to
build the resulting Property Groups when performing a query.

So, a query might look like the following:

pgs = query.select(..., ..., ["source",]);

would return an array of property groups that include the source
information for the PG and all properties of the PG. We would have to
extend the PropertyGroup interface by adding one of the two following
methods:

    Sequence<any> source (in string predicate);

OR

    Sequence<any> info (in optional string predicate,
                        in optional string name);

I'm leaning toward the latter because it allows the developer more
flexibility in having many more informational items associated with a
PropertyGroup. For example, with the latter all of these are possible:

// get the Property Group's subject declaration elements:
subjectElements = pg.info(None, "source");

// get the object declaration elements for all "foaf:name" properties
objectElements = pg.info("foaf:name", "source");

One drawback to this approach is that you don't know where predicate's
sources are, but I couldn't think of a use case where you'd care as most
predicates are found in @rel/@property/@typeof properties and I couldn't
think of a case where you'd want to retrieve those.

I guess we could do something like this:

subjectElements = pg.info("foaf:name", "subjectSource");
predicateElements = pg.info("foaf:name", "predicateSource");
objectElements = pg.info("foaf:name", "objectSource");

A non-DOM-based RDFa API would return an empty array for each of these
queries, which would be fine.

Now, as far as implementations go, I'd expect that each subject,
predicate, object of a triple would store the source element (which is
exactly what the current draft text states). So, Ivan, Nathan and Toby's
concerns are still there because developers may not know that we intend
that comparisons should be done with only the raw triple data, excluding
source. So we will have to state something about doing comparisons
between core RDF types.

This is all preliminary of course and is open to debate and general
discussion. I haven't spent a great deal of time thinking through every
detail of this proposal, so there may be holes in it or someone may have
a different approach that we haven't heard about yet. Thoughts?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: WebID - Universal Login for the Web
http://blog.digitalbazaar.com/2010/08/07/webid/2/

Received on Thursday, 12 August 2010 03:15:10 UTC