URIs in @rel and @property...

[Ben Adida-2]

Hey folks,

I'm catching up on the minutes from today, looks like a productive
meeting, very nice.

I am a little bit concerned about supporting plain CURIEs in @about,
@href, and @resource. For one, the use case is *very* limited, since the
whole point of prefixes is to reuse vocabularies, and that applies to
predicates, not to subjects and objects. Also, we want to continue to
support relative URIs in @about, just like @href (and the spec for @href
isn't about to change), and that's not very easy to do if we allow plain
CURIEs, too.

So I think we should be as conservative as possible with this change.
Allowing absolute URIs in @rel, @property, @typeof, and @datatype makes
sense, but generalizing the "other way" to let @about and @resource (and
@href) carry plain CURIEs does not, in my opinion, because of important
existing uses for those attributes.

-Ben

[Ivan Herman-2]

Ben,

I am not sure I understand the issue about relative URIs in @about and
@resource. Why would that be affected by allowing plain CURIE-s there?

As for the use case: Some typical cases where I have this.

- I generate lists in RDFa, ie, I will have to have @about="[_:x]" style
values (eg, when I encode a list of persons co-authoring a paper or a
presentation).

- I encode a set of statements for URI-s of the form
http://example.org/A, http://example.org/B, ...(eg, an HTML text
describing a vocabulary). The obvious way of doing that is to define a
namespace for http://example.org/ and use @about="[ex:A]", @about="[ex:B]".

In all those cases I keep forgetting those [ and ]-s, generating faulty
RDF...

I guess I do not see the problem...

Ivan

Ben Adida wrote:

