Re: Property copying final issues

On Tue, Jan 29, 2013 at 9:36 PM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> We're almost done with the conversation on property copying, but I don't think we've quite converged yet.
>
> The current draft of the spec has the following rules:
>
> Rule: pattern-copy
>   ?subject rdfa:copy ?target . ?target a rdfa:Pattern; ?predicate ?object
>   =>
>   ?subject ?predicate ?object .
>   except -- ?predicate = rdf:type and ?object = rdfa:Pattern.
>
> Rule: clean-copy:
>  ?subject rdfa:copy ?target => remove ?subject rdfa:copy ?target
>
> Rule: clean-pattern:
>   ?subject a rdfa:Pattern; ?predicate ?object => remove ?subject ?predicate ?object
>
> There are several problems with this that the original statement had addressed:
>
> * The pattern-copy uses a form of pattern not used in any other specs, whereas the original closely followed the rule language in RDFS.

I agree that it would be better to use an existing form for these rules.

> * The clean-copy rule removes every use of rdfa:copy, not just those which actually reference a defined pattern.
>
> * The clean-pattern rule removes all patterns, even if they're not referenced.
>
> It may be that these rules are easier to understand than the originals, but they mean different things; we should be clear on what we want the semantics to be.
>
> Should we remove every use of rdfa:copy, even if it doesn't reference a pattern? I think this may be a problem if we do.
>
> Should we remove every pattern, even if it is not referenced? This could be a problem, but I could imaging using a "library" of patterns which may or may not be used by a specific document, and not wanting the patterns to survive.

Yes, I can see some value in keeping parts which have not fully
satisfied the requirements for a copy to occur (i.e. a rdfa:copy
reference to an explicitly typed rdfa:Pattern). If for nothing else,
to indicate that there seem to be intent to use patterns but that
something is missing.

Though I might also be ok even with making the entire removal step an
active choice for the consumer; i.e. control it with a flag. There is
little information in preserving an incorporated pattern using this
semantics (which is explicitly defined for this behavior), but some
might want to keep it for various reasons.

By the way, this mechanism is applied before any (optional) vocabulary
expansion, correct? I think that's important, to avoid any strange
inferred patterns or such.

> I think we need to finally resolve these issues, and have some final rules in place before we can agree to publish.

Another thing we're waiting for is feedback from the requesters of
this feature...

Does this mean that we will miss the LC deadline? What does that mean
in calendar time? I was hoping these things could be tweaked somewhat
(since the feature is marked as at risk), but I may have been to eager
in going forward.

Cheers,
Niklas

> Gregg Kellogg
> gregg@greggkellogg.net
>
>

Received on Tuesday, 29 January 2013 22:13:17 UTC