Proposal for 'URIs everywhere'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for 'URIs everywhere'

Mark Birbeck-4
Hello all,

I'd hoped to get the following proposal to the group at the beginning
of the week, but it wasn't possible.

Anyway, below you'll find a series of minor changes that I feel would
need to be made to various parts of the syntax document, in order to
support URIs and CURIEs in all RDFa-related attributes (except @src
and @href).

To recap, whilst most of our attributes support URIs and CURIEs
already, @property, @rel and @rev only supported URIs. This means that
authors must declare prefix mappings for all predicates, even though
they are not required to use prefix mappings for subjects or objects.
We've agreed to try to address this, and I had an action item to come
up with some proposed text.


APPROACH

The first step in sorting this out, is to remove the separation where
in some places we allow a CURIE, and in others we allow a
URIorSafeCURIE.

Both situations will now use the same type, which I've called
'URIorCURIE'. (This type did used to exist in previous drafts, but I
think that's ok. Of course, if anyone can spot a reason why we should
use a different name, then please mention it.)

After making the data type consistent throughout, we then need to
clarify the processing rules.

And finally, we need to add one or more examples of using a full URI
for a predicate.


DATATYPE

The datatype changes affect section 2.1, as follows:

1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
with 'URIorCURIE'.
2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.

Also, in section 5.4.4, the bullet-points listing the attributes
should change to this:

  * @about, @datatype, @property, @resource and @typeof support either a URI or
    a CURIE.
  * @href and @src support only a URI.
  * @rel and @rev support XHTML link types, URIs and CURIEs.


PROCESSING

In section 5.4.2, after the three steps, but before the note, we should add:

  Note that this algorithm assumes that its input is a CURIE, but in practice it
  won't be possible to definitively establish this until step 2; if
there is no in-scope
  mapping that matches the prefix, then the algorithm should terminate, and the
  input regarded as a URI.

In section 5.4.3, the first point should be removed, and in the second
point, the sentence:

  In this case any value that is not surrounded by square brackets, as defined
  by 'safe_curie' in the section CURIE Syntax Definition, will be
processed as if
  it was a URI.

should be changed to:

  In this case any value that is not a CURIE, as outlined in section 5.4.2, will
  be processed as a URI.

Note that I've left the prose about square brackets intact, because
there are probably use-cases where people want to say 'safe CURIE or
nothing'. (I.e., don't fall back to a URI if there is no prefix
mapping.)

In the sentence after the two (now one) sentences, we should change this:

  An example of an attribute that can contain CURIE and non-CURIE values is
  @about. As described, any CURIEs expressed in the attribute must follow the
  format of a [safe CURIE]. So to express a URI directly, an author
might do this:

to this:

  An example of an attribute that can contain a URIorCURIE is @about. To
  express a URI directly, an author might do this:

After the example, the next sentence/example combination can be
duplicated, to give us an extra example, like this:

  whilst to express a CURIE they could do this:

    <div about="dbr:Albert_Einstein">
      ...
    </div>

  The author could also use a safe CURIE, as follows:

    <div about="[dbr:Albert_Einstein]">
      ...
    </div>

In the next example, we just need to clarify that we're now only
referring to safe CURIEs; this:

  Since non-CURIE values MUST be ignored, ...

becomes this:

  Since non-CURIE values MUST be ignored when they appear in safe CURIEs, ...

In section 5.4.4, after the bullet-points, the entire sentence reading:

  Note that unlike @about and @resource, @rel and @rev do not
differentiate their two
  types of data by using [safe CURIE]s.

should be removed. The next sentence, which reads:

  Instead, any value that matches an entry in the list of link types
in the section
  The rel attribute, MUST be treated as if it was a URI within the
XHTML vocabulary,
  and all other values must be CURIEs.

should be changed to:

  Any value that matches an entry in the list of link types in the
section The rel
  attribute, MUST be treated as if it was a URI within the XHTML vocabulary. All
  other values will be processed as URIorCURIEs.

The next paragraph and its associated example, beginning:

  Note that only values in the link type list have this special behaviour, ...

can be deleted.

In the section 5.4.5, the example can have its square brackets removed.

In section 7, the sentence:

  Since it is difficult to distinguish between CURIEs and URIs, the CURIE
  syntax adds the notion of a [safe CURIE].

should be changed to:

  A URI that uses a scheme that is not an in-scope mapping cannot be
  confused with a CURIE. However, since there may be situations where
  authors would like to make it explicit that they are using a CURIE, the
  CURIE syntax adds the notion of a [safe CURIE].


EXAMPLES

At the end of section 2.2, we can add:

  When dealing with small amounts of mark-up, it is sometimes easier
to use full URIs,
  rather than CURIEs. The previous example can also be written as follows:

  <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title>Books by Marco Pierre White</title>
    </head>
    <body>
      I think White's book
      '<span
       about="urn:ISBN:0091808189"
       typeof="http://example.org/book"
       property="http://purl.org/dc/elements/1.1/title"
       >Canteen Cuisine</span>'
      is well worth getting since although it's quite advanced stuff, he
      makes it pretty easy to follow. You might also like
      <span
       about="urn:ISBN:1596913614"
       typeof="http://example.org/book"
       property="http://purl.org/dc/elements/1.1/description"
       >White's autobiography</span>.
    </body>
  </html>

Regards,

Mark

--
Mark Birbeck, webBackplane

[hidden email]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Julian Reschke
Hi,