>
> Hey folks,
>
> I'm catching up on the minutes from today, looks like a productive
> meeting, very nice.
>
> I am a little bit concerned about supporting plain CURIEs in @about,
> @href, and @resource. For one, the use case is *very* limited, since the
> whole point of prefixes is to reuse vocabularies, and that applies to
> predicates, not to subjects and objects. Also, we want to continue to
> support relative URIs in @about, just like @href (and the spec for @href
> isn't about to change), and that's not very easy to do if we allow plain
> CURIEs, too.
>
> So I think we should be as conservative as possible with this change.
> Allowing absolute URIs in @rel, @property, @typeof, and @datatype makes
> sense, but generalizing the "other way" to let @about and @resource (and
> @href) carry plain CURIEs does not, in my opinion, because of important
> existing uses for those attributes.
>
> -Ben
>

--

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

[Shane McCarron]

Ben Adida wrote:

>
> Hey folks,
>
> I'm catching up on the minutes from today, looks like a productive
> meeting, very nice.
>
> I am a little bit concerned about supporting plain CURIEs in @about,
> @href, and @resource. For one, the use case is *very* limited, since
> the whole point of prefixes is to reuse vocabularies, and that applies
> to predicates, not to subjects and objects. Also, we want to continue
> to support relative URIs in @about, just like @href (and the spec for
> @href isn't about to change), and that's not very easy to do if we
> allow plain CURIEs, too.

I do not think that the concept of enabling regular CURIEs in @about and
@resource was really accepted.  If it was, I wasn't paying attention
(which is possible).  I can see how it is a logical extension of the
rule that says "if a prefix is not mapped, treat it as a URI" but I
consider it to be a separate topic.  Happy to debate it.  Not sure how I
feel about it at this point.  In general I am not a fan of making
changes like this.  I find relative URIs in @about and @resource to be
compelling.  I find your vocabulary and predicates compelling.  So,
right this moment, I would oppose permitting regular CURIEs in @about
and @resource.

>
> So I think we should be as conservative as possible with this change.
> Allowing absolute URIs in @rel, @property, @typeof, and @datatype
> makes sense, but generalizing the "other way" to let @about and
> @resource (and @href) carry plain CURIEs does not, in my opinion,
> because of important existing uses for those attributes.
I do not think there was support in the meeting for extending CURIEs
into non-RDFa attributes (e.g., @href and @src).  Personally, I would
oppose such a move.


--
Shane P. McCarron                          Phone: [phone] x120
Managing Director                            Fax: [phone]
ApTest Minnesota                            Inet: shane@...

[Mark Birbeck-4]

Hi Ben,

I don't want to detract from your broader point, but I do just want to
pick up on one thing you said:

> I am a little bit concerned about supporting plain CURIEs in @about, @href,
> and @resource. For one, the use case is *very* limited, since the whole
> point of prefixes is to reuse vocabularies, and that applies to predicates,
> not to subjects and objects.

This is the point I was trying to get at in my 'tokenisation' discussion [1].

As you say, prefixes have always been used for vocabulary mappings,
but this has meant that the technique is inadequate when it comes to
mapping full URIs -- hence the development of the CURIE approach.

But also, setting the pattern as:

  vocab:term

is exactly why every document begins with so many prefix declarations.

My suggestion in the tokenisation document is to move away from
working out how to map vocabularies to prefixes, and instead, to work
out how to map between URIs and tokens.

Regards,

Mark

[1] <http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web>

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

[Ivan Herman-2]

Still following up on this...

Ben Adida wrote:

>
> Hey folks,
>
> I'm catching up on the minutes from today, looks like a productive
> meeting, very nice.
>
> I am a little bit concerned about supporting plain CURIEs in @about,
> @href, and @resource. For one, the use case is *very* limited, since the
> whole point of prefixes is to reuse vocabularies, and that applies to
> predicates, not to subjects and objects. Also, we want to continue to
> support relative URIs in @about, just like @href (and the spec for @href
> isn't about to change), and that's not very easy to do if we allow plain
> CURIEs, too.
>

- I agree that we should _not_ touch @href (and @src). Those are not
under our control, they should stay as they are.

- I must admit I did not see your comment on 'that applies to
predicates, not to subjects and objects' until now. And I do not agree
with that. Apart from the few examples I gave in my previous mail,
another one just came to my mind: one of our use case is to provide a
readable version of a vocabulary definition. Such description will be
full of subclass, subproperty etc relationships on its own domain, ie,
both the subject and the object part will need curies-s. And protected
curie-s are a pain and are error prone...

- I actually did an implementation on my machine, reasonably tested. The
algorithm is fairly simple (unless I miss an elephant in the room):

1. check whether the value is of the 'a:b' form and 'a' is defined CURIE
prefix
2. if yes, return the URI as defined by the CURIE
3. if not, do a urljoin of the base URI and the value. Per definition of
that join, if the value is an absolute URI, that will prevail, otherwise
the urljoin rules will dictate the behaviour. (eg, Python has just
method as part of its standard library...)

The only difference between the old and new version is entries #1 and
#2, #3 was the behaviour as of RDFa 1.0.

Actually, the same steps could also be used for @rel/@rev/@typeof, ie,
allowing relative URIs for those attributes as well! Which might
simplify everything: all RDFa attributes would behave similarly. (Again,
we should not touch @href and @src.)

So is there an elephant?:-)

Ivan


> So I think we should be as conservative as possible with this change.
> Allowing absolute URIs in @rel, @property, @typeof, and @datatype makes
> sense, but generalizing the "other way" to let @about and @resource (and
> @href) carry plain CURIEs does not, in my opinion, because of important
> existing uses for those attributes.
>
> -Ben
>

--

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

[Niklas Lindström]

Hi!

On Mon, Nov 16, 2009 at 1:03 PM, Ivan Herman <ivan@...> wrote:
> Still following up on this...
>
[...]

> - I actually did an implementation on my machine, reasonably tested. The
> algorithm is fairly simple (unless I miss an elephant in the room):
>
> 1. check whether the value is of the 'a:b' form and 'a' is defined CURIE
> prefix
> 2. if yes, return the URI as defined by the CURIE
> 3. if not, do a urljoin of the base URI and the value. Per definition of
> that join, if the value is an absolute URI, that will prevail, otherwise
> the urljoin rules will dictate the behaviour. (eg, Python has just
> method as part of its standard library...)
>
> The only difference between the old and new version is entries #1 and
> #2, #3 was the behaviour as of RDFa 1.0.
>
> Actually, the same steps could also be used for @rel/@rev/@typeof, ie,
> allowing relative URIs for those attributes as well! Which might
> simplify everything: all RDFa attributes would behave similarly. (Again,
> we should not touch @href and @src.)
>
> So is there an elephant?:-)

I haven't followed this discussion to closely, so I want to check if
this the following is considered:

This usage will "muddle the waters" in cases when the relative URI:s
contain colon, and there is a prefix with the same name as the leading
part before that, right? Concrete (but contrieved) example:

Given:
    - base URI: <http://en.wikipedia.org/wiki/>
    - prefix Talk: <http://example.org/schema/talk#>

When:
    @resource="Talk:Linked_Data"

Then:
    - URI becomes < http://example.org/schema/talk#Linked_Data>,
instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
might be expected?

(Don't mind the malpractise of using a "Title-cased" prefix here, I
just picked the first real-word relative URL with colon in it I
found..)

Best regards,
Niklas

[Ivan Herman-2]

Hi Niklas,

Niklas Lindström wrote:

>>
>> So is there an elephant?:-)
>
> I haven't followed this discussion to closely, so I want to check if
> this the following is considered:
>
> This usage will "muddle the waters" in cases when the relative URI:s
> contain colon, and there is a prefix with the same name as the leading
> part before that, right? Concrete (but contrieved) example:
>
> Given:
>     - base URI: <http://en.wikipedia.org/wiki/>
>     - prefix Talk: <http://example.org/schema/talk#>
>
> When:
>     @resource="Talk:Linked_Data"
>
> Then:
>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
> might be expected?
>

Hm. You may found the elephant:-)

Yes, in this case one would indeed get the example.org URI.

The question is: is this use case so strong as to nullify the advantages
of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
quite a lot but the user can of course put full URI-s into the value of
@about...

Thanks!

Ivan



> (Don't mind the malpractise of using a "Title-cased" prefix here, I
> just picked the first real-word relative URL with colon in it I
> found..)
>
> Best regards,
> Niklas

--

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

[Toby Inkster-4]

Here's an idea, and it may be a terrible one. That's for you lot to
decide.

In RDFa 1.1, all RDFa-specific attributes (i.e. not @href and @src) may
take either SafeCURIEs or Safe URIs. SafeCURIEs take the form:

        [prefix:suffix]

SafeURIs take the form:

        {absoluteOrRelativeURI}

(Angled brackets are theoretically nicer than curly braces because they
fit better with how URIs are often given in the wild - but they'd need
escaping when serialised, so they're probably not as nice in practise.
More on this later...)

