Re: Consts/CURIEs in PS (was Re: DTB status (on today's agenda) )

> 
> Sandro Hawke wrote:
> > Okay, I think I see a consensus here (more or less proposed by Jos and
> > Michael at different times):
> > 
> > (1) "foo"^^<bar>
> > 
> > This is the normal, full syntax for constants.  For example:
> > 
> >     "http://purl.org/dc/terms/creator"^^<http://www.w3.org/2007/rif#iri>
> > 
> > (2)  foo:bar    
> > 
> > is shorthand for
> > 
> >     "expand(foo)bar"^^<http://www.w3.org/2007/rif#iri>
> > 
> > except on the right-hand-side of a ^^.
> > 
> > (3) "foo"^^bar:baz
> > 
> > is shorthand for
> > 
> >     "foo"^^<expand(bar)baz>
> > 
> > This means that the CURIE syntax (a:b) is context sensitive; it's read
> > differently on the right-hand-side of ^^.
> > 
> > (4) <foo>
> > 
> > This is not allowed.  The pointy-brackets are only allowed as part of
> > the ^^ construct. Maybe someday we can figure out a way to allow it, but
> > right now it has problems.
> 
> This is allowed in N3, etc. and the grammar is very simple. so, if we 
> allow context-sensitivity, we can savely allow it to expand to
> 
> "foo"^^<http://www.w3.org/2007/rif#iri>
> 
> There is not real reason to allow context-sensitivity in one case and 
> forbid it in another.

Except that this adds more context sensitive rules on top of already
existing context-sensitive rules.

> For the sake of compatibility, I opt for allowing it.

We are not talking about incompatibility -- just a subset of what some
other language has (N3). There are other schemes as well and it is not
clear why we should stick to every little detail of one particular schema.
Especially since we do not need this complication (notwithstanding your
next paragraph).

> As for the question why we need this ("I do not see why we need such 
> a macro in the first place, if in most case we will be using foo:bar."), 
> there are IRIs which cannot be written as foo:bar, assuming that bar 
> needs to be an ncname:
> e.g. <http://www.rif.org/>
> cannot be split into a prefix and an ncname.

Of course there are cases. The question is why do we need this in RIF?
Where are the examples where would you would desperately need to write
<http://www.rif.org/> vs. "http://www.rif.org/"^^rif:iri because doing so
would make your example look ugly? How many occurrences of this
kind of situation do we have?

Given that we already (almost) have ciries, I would say that other
shortcuts (integers, strings) have much higher priority.

> > (5) "foo"^^bar
>  >
> > is allowed for aliasing (I don't quite follow this), but doesn't
> > interact with the above.
> 
> I don't see for what we need this, but this should be only allowed if 
> bar is non-ambiguous, i.e. may not contain be confused with a CURIE.

I think Jos wanted it so that RIF datatypes would be equivalent to datatype
maps. But I never saw a use case where multiple identifiers would be needed
for the same datatype (as allowed by datatype maps).  Given that RIF
is an exchange language, it is unclear why can't systems always convert to
canonical datatype Ids?

Maybe Jos can clarify this?


> > ================================================================
> > 
> > If I'm understanding everyone correctly, we can all live with that.
> > Yes?
> 
> Please provide a grammar which clarifies (5). As for (4), as mentioned 
> before, I object against incompatibility with N3.

We are not talking about incompatibility - just not supporting everything
that N3 supports. As I said, there are other IRI schemes as well, and by
the same token one might object to not supporting them.


	--michael  


> Axel
> 
> >      -- Sandro
> > 
> > 
> 
> 
> -- 
> Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
> email: axel.polleres@deri.org  url: http://www.polleres.net/
> 
> rdfs:Resource owl:differentFrom xsd:anyURI .
> 
>

Received on Friday, 2 May 2008 23:36:57 UTC