here's a high-level comment without looking at the details.

I appreciate the attempt to make progress. As far as I can tell, the
change being proposed actually will not be backwards-compatible in all
cases (for instance, when changing from URIorSafeCURIE to URIorCURIE).
In which case you really should consider making a change that at least
avoids confusion and potential ambiguity, by making everything
URIorSafeCURIE. That would also align (as far as I recall) with the TAG
advice not to use CURIEs where they might be confused with URIs.

Best regards, Julian


Mark Birbeck wrote:

> Hello all,
>
> I'd hoped to get the following proposal to the group at the beginning
> of the week, but it wasn't possible.
>
> Anyway, below you'll find a series of minor changes that I feel would
> need to be made to various parts of the syntax document, in order to
> support URIs and CURIEs in all RDFa-related attributes (except @src
> and @href).
>
> To recap, whilst most of our attributes support URIs and CURIEs
> already, @property, @rel and @rev only supported URIs. This means that
> authors must declare prefix mappings for all predicates, even though
> they are not required to use prefix mappings for subjects or objects.
> We've agreed to try to address this, and I had an action item to come
> up with some proposed text.
>
>
> APPROACH
>
> The first step in sorting this out, is to remove the separation where
> in some places we allow a CURIE, and in others we allow a
> URIorSafeCURIE.
>
> Both situations will now use the same type, which I've called
> 'URIorCURIE'. (This type did used to exist in previous drafts, but I
> think that's ok. Of course, if anyone can spot a reason why we should
> use a different name, then please mention it.)
>
> After making the data type consistent throughout, we then need to
> clarify the processing rules.
>
> And finally, we need to add one or more examples of using a full URI
> for a predicate.
>
>
> DATATYPE
>
> The datatype changes affect section 2.1, as follows:
>
> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
> with 'URIorCURIE'.
> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.
>
> Also, in section 5.4.4, the bullet-points listing the attributes
> should change to this:
>
>   * @about, @datatype, @property, @resource and @typeof support either a URI or
>     a CURIE.
>   * @href and @src support only a URI.
>   * @rel and @rev support XHTML link types, URIs and CURIEs.
>
>
> PROCESSING
>
> In section 5.4.2, after the three steps, but before the note, we should add:
>
>   Note that this algorithm assumes that its input is a CURIE, but in practice it
>   won't be possible to definitively establish this until step 2; if
> there is no in-scope
>   mapping that matches the prefix, then the algorithm should terminate, and the
>   input regarded as a URI.
>
> In section 5.4.3, the first point should be removed, and in the second
> point, the sentence:
>
>   In this case any value that is not surrounded by square brackets, as defined
>   by 'safe_curie' in the section CURIE Syntax Definition, will be
> processed as if
>   it was a URI.
>
> should be changed to:
>
>   In this case any value that is not a CURIE, as outlined in section 5.4.2, will
>   be processed as a URI.
>
> Note that I've left the prose about square brackets intact, because
> there are probably use-cases where people want to say 'safe CURIE or
> nothing'. (I.e., don't fall back to a URI if there is no prefix
> mapping.)
>
> In the sentence after the two (now one) sentences, we should change this:
>
>   An example of an attribute that can contain CURIE and non-CURIE values is
>   @about. As described, any CURIEs expressed in the attribute must follow the
>   format of a [safe CURIE]. So to express a URI directly, an author
> might do this:
>
> to this:
>
>   An example of an attribute that can contain a URIorCURIE is @about. To
>   express a URI directly, an author might do this:
>
> After the example, the next sentence/example combination can be
> duplicated, to give us an extra example, like this:
>
>   whilst to express a CURIE they could do this:
>
>     <div about="dbr:Albert_Einstein">
>       ...
>     </div>
>
>   The author could also use a safe CURIE, as follows:
>
>     <div about="[dbr:Albert_Einstein]">
>       ...
>     </div>
>
> In the next example, we just need to clarify that we're now only
> referring to safe CURIEs; this:
>
>   Since non-CURIE values MUST be ignored, ...
>
> becomes this:
>
>   Since non-CURIE values MUST be ignored when they appear in safe CURIEs, ...
>
> In section 5.4.4, after the bullet-points, the entire sentence reading:
>
>   Note that unlike @about and @resource, @rel and @rev do not
> differentiate their two
>   types of data by using [safe CURIE]s.
>
> should be removed. The next sentence, which reads:
>
>   Instead, any value that matches an entry in the list of link types
> in the section
>   The rel attribute, MUST be treated as if it was a URI within the
> XHTML vocabulary,
>   and all other values must be CURIEs.
>
> should be changed to:
>
>   Any value that matches an entry in the list of link types in the
> section The rel
>   attribute, MUST be treated as if it was a URI within the XHTML vocabulary. All
>   other values will be processed as URIorCURIEs.
>
> The next paragraph and its associated example, beginning:
>
>   Note that only values in the link type list have this special behaviour, ...
>
> can be deleted.
>
> In the section 5.4.5, the example can have its square brackets removed.
>
> In section 7, the sentence:
>
>   Since it is difficult to distinguish between CURIEs and URIs, the CURIE
>   syntax adds the notion of a [safe CURIE].
>
> should be changed to:
>
>   A URI that uses a scheme that is not an in-scope mapping cannot be
>   confused with a CURIE. However, since there may be situations where
>   authors would like to make it explicit that they are using a CURIE, the
>   CURIE syntax adds the notion of a [safe CURIE].
>
>
> EXAMPLES
>
> At the end of section 2.2, we can add:
>
>   When dealing with small amounts of mark-up, it is sometimes easier
> to use full URIs,
>   rather than CURIEs. The previous example can also be written as follows:
>
>   <html xmlns="http://www.w3.org/1999/xhtml">
>     <head>
>       <title>Books by Marco Pierre White</title>
>     </head>
>     <body>
>       I think White's book
>       '<span
>        about="urn:ISBN:0091808189"
>        typeof="http://example.org/book"
>        property="http://purl.org/dc/elements/1.1/title"
>        >Canteen Cuisine</span>'
>       is well worth getting since although it's quite advanced stuff, he
>       makes it pretty easy to follow. You might also like
>       <span
>        about="urn:ISBN:1596913614"
>        typeof="http://example.org/book"
>        property="http://purl.org/dc/elements/1.1/description"
>        >White's autobiography</span>.
>     </body>
>   </html>
>
> Regards,
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> [hidden email]
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Mark Birbeck-4
Hi Julian,