In the case of tokens which are neither a SafeCURIE nor a SafeURI, a
disambiguation method is applied:

        1. If the attrbute is @about or @resource, the token is
           a URI;

        2. If the attribute is @rel or @rev and on the list of
           known keywords, it's a keyword.

        3. If the token begins '_:' then it's a bnode.

        4. If the prefix of the token has been declared, or it's
           the empty prefix, it's a CURIE.

        5. Otherwise it's a URI.

(... More on the curly braces: actually you'll see that in most cases,
people will be able to rely on the disambiguation method rather than use
curly braces. So maybe instead with *should* use angled brackets <>
which look ugly when serialised - precisely to discourage people from
using them, and encourage them instead to rely on the disambiguation
algorithm.)

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Mark Birbeck-4]

Hi Ivan/Niklas,

2009/11/16 Ivan Herman <ivan@...>:

> Hi Niklas,
>
> Niklas Lindström wrote:
>>>
>>> So is there an elephant?:-)
>>
>> I haven't followed this discussion to closely, so I want to check if
>> this the following is considered:
>>
>> This usage will "muddle the waters" in cases when the relative URI:s
>> contain colon, and there is a prefix with the same name as the leading
>> part before that, right? Concrete (but contrieved) example:
>>
>> Given:
>>     - base URI: <http://en.wikipedia.org/wiki/>
>>     - prefix Talk: <http://example.org/schema/talk#>
>>
>> When:
>>     @resource="Talk:Linked_Data"
>>
>> Then:
>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>> might be expected?
>>
>
> Hm. You may found the elephant:-)
>
> Yes, in this case one would indeed get the example.org URI.
>
> The question is: is this use case so strong as to nullify the advantages
> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
> quite a lot but the user can of course put full URI-s into the value of
> @about...
>
> Thanks!

Whoah...slow down. :)

"Talk:Linked_Data" is not a relative path!

Forget prefixes, CURIEs, whatever...even if those things did not
exist, how would a URI processor know whether "Talk:" is a scheme or
just part of a relative path?

RFC 3986 [1] addresses this in the following way:

  A path segment that contains a colon character (e.g., "this:that")
cannot be used as the
  first segment of a relative-path reference, as it would be mistaken
for a scheme name.
  Such a segment must be preceded by a dot-segment (e.g.,
"./this:that") to make a
  relative-path reference.

So, if people are using relative paths that contain colons, in the
wild, then there's a problem, and that problem is completely
independent of RDFa.

Regards,

Mark

[1] <http://www.ietf.org/rfc/rfc3986.txt>

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

[Ivan Herman-2]

Pfew...:-)

Ivan

P.S. Mark-the-elephant-hunter:-)

Mark Birbeck wrote:

> Hi Ivan/Niklas,
>
> 2009/11/16 Ivan Herman <ivan@...>:
>> Hi Niklas,
>>
>> Niklas Lindström wrote:
>>>> So is there an elephant?:-)
>>> I haven't followed this discussion to closely, so I want to check if
>>> this the following is considered:
>>>
>>> This usage will "muddle the waters" in cases when the relative URI:s
>>> contain colon, and there is a prefix with the same name as the leading
>>> part before that, right? Concrete (but contrieved) example:
>>>
>>> Given:
>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>
>>> When:
>>>     @resource="Talk:Linked_Data"
>>>
>>> Then:
>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>> might be expected?
>>>
>> Hm. You may found the elephant:-)
>>
>> Yes, in this case one would indeed get the example.org URI.
>>
>> The question is: is this use case so strong as to nullify the advantages
>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>> quite a lot but the user can of course put full URI-s into the value of
>> @about...
>>
>> Thanks!
>
>
> Whoah...slow down. :)
>
> "Talk:Linked_Data" is not a relative path!
>
> Forget prefixes, CURIEs, whatever...even if those things did not
> exist, how would a URI processor know whether "Talk:" is a scheme or
> just part of a relative path?
>
> RFC 3986 [1] addresses this in the following way:
>
>   A path segment that contains a colon character (e.g., "this:that")
> cannot be used as the
>   first segment of a relative-path reference, as it would be mistaken
> for a scheme name.
>   Such a segment must be preceded by a dot-segment (e.g.,
> "./this:that") to make a
>   relative-path reference.
>
> So, if people are using relative paths that contain colons, in the
> wild, then there's a problem, and that problem is completely
> independent of RDFa.
>
> Regards,
>
> Mark
>
> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>
> --
> Mark Birbeck, webBackplane
>
> mark.birbeck@...
>
> 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)

--

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

[Niklas Lindström]

Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
that RFC 3986 is so precise about these things.

(I should have known that -- I now recall reading that very same rule
a couple of months ago when investigating the legality of non-escaped
colons in URI:s. Only remembered half of it apparently.)

Best regards,
Niklas


2009/11/16 Ivan Herman <ivan@...>:

> Pfew...:-)
>
> Ivan
>
> P.S. Mark-the-elephant-hunter:-)
>
> Mark Birbeck wrote:
>> Hi Ivan/Niklas,
>>
>> 2009/11/16 Ivan Herman <ivan@...>:
>>> Hi Niklas,
>>>
>>> Niklas Lindström wrote:
>>>>> So is there an elephant?:-)
>>>> I haven't followed this discussion to closely, so I want to check if
>>>> this the following is considered:
>>>>
>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>> contain colon, and there is a prefix with the same name as the leading
>>>> part before that, right? Concrete (but contrieved) example:
>>>>
>>>> Given:
>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>
>>>> When:
>>>>     @resource="Talk:Linked_Data"
>>>>
>>>> Then:
>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>> might be expected?
>>>>
>>> Hm. You may found the elephant:-)
>>>
>>> Yes, in this case one would indeed get the example.org URI.
>>>
>>> The question is: is this use case so strong as to nullify the advantages
>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>> quite a lot but the user can of course put full URI-s into the value of
>>> @about...
>>>
>>> Thanks!
>>
>>
>> Whoah...slow down. :)
>>
>> "Talk:Linked_Data" is not a relative path!
>>
>> Forget prefixes, CURIEs, whatever...even if those things did not
>> exist, how would a URI processor know whether "Talk:" is a scheme or
>> just part of a relative path?
>>
>> RFC 3986 [1] addresses this in the following way:
>>
>>   A path segment that contains a colon character (e.g., "this:that")
>> cannot be used as the
>>   first segment of a relative-path reference, as it would be mistaken
>> for a scheme name.
>>   Such a segment must be preceded by a dot-segment (e.g.,
>> "./this:that") to make a
>>   relative-path reference.
>>
>> So, if people are using relative paths that contain colons, in the
>> wild, then there's a problem, and that problem is completely
>> independent of RDFa.
>>
>> Regards,
>>
>> Mark
>>
>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>
>> --
>> Mark Birbeck, webBackplane
>>
>> mark.birbeck@...
>>
>> 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)
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: [phone]
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>

[Niklas Lindström]

Another point though. Isn't there a problem if prefixes are declared
for existing protocols?

When prefixes are declared for e.g.:

    xmlns:http="http://www.w3.org/2006/http#"
    xmlns:tag="http://example.org/tagging#"

With the proposed rules ("unsafe CURIE or URI"), wouldn't these:

    about="http://example.org/me"
    resource="tag:example.org,2009:item:1"

be resolved against those prefixes (instead of as-is)?

Best regards,
Niklas


2009/11/16 Niklas Lindström <lindstream@...>:

> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
> that RFC 3986 is so precise about these things.
>
> (I should have known that -- I now recall reading that very same rule
> a couple of months ago when investigating the legality of non-escaped
> colons in URI:s. Only remembered half of it apparently.)
>
> Best regards,
> Niklas
>
>
> 2009/11/16 Ivan Herman <ivan@...>:
>> Pfew...:-)
>>
>> Ivan
>>
>> P.S. Mark-the-elephant-hunter:-)
>>
>> Mark Birbeck wrote:
>>> Hi Ivan/Niklas,
>>>
>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>> Hi Niklas,
>>>>
>>>> Niklas Lindström wrote:
>>>>>> So is there an elephant?:-)
>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>> this the following is considered:
>>>>>
>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>
>>>>> Given:
>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>
>>>>> When:
>>>>>     @resource="Talk:Linked_Data"
>>>>>
>>>>> Then:
>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>> might be expected?
>>>>>
>>>> Hm. You may found the elephant:-)
>>>>
>>>> Yes, in this case one would indeed get the example.org URI.
>>>>
>>>> The question is: is this use case so strong as to nullify the advantages
>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>> quite a lot but the user can of course put full URI-s into the value of
>>>> @about...
>>>>
>>>> Thanks!
>>>
>>>
>>> Whoah...slow down. :)
>>>
>>> "Talk:Linked_Data" is not a relative path!
>>>
>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>> just part of a relative path?
>>>
>>> RFC 3986 [1] addresses this in the following way:
>>>
>>>   A path segment that contains a colon character (e.g., "this:that")
>>> cannot be used as the
>>>   first segment of a relative-path reference, as it would be mistaken
>>> for a scheme name.
>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>> "./this:that") to make a
>>>   relative-path reference.
>>>
>>> So, if people are using relative paths that contain colons, in the
>>> wild, then there's a problem, and that problem is completely
>>> independent of RDFa.
>>>
>>> Regards,
>>>
>>> Mark
>>>
>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>
>>> --
>>> Mark Birbeck, webBackplane
>>>
>>> mark.birbeck@...
>>>
>>> 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)
>>
>> --
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: [phone]
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>>
>

[Ivan Herman-2]

That is probably correct. It is also a very bad authoring practice...

In more general terms, one could declare a number of strings as being
off-limit for CURIE-s. But I am not sure it is worth the trouble in
terms of usage.

Ivan



Niklas Lindström wrote:

> Another point though. Isn't there a problem if prefixes are declared
> for existing protocols?
>
> When prefixes are declared for e.g.:
>
>     xmlns:http="http://www.w3.org/2006/http#"
>     xmlns:tag="http://example.org/tagging#"
>
> With the proposed rules ("unsafe CURIE or URI"), wouldn't these:
>
>     about="http://example.org/me"
>     resource="tag:example.org,2009:item:1"
>
> be resolved against those prefixes (instead of as-is)?
>
> Best regards,
> Niklas
>
>
> 2009/11/16 Niklas Lindström <lindstream@...>:
>> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
>> that RFC 3986 is so precise about these things.
>>
>> (I should have known that -- I now recall reading that very same rule
>> a couple of months ago when investigating the legality of non-escaped
>> colons in URI:s. Only remembered half of it apparently.)
>>
>> Best regards,
>> Niklas
>>
>>
>> 2009/11/16 Ivan Herman <ivan@...>:
>>> Pfew...:-)
>>>
>>> Ivan
>>>
>>> P.S. Mark-the-elephant-hunter:-)
>>>
>>> Mark Birbeck wrote:
>>>> Hi Ivan/Niklas,
>>>>
>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>> Hi Niklas,
>>>>>
>>>>> Niklas Lindström wrote:
>>>>>>> So is there an elephant?:-)
>>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>>> this the following is considered:
>>>>>>
>>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>>
>>>>>> Given:
>>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>>
>>>>>> When:
>>>>>>     @resource="Talk:Linked_Data"
>>>>>>
>>>>>> Then:
>>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>>> might be expected?
>>>>>>
>>>>> Hm. You may found the elephant:-)
>>>>>
>>>>> Yes, in this case one would indeed get the example.org URI.
>>>>>
>>>>> The question is: is this use case so strong as to nullify the advantages
>>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>>> quite a lot but the user can of course put full URI-s into the value of
>>>>> @about...
>>>>>
>>>>> Thanks!
>>>>
>>>> Whoah...slow down. :)
>>>>
>>>> "Talk:Linked_Data" is not a relative path!
>>>>
>>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>>> just part of a relative path?
>>>>
>>>> RFC 3986 [1] addresses this in the following way:
>>>>
>>>>   A path segment that contains a colon character (e.g., "this:that")
>>>> cannot be used as the
>>>>   first segment of a relative-path reference, as it would be mistaken
>>>> for a scheme name.
>>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>>> "./this:that") to make a
>>>>   relative-path reference.
>>>>
>>>> So, if people are using relative paths that contain colons, in the
>>>> wild, then there's a problem, and that problem is completely
>>>> independent of RDFa.
>>>>
>>>> Regards,
>>>>
>>>> Mark
>>>>
>>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>>
>>>> --
>>>> Mark Birbeck, webBackplane
>>>>
>>>> mark.birbeck@...
>>>>
>>>> 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)
>>> --
>>>
>>> Ivan Herman, W3C Semantic Web Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: [phone]
>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>
>>>

--

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

[Shane McCarron]

I suppose a 'should not' admonition would be harmless.

Ivan Herman <ivan@...> wrote:

>That is probably correct. It is also a very bad authoring practice...
>
>In more general terms, one could declare a number of strings as being
>off-limit for CURIE-s. But I am not sure it is worth the trouble in
>terms of usage.
>
>Ivan
>
>
>
>Niklas Lindström wrote:
>> Another point though. Isn't there a problem if prefixes are declared
>> for existing protocols?
>>
>> When prefixes are declared for e.g.:
>>
>>     xmlns:http="http://www.w3.org/2006/http#"
>>     xmlns:tag="http://example.org/tagging#"
>>
>> With the proposed rules ("unsafe CURIE or URI"), wouldn't these:
>>
>>     about="http://example.org/me"
>>     resource="tag:example.org,2009:item:1"
>>
>> be resolved against those prefixes (instead of as-is)?
>>
>> Best regards,
>> Niklas
>>
>>
>> 2009/11/16 Niklas Lindström <lindstream@...>:
>>> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
>>> that RFC 3986 is so precise about these things.
>>>
>>> (I should have known that -- I now recall reading that very same rule
>>> a couple of months ago when investigating the legality of non-escaped
>>> colons in URI:s. Only remembered half of it apparently.)
>>>
>>> Best regards,
>>> Niklas
>>>
>>>
>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>> Pfew...:-)
>>>>
>>>> Ivan
>>>>
>>>> P.S. Mark-the-elephant-hunter:-)
>>>>
>>>> Mark Birbeck wrote:
>>>>> Hi Ivan/Niklas,
>>>>>
>>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>>> Hi Niklas,
>>>>>>
>>>>>> Niklas Lindström wrote:
>>>>>>>> So is there an elephant?:-)
>>>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>>>> this the following is considered:
>>>>>>>
>>>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>>>
>>>>>>> Given:
>>>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>>>
>>>>>>> When:
>>>>>>>     @resource="Talk:Linked_Data"
>>>>>>>
>>>>>>> Then:
>>>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>>>> might be expected?
>>>>>>>
>>>>>> Hm. You may found the elephant:-)
>>>>>>
>>>>>> Yes, in this case one would indeed get the example.org URI.
>>>>>>
>>>>>> The question is: is this use case so strong as to nullify the advantages
>>>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>>>> quite a lot but the user can of course put full URI-s into the value of
>>>>>> @about...
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Whoah...slow down. :)
>>>>>
>>>>> "Talk:Linked_Data" is not a relative path!
>>>>>
>>>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>>>> just part of a relative path?
>>>>>
>>>>> RFC 3986 [1] addresses this in the following way:
>>>>>
>>>>>   A path segment that contains a colon character (e.g., "this:that")
>>>>> cannot be used as the
>>>>>   first segment of a relative-path reference, as it would be mistaken
>>>>> for a scheme name.
>>>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>>>> "./this:that") to make a
>>>>>   relative-path reference.
>>>>>
>>>>> So, if people are using relative paths that contain colons, in the
>>>>> wild, then there's a problem, and that problem is completely
>>>>> independent of RDFa.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mark
>>>>>
>>>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>>>
>>>>> --
>>>>> Mark Birbeck, webBackplane
>>>>>
>>>>> mark.birbeck@...
>>>>>
>>>>> 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)
>>>> --
>>>>
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: [phone]
>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>
>>>>
>
>--
>
>Ivan Herman, W3C Semantic Web Activity Lead
>Home: http://www.w3.org/People/Ivan/
>mobile: [phone]
>PGP Key: http://www.ivan-herman.net/pgpkey.html
>FOAF: http://www.ivan-herman.net/foaf.rdf
>

