Re: Exact wording for non-prefixed CURIEs in @rel/@rev

Hi Manu,

On 22/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> Mark Birbeck wrote:
> > Now...sorry to keep repeating the same point, but the issue has never
> > been about how to recognise the reserved values, but how to *ignore*
> > the non-recognised values. In your model a value of "foo" will be
> > processed as a non-prefixed CURIE, and so generate a triple.
>
> That's fine - it's a valid point. :)

And unfortunately, it's the tricky one. :)


> I don't know what is in the current editors draft, but from what Shane
> wrote, he had the following two lines in his text:
>
> # the mapping to use when there is no prefix is the URL for the XHTML
>   vocabulary definition, http://www.w3.org/1999/xhtml/vocab#;
> # a mapping to use when there is no prefix (for example, next);
>
> I don't think we should have a "mapping" to use when there is no prefix.
> The two lines above should be removed from the document. Having a prefix
> mapping for non-prefixed CURIEs assumes that all non-prefixed CURIEs are
> valid and have a mapping (which is not true).

But the problem is that you are only looking at @rel. Unprefixed
CURIEs could be made to be perfectly valid in other attributes, for
example, if the unprefixed context is set to be the current default
namespace, then this would work fine:

  <div about="[blah]" xmlns="http://xyz"


> Only non-prefixed CURIEs defined in the XHTML+RDFa spec are allowed, all
> others will not generate namespaced predicates, thus MUST NOT generate
> triples.

As I say, that's only because you are looking at @rel.


> Current issues with this proposal:
>    * Shane mentioned that these same rules should apply to @property.
>      Was that what the consensus was? I think it should, for
>      consistency.

We could, but I don't see that there is a _requirement_ to. The whole
reason I tried to break apart the 'legacy question' from the general
behaviour was so that we could isolate the only place where we have a
problem, which is @rel/@rev; we don't have a problem with unprefixed
CURIEs in @about, @property, @datatype, or @resource.


>    * Shane also mentioned that we don't use the term "namespace" when
>      talking about prefix-mappings, but if we get rid of the "no prefix"
>      mapping, what do we call it? I'm going to continue calling it a
>      namespace until there is a suitable replacement (that isn't
>      "mapping")

I don't quite follow this. We specifically called the whole thing
'mappings' so that we could open up the possibility of using other
ways of creating 'mappings' that didn't use @xmlns.

But anyway, we don't need to remove the 'no prefix' mapping as such;
it might be better to leave it in, and say that such values are
ignored. The 'in progress' text that I have in the document at the
moment (that Shane referred to), actually does have that text already:

<quote>
 To evaluate CURIEs during processing the following context needs to
  be set:

  * a set of mappings from prefixes to URIs;
  * a mapping to use with the default prefix (for example, ":p");
  * a mapping to use when there is no prefix (for example, "p");
  * a mapping to use with the '_' prefix, which is used to generate
    unique identifiers (for   example, "_:p").

These values are defined in RDFa as follows:

  * the set of mappings from prefixes to URIs is provided by the current
    in-scope namespace declarations of the [current element] during
    parsing;
  * the mapping to use with the default prefix is the URL for the XHTML
    vocabulary definition, http://www.w3.org/1999/xhtml/vocab#;
  * the mapping to use when there is no prefix is not defined. This means
    that all uses of existing XHTML values, such as 'next' and 'previous'
    will not generate triples in the default graph;
  * the mapping to use with the '_' prefix, is not explicitly stated, but since
    it is used to generate [bnode]s, it needs to be compatible with the RDF
    definition.
</quote>

This was part of the 'package' that would fulfill the preprocessing
position that was discussed a while back; the idea was to ignore *all*
non-prefixed values, and then rely on the preprocessor to 'prefix' the
unprefixed values that you wanted to keep...thus saving them from
being ignored...if you see what I mean. :)

This means that you don't need to put any specific text elsewhere
about what to process and what to ignore, since we're saying that
there are no longer _any_ prefixed CURIEs. (Which, as I say, requires
that some other process 'saves' the important values from being
ignored, by prefixing them.)


>    * Mark, Shane, does getting rid of the "no prefix" mapping screw
>      anything else up?

Well, I went for it before, and that's why it's in the current
document. But I really I don't like it. :(

In my view it is the tail wagging the dog -- we only have a problem
with @rel, yet to solve it we're changing CURIEs completely. I happen
to think that having CURIEs based on the current default namespace
could be quite useful.

...but then, we've also got lives to lead. :) So I accepted that
compromise ages ago, as part of the 'deferral approach' that we had
before.


>    * If we put these rules in there, should we get rid of the colon-only
>      CURIE form (ie... ":next")?

You mean get rid of CURIEs altogether? ;)

We have to be careful that we don't simply hack away at the CURIE
syntax until @rel works, only to find that we've created problems
elsewhere. Remember, the only attributes that have this problem are
@rel and @rev. (@name could have this problem, but all we have to do
to solve that is simply say that @name stays unchanged, and you need
to use @property if you want to use CURIEs.)

Anyway, I don't see why we'd want -- or need -- to remove ":blah". And
actually, thinking about it, we could change the mapping for the empty
prefix to be the current default mapping rather than XHTML-vocab,
which would fulfill my use-cases:

  <div about="[:blah]" xmlns="http://xyz">


> Here's the second attempt, changes highlighted in **

Great.


> [...]
>
> Thoughts?

I think it could work. But I'm feeling that a more compact solution
would be possible, by simply removing unprefixed CURIEs altogether,
and then ensuring that valid unprefixed values get prefixed.

How about that? We simply modify the introductory part of the CURIE
section to say that unprefixed CURIEs are ignored (which we have
already, but it's not published) and then in some other suitable spot
we just say that "license" => "xh:license", "next" => "xh:next", and
so on.

And we might as well change the empty prefix from XHTML-vocab (since
no-one needs to write ":next" anymore) to the current default mapping.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 22 January 2008 21:28:44 UTC