Thanks for this.

The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
everywhere.

:)

It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
I figured that using the name 'URIorCURIE' rather than
'URIorCURIEorSafeCURIE', to represent this in the prose, would be
acceptable.

In other words, the functionality is definitely as you describe --
i.e., it is backwards-compatible -- it's just that the short name I've
used collapses the two types of CURIE into one, more general notion,
of a CURIE.

But if there's a feeling that this might confuse people, and that we
should use the longer term, then I don't have a problem with that
either.

Regards,

Mark

On Thu, Nov 26, 2009 at 12:30 PM, Julian Reschke <[hidden email]> wrote:

> Hi,
>
> here's a high-level comment without looking at the details.
>
> I appreciate the attempt to make progress. As far as I can tell, the change
> being proposed actually will not be backwards-compatible in all cases (for
> instance, when changing from URIorSafeCURIE to URIorCURIE). In which case
> you really should consider making a change that at least avoids confusion
> and potential ambiguity, by making everything URIorSafeCURIE. That would
> also align (as far as I recall) with the TAG advice not to use CURIEs where
> they might be confused with URIs.
>
> Best regards, Julian
>
>
> Mark Birbeck wrote:
>>
>> Hello all,
>>
>> I'd hoped to get the following proposal to the group at the beginning
>> of the week, but it wasn't possible.
>>
>> Anyway, below you'll find a series of minor changes that I feel would
>> need to be made to various parts of the syntax document, in order to
>> support URIs and CURIEs in all RDFa-related attributes (except @src
>> and @href).
>>
>> To recap, whilst most of our attributes support URIs and CURIEs
>> already, @property, @rel and @rev only supported URIs. This means that
>> authors must declare prefix mappings for all predicates, even though
>> they are not required to use prefix mappings for subjects or objects.
>> We've agreed to try to address this, and I had an action item to come
>> up with some proposed text.
>>
>>
>> APPROACH
>>
>> The first step in sorting this out, is to remove the separation where
>> in some places we allow a CURIE, and in others we allow a
>> URIorSafeCURIE.
>>
>> Both situations will now use the same type, which I've called
>> 'URIorCURIE'. (This type did used to exist in previous drafts, but I
>> think that's ok. Of course, if anyone can spot a reason why we should
>> use a different name, then please mention it.)
>>
>> After making the data type consistent throughout, we then need to
>> clarify the processing rules.
>>
>> And finally, we need to add one or more examples of using a full URI
>> for a predicate.
>>
>>
>> DATATYPE
>>
>> The datatype changes affect section 2.1, as follows:
>>
>> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
>> with 'URIorCURIE'.
>> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.
>>
>> Also, in section 5.4.4, the bullet-points listing the attributes
>> should change to this:
>>
>>  * @about, @datatype, @property, @resource and @typeof support either a
>> URI or
>>    a CURIE.
>>  * @href and @src support only a URI.
>>  * @rel and @rev support XHTML link types, URIs and CURIEs.
>>
>>
>> PROCESSING
>>
>> In section 5.4.2, after the three steps, but before the note, we should
>> add:
>>
>>  Note that this algorithm assumes that its input is a CURIE, but in
>> practice it
>>  won't be possible to definitively establish this until step 2; if
>> there is no in-scope
>>  mapping that matches the prefix, then the algorithm should terminate, and
>> the
>>  input regarded as a URI.
>>
>> In section 5.4.3, the first point should be removed, and in the second
>> point, the sentence:
>>
>>  In this case any value that is not surrounded by square brackets, as
>> defined
>>  by 'safe_curie' in the section CURIE Syntax Definition, will be
>> processed as if
>>  it was a URI.
>>
>> should be changed to:
>>
>>  In this case any value that is not a CURIE, as outlined in section 5.4.2,
>> will
>>  be processed as a URI.
>>
>> Note that I've left the prose about square brackets intact, because
>> there are probably use-cases where people want to say 'safe CURIE or
>> nothing'. (I.e., don't fall back to a URI if there is no prefix
>> mapping.)
>>
>> In the sentence after the two (now one) sentences, we should change this:
>>
>>  An example of an attribute that can contain CURIE and non-CURIE values is
>>  @about. As described, any CURIEs expressed in the attribute must follow
>> the
>>  format of a [safe CURIE]. So to express a URI directly, an author
>> might do this:
>>
>> to this:
>>
>>  An example of an attribute that can contain a URIorCURIE is @about. To
>>  express a URI directly, an author might do this:
>>
>> After the example, the next sentence/example combination can be
>> duplicated, to give us an extra example, like this:
>>
>>  whilst to express a CURIE they could do this:
>>
>>    <div about="dbr:Albert_Einstein">
>>      ...
>>    </div>
>>
>>  The author could also use a safe CURIE, as follows:
>>
>>    <div about="[dbr:Albert_Einstein]">
>>      ...
>>    </div>
>>
>> In the next example, we just need to clarify that we're now only
>> referring to safe CURIEs; this:
>>
>>  Since non-CURIE values MUST be ignored, ...
>>
>> becomes this:
>>
>>  Since non-CURIE values MUST be ignored when they appear in safe CURIEs,
>> ...
>>
>> In section 5.4.4, after the bullet-points, the entire sentence reading:
>>
>>  Note that unlike @about and @resource, @rel and @rev do not
>> differentiate their two
>>  types of data by using [safe CURIE]s.
>>
>> should be removed. The next sentence, which reads:
>>
>>  Instead, any value that matches an entry in the list of link types
>> in the section
>>  The rel attribute, MUST be treated as if it was a URI within the
>> XHTML vocabulary,
>>  and all other values must be CURIEs.
>>
>> should be changed to:
>>
>>  Any value that matches an entry in the list of link types in the
>> section The rel
>>  attribute, MUST be treated as if it was a URI within the XHTML
>> vocabulary. All
>>  other values will be processed as URIorCURIEs.
>>
>> The next paragraph and its associated example, beginning:
>>
>>  Note that only values in the link type list have this special behaviour,
>> ...
>>
>> can be deleted.
>>
>> In the section 5.4.5, the example can have its square brackets removed.
>>
>> In section 7, the sentence:
>>
>>  Since it is difficult to distinguish between CURIEs and URIs, the CURIE
>>  syntax adds the notion of a [safe CURIE].
>>
>> should be changed to:
>>
>>  A URI that uses a scheme that is not an in-scope mapping cannot be
>>  confused with a CURIE. However, since there may be situations where
>>  authors would like to make it explicit that they are using a CURIE, the
>>  CURIE syntax adds the notion of a [safe CURIE].
>>
>>
>> EXAMPLES
>>
>> At the end of section 2.2, we can add:
>>
>>  When dealing with small amounts of mark-up, it is sometimes easier
>> to use full URIs,
>>  rather than CURIEs. The previous example can also be written as follows:
>>
>>  <html xmlns="http://www.w3.org/1999/xhtml">
>>    <head>
>>      <title>Books by Marco Pierre White</title>
>>    </head>
>>    <body>
>>      I think White's book
>>      '<span
>>       about="urn:ISBN:0091808189"
>>       typeof="http://example.org/book"
>>       property="http://purl.org/dc/elements/1.1/title"
>>       >Canteen Cuisine</span>'
>>      is well worth getting since although it's quite advanced stuff, he
>>      makes it pretty easy to follow. You might also like
>>      <span
>>       about="urn:ISBN:1596913614"
>>       typeof="http://example.org/book"
>>       property="http://purl.org/dc/elements/1.1/description"
>>       >White's autobiography</span>.
>>    </body>
>>  </html>
>>
>> Regards,
>>
>> Mark
>>
>> --
>> Mark Birbeck, webBackplane
>>
>> [hidden email]
>>
>> http://webBackplane.com/mark-birbeck
>>
>> webBackplane is a trading name of Backplane Ltd. (company number
>> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
>> London, EC2A 4RR)
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Julian Reschke
Mark Birbeck wrote:
> Hi Julian,
>
> Thanks for this.
>
> The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
> everywhere.

