Re: URIs in @rel and @property...

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@w3.org>:
> 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@gmail.com>:
>>> 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@w3.org>:
>>>> Pfew...:-)
>>>>
>>>> Ivan
>>>>
>>>> P.S. Mark-the-elephant-hunter:-)
>>>>
>>>> Mark Birbeck wrote:
>>>>> Hi Ivan/Niklas,
>>>>>
>>>>> 2009/11/16 Ivan Herman <ivan@w3.org>:
>>>>>> 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@webBackplane.com
>>>>>
>>>>> 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: +31-641044153
>>>> 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: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>

Received on Tuesday, 17 November 2009 15:52:26 UTC