Re: DTB status (on today's agenda)

> 
> Let me try to write it as a grammar - yes context sensitive - but farily 
> simple, isn't it?

What does "it" refer to? Sandro's proposal?

It has too many problems besides context sensitivity.
Although I tried to put it as a joke about the difficulty to remember all
the rules, it was actually a very serious problem. Such complex macro rules
for what? A concatenation macro? 

And the fact that it is easy to implement is not the right argument. In a
presentation language it should be easy to *understand*.


	--michael  



> ANGLEBRACKIRI     ::= '<' IRIRef '>'
> 
> STRING            ::= '"' ANYSTRINGWITHOUTQUOTES '"'
> 
> CURIE  	          ::=  PNAME_LN | PNAME_NS
> 
> Const             ::= ANGLEBRACKIRI
>                      | CURIE
>                      | STRING^^ANGLEBRACKIRI
>                      | STRING^^CURIE
> 
> 
> The context-dependent definition of Const meaning
> somewhat in  flex/bison style:
> 
> 
> Const : ANGLEBRACKIRI
>         { /* treat as "ANYSTRING"^^<http://www.w3.org/2007/rif#iri> */}
>        | STRING^^ANGLEBRACKIRI
>         { /* treat as  STRING^^ANGLEBRACKIRI */}
>        | STRING^^CURIE
>         { /* treat as STRING^^expand(CURIE) */}
>        | CURIE
>         {/*treat as "expand(CURIE)"^^<http://www.w3.org/2007/rif#iri> */}
> 
> where 'expand(CURIE)' looks up the prefix table and does concatenation 
> as usual.
> 
> For further details on PNAME_LN | PNAME_NS, see the productions for 
> PrefixedName from the SPARQL grammar.
> 
> 
> I find the above
> * easy enough to implement
> * it extends the Turtle/N3 usage and brings it together with RIF,
>    which I find nice
> * it covers the simplified proposal of Michael without the ambiguity
>    problem of the http: mailto: or other possible prefix which are also
>    often used IRI schemes
> 
> As for the last point, Michael, even if "the above rules" seem "too 
> complex" [...] to retain in [your] diminishing pool of long-term memory 
> cells" they basically cover your simplified proposal without the ugly 
> side effect of having ambiguity, since long IRIs are always either 
> quoted or in angle brackets.
> 
> Axel
> 
> 
> Michael Kifer wrote:
> >> Michael Kifer wrote:
> >>>> Dear all,
> >>>>
> >>>> since DTB status is on the agenda today, I basically want to clarify in 
> >>>> the call today the following issues. I was anyway a bit occupied with 
> >>>> other things, but basically, I am still stuck, as long as these issues 
> >>>> are open, because any switch on them would mean unnecessary additional 
> >>>> work on editing over the whole document (as opposed doing it in one go 
> >>>> when they are clarified).
> >>>>
> >>>> ==============================================================================
> >>>>
> >>>>
> >>>> 1) As for CURIEs, is [1] a proposal which woulc achieve a majority?
> >>>> I would like it. I postponed further editing before the CURIE issues is 
> >>>> solved or before at least it was discussed in the Telconf., since I 
> >>>> don't want to change everything back again, when we decide something.
> >>>>
> >>>> I suggest to
> >>>>
> >>>> PROPOSE: Adopt the CURIE proposals of [1] for RIF's presentation syntax.
> >>>>
> >>>> [1] Sandro's final CURIE proposal: 
> >>>> http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0134.html
> >>> As discussed, this still has the old problems that interpretation of the
> >>> macro : depends on the context and is too complex. Why not use a simple
> >>> concatenation macro and be done with it?
> >> Well, don't think this is a problem if "marcos" ie. prefixes are not 
> >> expanded within quotes and angle brackets. Why ist is a problem if 
> >> quotes or angle brackets escape the macro expansion? Otherwise, you can 
> >> get ambiguities.
> >>
> >> Axel
> > 
> > Here are the problems again:
> > 
> >    1.  Point Brackets
> > 
> >          <http://purl.org/dc/terms/creator>
> > 
> > same as "http://purl.org/dc/terms/creator"^^rif:iri  - ok
> > 
> >    2.  CURIEs
> > 
> >     	 after:   PREFIX("dc", "http://purl.org/dc/terms/").
> > 
> >          dc:creator
> > 
> > presumably "http://purl.org/dc/terms/creator"^^rif:iri - ok
> > 
> >    3.  Data Value (using Pointy Brackets for rif:uri)
> > 
> >          "http://purl.org/dc/terms/creator"^^<http://www.w3.org/2007/rif#iri>
> > 
> > Not ok: <http://www.w3.org/2007/rif#iri> is supposed to stand for
> > "http://purl.org/dc/terms/creator"^^rif:iri, so we have context sensitivity
> > here.
> > 
> >    4.  Data Value (using CURIE rif:uri)
> > 
> > 	 after:   PREFIX("rif", "http://www.w3.org/2007/rif#").
> > 
> >          "http://purl.org/dc/terms/creator"^^rif:iri
> > 
> > Context sensitivity. rif:iri here is supposed to stand for
> > http://www.w3.org/2007/rif#iri. But according to (2) above it stands for
> > "http://www.w3.org/2007/rif#iri"^^rif:iri.
> > 
> > If you are saying that rif:iri cannot be expanded into what it stands for
> > after the ^^ then it is even worse than context sensitivity.
> > 
> > In addition, I find the above rules too complex for me to retain in my
> > diminishing pool of long-term memory cells.
> > I prefer a simple macro that is akin to (but much simpler) than
> > C macros. XML entities is an example of this, but most people find them
> > ugly and they need to be defined in the presentation syntax anyway.
> > For instance,
> > 
> >     dc:creator^^rif:iri
> > 
> > 
> >     If the above is unacceptable, in the interests of moving things
> > forward, I think the following could be tolerated, although it is still
> > context-sensitive. It was proposed in the past by somebody (maybe not
> > exactly this):
> > 
> > 1. After ^^ a curie expands by simple concatenation:
> > 
> >     "foobar"^^rif:iri
> >     -->
> >     "foobar"^^http://www.w3.org/2007/rif#iri
> > 
> > 2. Standalone: expands into concatenation, enclosed in "..." and followed
> >    by ^^http://www.w3.org/2007/rif#iri:
> > 
> >     dc:creator
> >     -->
> >     "http://purl.org/dc/terms/creator"^^http://www.w3.org/2007/rif#iri
> > 
> > This is simple enough and is sellable.
> > 
> > There is still an issue of what to do if somebody defines http as a prefix.
> > Also, leaving something like http://www.w3.org/2007/rif#iri hand around
> > without delimiters is problematic, especially since IRIs have many
> > different schemes. One possibility is to delimit these iris with single quotes:
> > 
> >     "http://purl.org/dc/terms/creator"^^'http://www.w3.org/2007/rif#iri'
> > 
> > or with double quotes.
> > 
> > 
> > 	--michael  
> 
> 
> -- 
> 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 Wednesday, 30 April 2008 07:02:11 UTC