Re: InverseFunctional properties are the new URI?

* Damian Steer <> [2004-07-30 10:26+0100]
> Hash: SHA1
> Sandro Hawke wrote:
> |>Actually, I think I'll disagree with myself before anyone else does.
> |>Taking Dan's point, the ordering could well be IFP > no URI/IFP > URI
> |>because the URI is in no way a property of the described object whereas
> |>all other properties are.
> |
> |
> | Why isn't something's URI an IFP property of the thing?   TimBL calls
> | that property log:uri, I think.   For a while, I generalized it
> | slightly to u:uname [1].
> |
> |      -- sandro
> |
> | [1]
> Hmm. Why not use rdf:resource and rdf:about (being samePropertyAs)?
> Backwards compatible, and parsers will just need to de-bless those
> attributes. For example:
> <rdf:Description newrdf:about="">
> ~  <a:prop newrdf:resource=""/>

If newrdf:resource is unblessed, ie. 'just a property' this is same as 


...which isn't quite what you want, I think. You'd also run into
back-compatibility problems since properties can repeat, while rdf:about
can't. Also if rdf:resource is a property, it would appear in a
different syntactic role, ie. as an element. And rdf:about could appear
there too. Thinking about it, it'd be total chaos :)

Nice try though! Maybe if all next-gen serializers were constrained to
write out a constrained (and possibly lossy) idiom...? Hmm even then I
think the property elements couldn't work in old and new worlds at same
time (eg. are these literal-valued or resource-valued properties? do
they take the string form of a URI? if so, property elements get written

Or maybe I misunderstand the above example. Perhaps if a:prop was
owl:sameAs it Might Just Work? If it wasn't for the back-compatibility
aspect, this would be a simplification of the syntax. With
back-compatiblity in mind, it looks somewhat more scary...



> produces what you want. s/newrdf/rdf/.
> Damian
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> iD8DBQFBChQxAyLCB+mTtykRApzZAJ0bYLuIF0h/S7U1+CT97vwtPZ6FLACg2vcx
> CLEM2dyc5Qm36+WyaDj82gw=
> =llMw

Received on Friday, 30 July 2004 05:57:39 UTC