Re: DTB status (on today's agenda)

> 
> Dear Michael,
> 
> Michael Kifer wrote:
> >> 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?
> 
> Sandro's proposal, yes.
> 
> > It has too many problems besides context sensitivity.
> 
> Well... maybe I am too dumb, but I fail to see this.

I do not know what to tell you.  I explained everything in an earlier email
and there was also a response from Sandro. You are not reading, and I am
tired of writing.

One clear sign that you are not reading is your offer to me (below) to
abandon my "strict position" that everything should be context free.
If you read what I wrote, I did abandon that position.
Your approach, however, is even worse than what I was initially objecting to.

	--michael  


> As the grammar should have shown (repeating myself here), Sandro's 
> proposal is
>   * 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 yours without the ambiguity
>      problem of the http: mailto: or other possible prefix which are also
>      often used IRI schemes
> 
> Over all, in my opinion it *IS* easy to understand, but we may agree
> to disagree here, you may just want to leave your strict position that 
> we are talking about a (context-free) *macro expansion* mechanism here, 
> we are not. I at least am talking about a Turtle/N3/SPARQL compatible
> IRI-prefix definition mechanism.
> 
> What are the "many problems besides" you are talking about?
> 
> > 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? 
> 
> Please look at the grammar: In what sense do you define "complex"?
> 
> > A concatenation macro? 
> 
> No, see above.
> 
> > And the fact that it is easy to implement is not the right argument. 
> 
> Well, it *is* - to my purely personal taste of course - a better 
> argument than: "let's rather take something ambiguous which we 
> deliberately only define by hand-waving" (current status)
> 
>  > In a presentation language it should be easy to *understand*.
> 
> I find it pretty easy to understand, also here we can agree to disagree. 
> Who else thinks it is too complex?
> 
> META-COMMENT (in human language, since we cannot agree on a syntax for 
> metadata either):
> 
> I think we should (just like for the metadata discussion), accept that 
> there are not always consensual solutions possible and we can nitpick 
> forever on those syntactical details, but we have to get on. By making 
> Sandro's proposal concrete with a grammar, I wanted to put something on 
> the table we can vote over. Apart from the arguable claim that it is 
> "too compex" I see no further technical problems remaining.
> 
> In the end, I think after the hard part of the semantics, where you, 
> Harold, and Jos did an incredibly good job, these comparably minor 
> issues seem to - strange enough - cost us much more time.
> 
> just my two cents,
> Axel
> 
> 
> 
> 
> > 	--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 .
> >>
> >>
> > 
> 
> 
> -- 
> 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 18:43:27 UTC