Re: Proposal for 'URIs everywhere'

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