[Mark Birbeck-4]

Hi Niklas,

I'm not sure you can call it a "problem". As long as the rules of
interpretation are clear, then authors are free to do what they want
within the context of those rules.

In this particular case, I'd say that if someone defines a
prefix-mapping that matches a URL scheme, then hopefully, they know
what they are doing.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)



2009/11/17 Niklas Lindström <lindstream@...>:

> Another point though. Isn't there a problem if prefixes are declared
> for existing protocols?
>
> When prefixes are declared for e.g.:
>
>    xmlns:http="http://www.w3.org/2006/http#"
>    xmlns:tag="http://example.org/tagging#"
>
> With the proposed rules ("unsafe CURIE or URI"), wouldn't these:
>
>    about="http://example.org/me"
>    resource="tag:example.org,2009:item:1"
>
> be resolved against those prefixes (instead of as-is)?
>
> Best regards,
> Niklas
>
>
> 2009/11/16 Niklas Lindström <lindstream@...>:
>> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
>> that RFC 3986 is so precise about these things.
>>
>> (I should have known that -- I now recall reading that very same rule
>> a couple of months ago when investigating the legality of non-escaped
>> colons in URI:s. Only remembered half of it apparently.)
>>
>> Best regards,
>> Niklas
>>
>>
>> 2009/11/16 Ivan Herman <ivan@...>:
>>> Pfew...:-)
>>>
>>> Ivan
>>>
>>> P.S. Mark-the-elephant-hunter:-)
>>>
>>> Mark Birbeck wrote:
>>>> Hi Ivan/Niklas,
>>>>
>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>> Hi Niklas,
>>>>>
>>>>> Niklas Lindström wrote:
>>>>>>> So is there an elephant?:-)
>>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>>> this the following is considered:
>>>>>>
>>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>>
>>>>>> Given:
>>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>>
>>>>>> When:
>>>>>>     @resource="Talk:Linked_Data"
>>>>>>
>>>>>> Then:
>>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>>> might be expected?
>>>>>>
>>>>> Hm. You may found the elephant:-)
>>>>>
>>>>> Yes, in this case one would indeed get the example.org URI.
>>>>>
>>>>> The question is: is this use case so strong as to nullify the advantages
>>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>>> quite a lot but the user can of course put full URI-s into the value of
>>>>> @about...
>>>>>
>>>>> Thanks!
>>>>
>>>>
>>>> Whoah...slow down. :)
>>>>
>>>> "Talk:Linked_Data" is not a relative path!
>>>>
>>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>>> just part of a relative path?
>>>>
>>>> RFC 3986 [1] addresses this in the following way:
>>>>
>>>>   A path segment that contains a colon character (e.g., "this:that")
>>>> cannot be used as the
>>>>   first segment of a relative-path reference, as it would be mistaken
>>>> for a scheme name.
>>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>>> "./this:that") to make a
>>>>   relative-path reference.
>>>>
>>>> So, if people are using relative paths that contain colons, in the
>>>> wild, then there's a problem, and that problem is completely
>>>> independent of RDFa.
>>>>
>>>> Regards,
>>>>
>>>> Mark
>>>>
>>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>>
>>>> --
>>>> Mark Birbeck, webBackplane
>>>>
>>>> mark.birbeck@...
>>>>
>>>> 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)
>>>
>>> --
>>>
>>> Ivan Herman, W3C Semantic Web Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: [phone]
>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>
>>>
>>
>

[Niklas Lindström]

Ivan, Mark,

but people are alredy doing it [1] [2] -- including the W3C [3]!

[1] = <http://www.jenitennison.com/blog/node/133>
[2] = <http://www.holygoat.co.uk/projects/tags/>
[3] = <http://www.w3.org/TR/HTTP-in-RDF10/>

So neither declaring it bad practise nor forbidding it syntactically
seems really proper to me..

And as for "people knowing what they are doing", is that really enough
when introducing something that would drastically change the
interpreted values in @about/@typeof (when the protocol names have
been declared as prefixes "somewhere higher up"); and in a non-obvious
way for someone looking at just the URI:s?

To do this just feels brittle to me. (And, I fear, would increase the
dislike of CURIEs/prefix mechanisms.)

Of course, I also realise that not doing this, while introducing
"CURIE or URI-if-undefined-prefix" rules (where CURIE was the
precedent and "as URI" is new), may be confusing as well. Since it
would be very hard to distinguish between the syntax allowed in
@property and @rel, and the "plain URI only" attributes.. (The
attributes will have same *apparent* lexical space, but in some of
them, defined prefixes would have profound effects..)

.. But I have no alternate suggestions either I'm afraid. Apart
perhaps from redesign/new syntax such as if "[...]" could be used to
expand prefixes everywhere, e.g. about="[foaf]Person",
property="[foaf]homepage".. But that's probably awkward.

(.. Or just (ducks and covers) "skip CURIEs altogether and let XML
users use the old, ugly ENTITY mechanism for shortening". I sure
prefer using prefixes+CURIEs to replace that.. Not the least since in
HTML scenarios it would probably be a no-go anyway.)

Best regards,
Niklas



2009/11/17 Ivan Herman <ivan@...>:

> That is probably correct. It is also a very bad authoring practice...
>
> In more general terms, one could declare a number of strings as being
> off-limit for CURIE-s. But I am not sure it is worth the trouble in
> terms of usage.
>
> Ivan
>
>
>
> Niklas Lindström wrote:
>> Another point though. Isn't there a problem if prefixes are declared
>> for existing protocols?
>>
>> When prefixes are declared for e.g.:
>>
>>     xmlns:http="http://www.w3.org/2006/http#"
>>     xmlns:tag="http://example.org/tagging#"
>>
>> With the proposed rules ("unsafe CURIE or URI"), wouldn't these:
>>
>>     about="http://example.org/me"
>>     resource="tag:example.org,2009:item:1"
>>
>> be resolved against those prefixes (instead of as-is)?
>>
>> Best regards,
>> Niklas
>>
>>
>> 2009/11/16 Niklas Lindström <lindstream@...>:
>>> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
>>> that RFC 3986 is so precise about these things.
>>>
>>> (I should have known that -- I now recall reading that very same rule
>>> a couple of months ago when investigating the legality of non-escaped
>>> colons in URI:s. Only remembered half of it apparently.)
>>>
>>> Best regards,
>>> Niklas
>>>
>>>
>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>> Pfew...:-)
>>>>
>>>> Ivan
>>>>
>>>> P.S. Mark-the-elephant-hunter:-)
>>>>
>>>> Mark Birbeck wrote:
>>>>> Hi Ivan/Niklas,
>>>>>
>>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>>> Hi Niklas,
>>>>>>
>>>>>> Niklas Lindström wrote:
>>>>>>>> So is there an elephant?:-)
>>>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>>>> this the following is considered:
>>>>>>>
>>>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>>>
>>>>>>> Given:
>>>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>>>
>>>>>>> When:
>>>>>>>     @resource="Talk:Linked_Data"
>>>>>>>
>>>>>>> Then:
>>>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>>>> might be expected?
>>>>>>>
>>>>>> Hm. You may found the elephant:-)
>>>>>>
>>>>>> Yes, in this case one would indeed get the example.org URI.
>>>>>>
>>>>>> The question is: is this use case so strong as to nullify the advantages
>>>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>>>> quite a lot but the user can of course put full URI-s into the value of
>>>>>> @about...
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Whoah...slow down. :)
>>>>>
>>>>> "Talk:Linked_Data" is not a relative path!
>>>>>
>>>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>>>> just part of a relative path?
>>>>>
>>>>> RFC 3986 [1] addresses this in the following way:
>>>>>
>>>>>   A path segment that contains a colon character (e.g., "this:that")
>>>>> cannot be used as the
>>>>>   first segment of a relative-path reference, as it would be mistaken
>>>>> for a scheme name.
>>>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>>>> "./this:that") to make a
>>>>>   relative-path reference.
>>>>>
>>>>> So, if people are using relative paths that contain colons, in the
>>>>> wild, then there's a problem, and that problem is completely
>>>>> independent of RDFa.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mark
>>>>>
>>>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>>>
>>>>> --
>>>>> Mark Birbeck, webBackplane
>>>>>
>>>>> mark.birbeck@...
>>>>>
>>>>> 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)
>>>> --
>>>>
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: [phone]
>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>
>>>>
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: [phone]
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>

[Ivan Herman-2]

Niklas Lindström wrote:

> Ivan, Mark,
>
> but people are alredy doing it [1] [2] -- including the W3C [3]!
>
> [1] = <http://www.jenitennison.com/blog/node/133>
> [2] = <http://www.holygoat.co.uk/projects/tags/>
> [3] = <http://www.w3.org/TR/HTTP-in-RDF10/>
>
> So neither declaring it bad practise nor forbidding it syntactically
> seems really proper to me..
>

I think Shane's proposal, ie, that the document would say "should not do
it" gives the right balance. I agree forbidding it is too much; the
'should not' is not bad practice, just a kind of a warning that people,
well, should avoid doing this...

My feeling is that this type of usage is (and should be:-) rare, and the
gains vastly overweight the possible complications. Obviously, this is
not a technical argument...

Ivan