Ah, I missed the "...orSafeCURIE".

> :)
>
> It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
> I figured that using the name 'URIorCURIE' rather than
> 'URIorCURIEorSafeCURIE', to represent this in the prose, would be
> acceptable.
>
> In other words, the functionality is definitely as you describe --
> i.e., it is backwards-compatible -- it's just that the short name I've
> used collapses the two types of CURIE into one, more general notion,
> of a CURIE.
>
> But if there's a feeling that this might confuse people, and that we
> should use the longer term, then I don't have a problem with that
> either.
> ...

I was confused, so my assumption would be that others will be confused
as well.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Julian Reschke
Julian Reschke wrote:

> Mark Birbeck wrote:
>> Hi Julian,
>>
>> Thanks for this.
>>
>> The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
>> everywhere.
>
> Ah, I missed the "...orSafeCURIE".
>
>> :)
>>
>> It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
>> I figured that using the name 'URIorCURIE' rather than
>> 'URIorCURIEorSafeCURIE', to represent this in the prose, would be
>> acceptable.
>>
>> In other words, the functionality is definitely as you describe --
>> i.e., it is backwards-compatible -- it's just that the short name I've
>> used collapses the two types of CURIE into one, more general notion,
>> of a CURIE.
>>
>> But if there's a feeling that this might confuse people, and that we
>> should use the longer term, then I don't have a problem with that
>> either.
>> ...
>
> I was confused, so my assumption would be that others will be confused
> as well.
> ...

Having said that... URIs and CURIEs use the same lexical space. On the
other hand, Safe-CURIEs have been designed to they never conflict with URIs.

