Re: Updates to HTML+RDFa 1.1 (ISSUE-144)

> Manu,
> 
> (I do not want to dive into the issue of naming right now.)
> 
> - I understand that one may want to copy properties that are not necessarily removed from the graph. However, I believe that there _are_ cases when one wants exactly that, ie, use a bunch of attributes just to be copied and not appearing in the graph per se, eg, because it does not really make sense. I am afraid that by doing the changes you propose we, sort of, fall into the other extreme.

I agree.

> Also, because that was also a motivation for us, wouldn't the current structure deviate from microdata? In the microdata->RDF conversion the 'referred' portion never generates triples per se, only as part of an @itemref. We should not introduce incompatibilities if we can avoid them.
> 
> Also, by using an explicit rdfa:Prototype, the user is forced to think twice before using this feature. Which is actually a good thing, because I am a bit concerned that, otherwise, unexpected things might occur... (although I admit I do not have an example in mind, it is just a gut feeling).

Actually, I think a streaming processor needs rdfa:Prototype, and further more needs it to be specified with @typeof on the containing element and/or the first element which introduces the subject. Without specifying rdfa:Prototype, a streaming processor could only do the include (or reference) if the prototype comes later in the document than the reference, which might not be the case. Further more, it's possible to include interdependent references (nothing to prevent it) in which order cannot be guaranteed anyway.

The way I think this needs to work in a streaming processor is something like the following:

1. Remember any subject and object with an rdfa:include (or rdfa:ref) property and do not emit this triple.

2. Remember any subject and all properties of type rdfa:Prototype, and do not emit such triples.

3. After processing is complete, add all properties from referenced prototypes that were found during processing (other than rdfa:Prototype). If no such reference is found, emit the rdfa:include triple. If an rdfa:Prototype is defined but not referenced (included), emit all triples defined against it.

Probably a couple of other steps for recursive prototype inclusions.

It does require some memory, but it should be pretty small for most reasonable uses of rdfa:include/ref. I don't think you can really do it any other way without requiring that all references be forward-references.

> I see the following possibilities:
> 
> 1. The structure you propose, which means that the user has no way of specifying a 'macro' without adding extra (and unwanted) RDF triples into the output
> 2. The previous structure, whereby the user will _not_ get the triples in a 'macro' (or prototype) in the final RDF graph
> 3. Something slightly more complicated, where we define two classes, rdfa:Prototype and (do not take the name seriously) rdfa:VisiblePrototype. Both behave similarly as for unfolding the macro; the former does not generate extra triples, whereas the latter does. (The rules to implement these are obvious, we had them already.)
> 
> At this moment, I am not happy with #1, and I tend to favour #2 or #3.

I'm -0.5 on 1), +1 on 2), and -0.5 on 3).

> - The current text includes the note:
> 
> [[[
> Some RDFa processors may not be able to operate on the output graph and are thus not required to implement the Property Copying feature. Alternate rules may be used to update the output graph as long as the end result is the same. RDFa processors may incorporate Property Copying as a part of RDFa Vocabulary Expansion.
> ]]]
> 
> Does it mean that the whole copying features becomes a non-required feature? This was not the way we described it before. Or does the note simply says that implementation may choose other types of implementation for this feature, and the rules are just there as illustrative examples for a (valid) way of implementing them?
> 
> I think that making this feature not-required may be a mistake. I would rather propose to make it a required feature, but add in the at-risk note that making it non-required might be a possibility if the community advises to do so.

I agree that to be useful, this feature must be required, otherwise it's fairly useless to developers.

Gregg

> - Also on the previous note: I think the reference to the RDFa Vocabulary Expansion is unnecessary. It just blurs things...
> 
> Ivan
> 
> 
> 
> 
> On Jan 7, 2013, at 03:14 , Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
>> Hi folks,
>> 
>> Gregg and I discussed the Reference Folding feature a bit today and then
>> I went through and "refined" the text a bit. Readers will have to let us
>> know if it is an improvement or not.
>> 
>> http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/Overview-src.html
>> 
>> High-level changes:
>> 
>> 1. Renamed the feature from "Reference Folding" to "Property Copying".
>> 2. Got rid of "rdfa:Prototype" as you may want to copy properties from
>>  something that isn't an rdfa:Prototype.
>> 3. Changed "rdfa:ref" to "rdfa:include".
>> 4. Removed the pass that removes the "prototype" features, as that may
>>  not be what the author always wants to do. For example, if you have
>>  a base model for something like a car, you don't want to delete
>>  it from the data as the knowledge of what the base model is can be
>>  useful.
>> 5. Based on feedback from Bruce Lawson of Opera, I changed the first
>>  example to be a little more accessible.
>> 6. I removed the use of bnodes in the examples because bnodes scare
>>  people.
>> 
>> Thoughts?
>> 
>> -- manu
>> 
>> -- 
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Problem with RDF and Nuclear Power
>> http://manu.sporny.org/2012/nuclear-rdf/
>> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Monday, 7 January 2013 17:58:27 UTC