> And as for "people knowing what they are doing", is that really enough
> when introducing something that would drastically change the
> interpreted values in @about/@typeof (when the protocol names have
> been declared as prefixes "somewhere higher up"); and in a non-obvious
> way for someone looking at just the URI:s?
>
> To do this just feels brittle to me. (And, I fear, would increase the
> dislike of CURIEs/prefix mechanisms.)
>
> Of course, I also realise that not doing this, while introducing
> "CURIE or URI-if-undefined-prefix" rules (where CURIE was the
> precedent and "as URI" is new), may be confusing as well. Since it
> would be very hard to distinguish between the syntax allowed in
> @property and @rel, and the "plain URI only" attributes.. (The
> attributes will have same *apparent* lexical space, but in some of
> them, defined prefixes would have profound effects..)
>
> .. But I have no alternate suggestions either I'm afraid. Apart
> perhaps from redesign/new syntax such as if "[...]" could be used to
> expand prefixes everywhere, e.g. about="[foaf]Person",
> property="[foaf]homepage".. But that's probably awkward.
>
> (.. Or just (ducks and covers) "skip CURIEs altogether and let XML
> users use the old, ugly ENTITY mechanism for shortening". I sure
> prefer using prefixes+CURIEs to replace that.. Not the least since in
> HTML scenarios it would probably be a no-go anyway.)
>
> Best regards,
> Niklas
>
>
>
> 2009/11/17 Ivan Herman <ivan@...>:
>> That is probably correct. It is also a very bad authoring practice...
>>
>> In more general terms, one could declare a number of strings as being
>> off-limit for CURIE-s. But I am not sure it is worth the trouble in
>> terms of usage.
>>
>> Ivan
>>
>>
>>
>> Niklas Lindström wrote:
>>> Another point though. Isn't there a problem if prefixes are declared
>>> for existing protocols?
>>>
>>> When prefixes are declared for e.g.:
>>>
>>>     xmlns:http="http://www.w3.org/2006/http#"
>>>     xmlns:tag="http://example.org/tagging#"
>>>
>>> With the proposed rules ("unsafe CURIE or URI"), wouldn't these:
>>>
>>>     about="http://example.org/me"
>>>     resource="tag:example.org,2009:item:1"
>>>
>>> be resolved against those prefixes (instead of as-is)?
>>>
>>> Best regards,
>>> Niklas
>>>
>>>
>>> 2009/11/16 Niklas Lindström <lindstream@...>:
>>>> Ah, but indeed! Good elephant-hunting Mark! ;) It's quite comforting
>>>> that RFC 3986 is so precise about these things.
>>>>
>>>> (I should have known that -- I now recall reading that very same rule
>>>> a couple of months ago when investigating the legality of non-escaped
>>>> colons in URI:s. Only remembered half of it apparently.)
>>>>
>>>> Best regards,
>>>> Niklas
>>>>
>>>>
>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>> Pfew...:-)
>>>>>
>>>>> Ivan
>>>>>
>>>>> P.S. Mark-the-elephant-hunter:-)
>>>>>
>>>>> Mark Birbeck wrote:
>>>>>> Hi Ivan/Niklas,
>>>>>>
>>>>>> 2009/11/16 Ivan Herman <ivan@...>:
>>>>>>> Hi Niklas,
>>>>>>>
>>>>>>> Niklas Lindström wrote:
>>>>>>>>> So is there an elephant?:-)
>>>>>>>> I haven't followed this discussion to closely, so I want to check if
>>>>>>>> this the following is considered:
>>>>>>>>
>>>>>>>> This usage will "muddle the waters" in cases when the relative URI:s
>>>>>>>> contain colon, and there is a prefix with the same name as the leading
>>>>>>>> part before that, right? Concrete (but contrieved) example:
>>>>>>>>
>>>>>>>> Given:
>>>>>>>>     - base URI: <http://en.wikipedia.org/wiki/>
>>>>>>>>     - prefix Talk: <http://example.org/schema/talk#>
>>>>>>>>
>>>>>>>> When:
>>>>>>>>     @resource="Talk:Linked_Data"
>>>>>>>>
>>>>>>>> Then:
>>>>>>>>     - URI becomes < http://example.org/schema/talk#Linked_Data>,
>>>>>>>> instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
>>>>>>>> might be expected?
>>>>>>>>
>>>>>>> Hm. You may found the elephant:-)
>>>>>>>
>>>>>>> Yes, in this case one would indeed get the example.org URI.
>>>>>>>
>>>>>>> The question is: is this use case so strong as to nullify the advantages
>>>>>>> of using CURIE-s in @about? Indeed, wikipedia uses such URI-s with ':'
>>>>>>> quite a lot but the user can of course put full URI-s into the value of
>>>>>>> @about...
>>>>>>>
>>>>>>> Thanks!
>>>>>> Whoah...slow down. :)
>>>>>>
>>>>>> "Talk:Linked_Data" is not a relative path!
>>>>>>
>>>>>> Forget prefixes, CURIEs, whatever...even if those things did not
>>>>>> exist, how would a URI processor know whether "Talk:" is a scheme or
>>>>>> just part of a relative path?
>>>>>>
>>>>>> RFC 3986 [1] addresses this in the following way:
>>>>>>
>>>>>>   A path segment that contains a colon character (e.g., "this:that")
>>>>>> cannot be used as the
>>>>>>   first segment of a relative-path reference, as it would be mistaken
>>>>>> for a scheme name.
>>>>>>   Such a segment must be preceded by a dot-segment (e.g.,
>>>>>> "./this:that") to make a
>>>>>>   relative-path reference.
>>>>>>
>>>>>> So, if people are using relative paths that contain colons, in the
>>>>>> wild, then there's a problem, and that problem is completely
>>>>>> independent of RDFa.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> [1] <http://www.ietf.org/rfc/rfc3986.txt>
>>>>>>
>>>>>> --
>>>>>> Mark Birbeck, webBackplane
>>>>>>
>>>>>> mark.birbeck@...
>>>>>>
>>>>>> 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)
>>>>> --
>>>>>
>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>> Home: http://www.w3.org/People/Ivan/
>>>>> mobile: [phone]
>>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>>
>>>>>
>> --
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: [phone]
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>>

--

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

[Ben Adida-2]

Many good comments and good elephant finding and hunting :)

I'm still concerned about the complexity we would be introducing in
@about and @resource when we already have safe CURIEs, meaning the use
cases are already addressed, I believe.

That said, I also see the benefit of applying the general rule of CURIE
falling back into URLS when the prefix isn't defined... that's kind of nice.

I'm not entirely sure which side I fall on right now, but if we have a
very clear algorithm that we all agree on, I guess I could be convinced
to go with this new URI-fallback mechanism.

-Ben