If you are going to allow all three notations in the same place, you may
want to give advice which to use. I *think* the best advice would be to
use either URIs or Safe-CURIEs, and to avoid CURIEs.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Toby Inkster-4
In reply to this post by Mark Birbeck-4
On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
> Anyway, below you'll find a series of minor changes that I feel would
> need to be made to various parts of the syntax document, in order to
> support URIs and CURIEs in all RDFa-related attributes (except @src
> and @href).

The following describes the behaviour of the unreleased
RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
0.20.)

If the parser is instantiated with the option "full_uris" set to true,
then, it uses the following behaviour for these attributes:

@about/@resource: Safe CURIE, falling back to URIs.
@src/@href: URIs only.
@rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
@property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.

I think this is more or less the same as your proposal, except that
unsafe CURIEs are disallowed in @about/@resource.

By default, i.e. when "full_uris" is not true, it uses:

@about/@resource: Safe CURIE, falling back to URIs.
@src/@href: URIs only.
@rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
@property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.

And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa
test suite. (Yay!)

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Ivan Herman-2
I redid the relevant part of my distiller, too, and it is much nicer and
simpler. It is one single method that has some internal branches, but
can still handle @rel/@rev/@about/@resource/@typeof in one place. An
this is nice. What it does with 'value':

1. Get the possible safe curie signs out of the way at the start, ie, if
the value is of the form '[...]' then remove the [ and ] signs. Ie, the
safe curie is there for backward compatibility only. (And yes, that
means that I do allow unsafe curies for @about and @resource)

2. Get the possible blank node management out of the way, ie return the
right blank node for things like '_:a'. Note that if this is called for
a @rel/@property/@ref, then return None (with possible error message)
because you cannot have a blank node for a predicate

3. If it is called on @rel/@rev and the value is a keyword then return
the corresponding URI

4. Try to match the value against a CURIE definition (ie, see if it is
of the form a:b and 'a' is defined as a namespace, oops, local name). If
yes, return the corresponding URI

5. If we get here, this is a real URI (absolute or relative), and fall
back to the usual URI management to get the final URI (there are python
tools to do that with all the quirks of relative uris and the like).

I think this is in line with what Mark describes. I have written it down
here to see if it is what Mark had in mind (until we have relevant test
cases...)

I plan to test a bit more and put up a test version of the distiller
service on line with an extra "1.1" flag to trigger this behaviour.
Hopefully on the week end or early next week.

Ivan


Toby Inkster wrote:

> On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
>> Anyway, below you'll find a series of minor changes that I feel would
>> need to be made to various parts of the syntax document, in order to
>> support URIs and CURIEs in all RDFa-related attributes (except @src
>> and @href).
>
> The following describes the behaviour of the unreleased
> RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
> 0.20.)
>
> If the parser is instantiated with the option "full_uris" set to true,
> then, it uses the following behaviour for these attributes:
>
> @about/@resource: Safe CURIE, falling back to URIs.
> @src/@href: URIs only.
> @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
> @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.
>
> I think this is more or less the same as your proposal, except that
> unsafe CURIEs are disallowed in @about/@resource.
>
> By default, i.e. when "full_uris" is not true, it uses:
>
> @about/@resource: Safe CURIE, falling back to URIs.
> @src/@href: URIs only.
> @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
> @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.
>
> And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa
> test suite. (Yay!)
>
--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Mark Birbeck-4
Wow...great work Ivan and Toby. :)

The algorithm I outlined is actually ever so slightly different to
what you have described Ivan.

Obviously it's all up for debate, but just so that we can have that
discussion, I'll clarify what I was proposing.

We've agreed that we're now saying that this is not a CURIE:

  a:b

but this is:

 @prefix a: <http://example.com/>

 a:b

I.e., if a mapping is defined, then we have a CURIE, if not, we have a URI.

However...

I believe it would be useful to say that the following will *never*
become a URI:

  [a:b]

My feeling is that in this situation the author is saying that they
explicitly want to use the CURIE 'a:b' with the mapping 'a'. And if
the mapping 'a' doesn't exist, then something has gone wrong, and they
would prefer it to be ignored altogether.

I'm seeing this as a useful 'strict' mode, that automated systems
might want to use, but hand-coders would almost certainly avoid.

Any thoughts?

Regards

Mark

--
Mark Birbeck, webBackplane

[hidden email]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)




On Fri, Nov 27, 2009 at 5:18 PM, Ivan Herman <[hidden email]> wrote:

> I redid the relevant part of my distiller, too, and it is much nicer and
> simpler. It is one single method that has some internal branches, but
> can still handle @rel/@rev/@about/@resource/@typeof in one place. An
> this is nice. What it does with 'value':
>
> 1. Get the possible safe curie signs out of the way at the start, ie, if
> the value is of the form '[...]' then remove the [ and ] signs. Ie, the
> safe curie is there for backward compatibility only. (And yes, that
> means that I do allow unsafe curies for @about and @resource)
>
> 2. Get the possible blank node management out of the way, ie return the
> right blank node for things like '_:a'. Note that if this is called for
> a @rel/@property/@ref, then return None (with possible error message)
> because you cannot have a blank node for a predicate
>
> 3. If it is called on @rel/@rev and the value is a keyword then return
> the corresponding URI
>
> 4. Try to match the value against a CURIE definition (ie, see if it is
> of the form a:b and 'a' is defined as a namespace, oops, local name). If
> yes, return the corresponding URI
>
> 5. If we get here, this is a real URI (absolute or relative), and fall
> back to the usual URI management to get the final URI (there are python
> tools to do that with all the quirks of relative uris and the like).
>
> I think this is in line with what Mark describes. I have written it down
> here to see if it is what Mark had in mind (until we have relevant test
> cases...)
>
> I plan to test a bit more and put up a test version of the distiller
> service on line with an extra "1.1" flag to trigger this behaviour.
> Hopefully on the week end or early next week.
>
> Ivan
>
>
> Toby Inkster wrote:
>> On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
>>> Anyway, below you'll find a series of minor changes that I feel would
>>> need to be made to various parts of the syntax document, in order to
>>> support URIs and CURIEs in all RDFa-related attributes (except @src
>>> and @href).
>>
>> The following describes the behaviour of the unreleased
>> RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
>> 0.20.)
>>
>> If the parser is instantiated with the option "full_uris" set to true,
>> then, it uses the following behaviour for these attributes:
>>
>> @about/@resource: Safe CURIE, falling back to URIs.
>> @src/@href: URIs only.
>> @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
>> @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.
>>
>> I think this is more or less the same as your proposal, except that
>> unsafe CURIEs are disallowed in @about/@resource.
>>
>> By default, i.e. when "full_uris" is not true, it uses:
>>
>> @about/@resource: Safe CURIE, falling back to URIs.
>> @src/@href: URIs only.
>> @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
>> @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.
>>
>> And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa
>> test suite. (Yay!)
>>
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Shane McCarron


Mark Birbeck wrote:

>
> I believe it would be useful to say that the following will *never*
> become a URI:
>
>   [a:b]
>
> My feeling is that in this situation the author is saying that they
> explicitly want to use the CURIE 'a:b' with the mapping 'a'. And if
> the mapping 'a' doesn't exist, then something has gone wrong, and they
> would prefer it to be ignored altogether.
>
> I'm seeing this as a useful 'strict' mode, that automated systems
> might want to use, but hand-coders would almost certainly avoid.
>
> Any thoughts?
I agree with this.  A lot.

--
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Gregg Kellogg
In reply to this post by Mark Birbeck-4
+1

[a:b] should generate an error if "" is undefined.

Gregg Kellogg
Sent from my iPhone

On Nov 27, 2009, at 1:00 PM, "Mark Birbeck" <[hidden email]
 > wrote:

> Wow...great work Ivan and Toby. :)
>
> The algorithm I outlined is actually ever so slightly different to
> what you have described Ivan.
>
> Obviously it's all up for debate, but just so that we can have that
> discussion, I'll clarify what I was proposing.
>
> We've agreed that we're now saying that this is not a CURIE:
>
>  a:b
>
> but this is:
>
> @prefix a: <http://example.com/>
>
> a:b
>
> I.e., if a mapping is defined, then we have a CURIE, if not, we have  
> a URI.
>
> However...
>
> I believe it would be useful to say that the following will *never*
> become a URI:
>
>  [a:b]
>
> My feeling is that in this situation the author is saying that they
> explicitly want to use the CURIE 'a:b' with the mapping 'a'. And if
> the mapping 'a' doesn't exist, then something has gone wrong, and they
> would prefer it to be ignored altogether.
>
> I'm seeing this as a useful 'strict' mode, that automated systems
> might want to use, but hand-coders would almost certainly avoid.
>
> Any thoughts?
>
> Regards
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> [hidden email]
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>
>
>
>
> On Fri, Nov 27, 2009 at 5:18 PM, Ivan Herman <[hidden email]> wrote:
>> I redid the relevant part of my distiller, too, and it is much  
>> nicer and
>> simpler. It is one single method that has some internal branches, but
>> can still handle @rel/@rev/@about/@resource/@typeof in one place. An
>> this is nice. What it does with 'value':
>>
>> 1. Get the possible safe curie signs out of the way at the start,  
>> ie, if
>> the value is of the form '[...]' then remove the [ and ] signs. Ie,  
>> the
>> safe curie is there for backward compatibility only. (And yes, that
>> means that I do allow unsafe curies for @about and @resource)
>>
>> 2. Get the possible blank node management out of the way, ie return  
>> the
>> right blank node for things like '_:a'. Note that if this is called  
>> for
>> a @rel/@property/@ref, then return None (with possible error message)
>> because you cannot have a blank node for a predicate
>>
>> 3. If it is called on @rel/@rev and the value is a keyword then  
>> return
>> the corresponding URI
>>
>> 4. Try to match the value against a CURIE definition (ie, see if it  
>> is
>> of the form a:b and 'a' is defined as a namespace, oops, local  
>> name). If
>> yes, return the corresponding URI
>>
>> 5. If we get here, this is a real URI (absolute or relative), and  
>> fall
>> back to the usual URI management to get the final URI (there are  
>> python
>> tools to do that with all the quirks of relative uris and the like).
>>
>> I think this is in line with what Mark describes. I have written it  
>> down
>> here to see if it is what Mark had in mind (until we have relevant  
>> test
>> cases...)
>>
>> I plan to test a bit more and put up a test version of the distiller
>> service on line with an extra "1.1" flag to trigger this behaviour.
>> Hopefully on the week end or early next week.
>>
>> Ivan
>>
>>
>> Toby Inkster wrote:
>>> On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
>>>> Anyway, below you'll find a series of minor changes that I feel  
>>>> would
>>>> need to be made to various parts of the syntax document, in order  
>>>> to
>>>> support URIs and CURIEs in all RDFa-related attributes (except @src
>>>> and @href).
>>>
>>> The following describes the behaviour of the unreleased
>>> RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
>>> 0.20.)
>>>
>>> If the parser is instantiated with the option "full_uris" set to  
>>> true,
>>> then, it uses the following behaviour for these attributes:
>>>
>>> @about/@resource: Safe CURIE, falling back to URIs.
>>> @src/@href: URIs only.
>>> @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
>>> @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.
>>>
>>> I think this is more or less the same as your proposal, except that
>>> unsafe CURIEs are disallowed in @about/@resource.
>>>
>>> By default, i.e. when "full_uris" is not true, it uses:
>>>
>>> @about/@resource: Safe CURIE, falling back to URIs.
>>> @src/@href: URIs only.
>>> @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
>>> @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.
>>>
>>> And as of 0.21 it's now passing all 107 approved tests in the XHTML
>>> +RDFa
>>> test suite. (Yay!)
>>>
>>
>> --
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Ivan Herman-2
In reply to this post by Mark Birbeck-4

