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

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@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
>>
>>

-- 

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