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?


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 06:32:42 UTC