Mark Birbeck wrote:

>
> However...
>
> I believe it would be useful to say that the following will *never*
> become a URI:
>
>   [a:b]
>
> My feeling is that in this situation the author is saying that they
> explicitly want to use the CURIE 'a:b' with the mapping 'a'. And if
> the mapping 'a' doesn't exist, then something has gone wrong, and they
> would prefer it to be ignored altogether.
>
> I'm seeing this as a useful 'strict' mode, that automated systems
> might want to use, but hand-coders would almost certainly avoid.
>
Yep, you are right, I missed that point. And I agree.

For the records, I modified my implementation taking this into account,
see below in the post scriptum. I have now set up

http://www.w3.org/2007/08/pyRdfa/Test.html

which runs the newer version. Default is set to RDFa1.1 (if set to 'No'
then the current mechanism comes into the picture). A tiny example is at

http://www.ivan-herman.net/Misc/2009/RDFaURITest.html

Again for the records (and to test my own understanding) here are the
differences between old and new as I see them:

- URI-s can be used in @rel/@rev/@property; this includes both absolute
and relative URIs, with the provision that predefined values (stylesheet
and the like) are not considered Curie predicates in the xhtml
namespace. Curies are of a higher priority than URIs
- @about/@resource can accept Curies with a higher priority than URIs.
- all the attributes can also accept Safe Curies; their usage would
disallow the fall back on URI-s. Note that, afaik, safe curies were
_not_ allowed in @rel/@rev/@property before, so this is a new feature
for those...

Looking at this list, the remaining asymmetry is the usage of keywords
for @rel/@rev/@property. I begin to wonder: if we do such a grand
unification, does it make sense to keep this asymmetry? I do not claim
that statements like

<span about="next" ... />

would have a widespread usage but it does make sense in the RDF sense,
ie, it means

xhtml:next some:property some:value .

ie, I make a statement on an existing predicate. Perfectly kosher for RDF.

Ie: what about removing that asymmetry altogether, and say that
predefined keywords are also valid for @about and @resource? It would
make the URI management simpler and cleaner and I do not really see a
major drawback...

Ivan

P.S. So here is what I run now.

1. Get the possible safe curie signs out of the way at the start, ie, if
the value is of the form '[...]' then remove the [ and ] signs and set a
'safe_curie' flag to True.

2. Get the possible blank node management out of the way, ie return the
right blank node for things like '_:a'. Note that if this is called for
a @rel/@property/@ref, then return None (with possible error message)
because you cannot have a blank node for a predicate

3. If it is called on @rel/@rev and the value is a keyword then return
the corresponding URI

4. Try to match the value against a CURIE definition (ie, see if it is
of the form a:b and 'a' is defined as a namespace, oops, local name). If
yes, return the corresponding URI

5. If we get here, this should become a real URI. However, if the
safe_curie flag was set to True, stop at this point and (possibly) issue
an error message and return with None

6. If we get here, this is a real URI (absolute or relative), and fall
back to the usual URI management to get the final URI.

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Steven Pemberton-3
In reply to this post by Mark Birbeck-4
On Fri, 27 Nov 2009 18:59:10 +0100, Mark Birbeck  
<[hidden email]> wrote:

> Wow...great work Ivan and Toby. :)
>
> The algorithm I outlined is actually ever so slightly different to
> what you have described Ivan.
>
> Obviously it's all up for debate, but just so that we can have that
> discussion, I'll clarify what I was proposing.
>
> We've agreed that we're now saying that this is not a CURIE:
>
>   a:b
>
> but this is:
>
>  @prefix a: <http://example.com/>
>
>  a:b
>
> I.e., if a mapping is defined, then we have a CURIE, if not, we have a  
> URI.
>
> However...
>
> I believe it would be useful to say that the following will *never*
> become a URI:
>
>   [a:b]
+1

Steven

>
> My feeling is that in this situation the author is saying that they
> explicitly want to use the CURIE 'a:b' with the mapping 'a'. And if
> the mapping 'a' doesn't exist, then something has gone wrong, and they
> would prefer it to be ignored altogether.
>
> I'm seeing this as a useful 'strict' mode, that automated systems
> might want to use, but hand-coders would almost certainly avoid.
>
> Any thoughts?
>
> Regards
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> [hidden email]
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>
>
>
>
> On Fri, Nov 27, 2009 at 5:18 PM, Ivan Herman <[hidden email]> wrote:
>> I redid the relevant part of my distiller, too, and it is much nicer and
>> simpler. It is one single method that has some internal branches, but
>> can still handle @rel/@rev/@about/@resource/@typeof in one place. An
>> this is nice. What it does with 'value':
>>
>> 1. Get the possible safe curie signs out of the way at the start, ie, if
>> the value is of the form '[...]' then remove the [ and ] signs. Ie, the
>> safe curie is there for backward compatibility only. (And yes, that
>> means that I do allow unsafe curies for @about and @resource)
>>
>> 2. Get the possible blank node management out of the way, ie return the
>> right blank node for things like '_:a'. Note that if this is called for
>> a @rel/@property/@ref, then return None (with possible error message)
>> because you cannot have a blank node for a predicate
>>
>> 3. If it is called on @rel/@rev and the value is a keyword then return
>> the corresponding URI
>>
>> 4. Try to match the value against a CURIE definition (ie, see if it is
>> of the form a:b and 'a' is defined as a namespace, oops, local name). If
>> yes, return the corresponding URI
>>
>> 5. If we get here, this is a real URI (absolute or relative), and fall
>> back to the usual URI management to get the final URI (there are python
>> tools to do that with all the quirks of relative uris and the like).
>>
>> I think this is in line with what Mark describes. I have written it down
>> here to see if it is what Mark had in mind (until we have relevant test
>> cases...)
>>
>> I plan to test a bit more and put up a test version of the distiller
>> service on line with an extra "1.1" flag to trigger this behaviour.
>> Hopefully on the week end or early next week.
>>
>> Ivan
>>
>>
>> Toby Inkster wrote:
>>> On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
>>>> Anyway, below you'll find a series of minor changes that I feel would
>>>> need to be made to various parts of the syntax document, in order to
>>>> support URIs and CURIEs in all RDFa-related attributes (except @src
>>>> and @href).
>>>
>>> The following describes the behaviour of the unreleased
>>> RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
>>> 0.20.)
>>>
>>> If the parser is instantiated with the option "full_uris" set to true,
>>> then, it uses the following behaviour for these attributes:
>>>
>>> @about/@resource: Safe CURIE, falling back to URIs.
>>> @src/@href: URIs only.
>>> @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
>>> @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.
>>>
>>> I think this is more or less the same as your proposal, except that
>>> unsafe CURIEs are disallowed in @about/@resource.
>>>
>>> By default, i.e. when "full_uris" is not true, it uses:
>>>
>>> @about/@resource: Safe CURIE, falling back to URIs.
>>> @src/@href: URIs only.
>>> @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
>>> @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.
>>>
>>> And as of 0.21 it's now passing all 107 approved tests in the  
>>> XHTML+RDFa
>>> test suite. (Yay!)
>>>
>>
>> --
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Steven Pemberton-3
In reply to this post by Ivan Herman-2
> Looking at this list, the remaining asymmetry is the usage of keywords
> for @rel/@rev/@property. I begin to wonder: if we do such a grand
> unification, does it make sense to keep this asymmetry? I do not claim
> that statements like
>
> <span about="next" ... />
>
> would have a widespread usage but it does make sense in the RDF sense,
> ie, it means
>
> xhtml:next some:property some:value .
>
> ie, I make a statement on an existing predicate. Perfectly kosher for  
> RDF.
>
> Ie: what about removing that asymmetry altogether, and say that
> predefined keywords are also valid for @about and @resource? It would
> make the URI management simpler and cleaner and I do not really see a
> major drawback...

No, please not. As far as I am concerned about="next" must always mean the  
same as about="./next". It must always be a URI.

Steven

>
> Ivan
>
> P.S. So here is what I run now.
>
> 1. Get the possible safe curie signs out of the way at the start, ie, if
> the value is of the form '[...]' then remove the [ and ] signs and set a
> 'safe_curie' flag to True.
>
> 2. Get the possible blank node management out of the way, ie return the
> right blank node for things like '_:a'. Note that if this is called for
> a @rel/@property/@ref, then return None (with possible error message)
> because you cannot have a blank node for a predicate
>
> 3. If it is called on @rel/@rev and the value is a keyword then return
> the corresponding URI
>
> 4. Try to match the value against a CURIE definition (ie, see if it is
> of the form a:b and 'a' is defined as a namespace, oops, local name). If
> yes, return the corresponding URI
>
> 5. If we get here, this should become a real URI. However, if the
> safe_curie flag was set to True, stop at this point and (possibly) issue
> an error message and return with None
>
> 6. If we get here, this is a real URI (absolute or relative), and fall
> back to the usual URI management to get the final URI.
>


Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Ivan Herman-2
>> Ie: what about removing that asymmetry altogether, and say that
>> predefined keywords are also valid for @about and @resource? It would
>> make the URI management simpler and cleaner and I do not really see a
>> major drawback...
>
> No, please not. As far as I am concerned about="next" must always mean
> the same as about="./next". It must always be a URI.
>
> Steven
>

Differences of sensibilities, obviously... the asymmetry between @rel
and @about bothers me more than a coincidence of one of the keywords
with a possible relative URI-s

Ivan

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for 'URIs everywhere'

Shane McCarron
In reply to this post by Steven Pemberton-3


Steven Pemberton wrote:
>
> No, please not. As far as I am concerned about="next" must always mean
> the same as about="./next". It must always be a URI.
>
+1

--
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: [hidden email]