Re: [SWC] comments/review SWC - replies to Jos' replies on part 1 of the review.

>> There are more than one syntaxes, e.g. the RDF/XML syntax.
> 
> there is ONE abstract syntax, defined in the RDF-Concepts document. 
> RDF/XML is a concrete syntax.

ok, then write

"The abstract syntax of the names in these sets [...]"


>> It is weird. Something that "conforms" conforms to *something*, so 
>> what is this something here?
> 
> The set of data types you consider for the RIF document.

Ok ,then write it:

"Definition. Let T be the set of considered datatypes. A datatype map D
is a conforming datatype map if it satisfies the following conditions:"

-->
"Definition. Let T be the set of considered datatypes. A datatype map D
is \emph{conforming with T} if it satisfies the following conditions:"


>> 
>> "a"^^xsd:string = "b"^^xsd:string
>> 
>> You imply that this is interpreted as an inconsistency. In simple 
>> RDF such an equality is not an inconsistency. Anyway, If you add 
>> the clarifying remark I talked about before, you can simply 
>> reference it here again and just point out that the reader shall be
>>  aware of this treatment in RIF. Just wanted a pointer, because I 
>> think it is not obvious.
> 
> There is a discussion here of why there is an inconsistency.  In 
> addition, I extended the example just above the section to include 
> the example of plain literals versus strings. is that good enough for
>  you?
> 


It is better, yes, I can live with it, I guess, if nobody else insists,
even without more clarification.
The same holds for the other comments that I skip from now on

>>> 
>>> I added the text "Profiles are assumed to be ordered.".  Do you
>>> think this is sufficient?
>> 
>> Profiles are assumed to be ordered (see ... below).
> 
> The added text clarifies that there is in order.  I don't see the
> point of forward references, which will only help to confuse the
> reader, rather than clarifying anything.

I mentioned it, because I was confused because I missed a link or 
pointer to where it was explained when reading it first.

> "Local constant <tt>s-u'</tt> that is not used in C and is obtained from  <tt>"s"^^u</tt>"
> 
> Is this better? 

hmmm, better yes, ideal no. I mean, yes, I got the idea, but I still see 
no guideline how to implement this here... on the other hand, maybe that 
would go to far, so, I can live with it.


>> that blank nodes labels are disambiguated beforehand:
> 
> This is only the necessary if you do a merge. the graphs are 
 > not submerged here; the embedding of each graph gets its own
> existential quantifier.

I didn't ask you to *submerge* anything, but now my question is 
clarified. :-)

>> because then G is a set of *g*raphs, R is a *r*uleset and we use S for the combination (I wondered about S for the graph set anyway...)
> 
> S is commonly used for graphs (e.g., RDF-semantics), that is why I'm using it. 

ok, but that wasn't the point, you asked for an alternative suggestion, 
I made one, which at least in the document is not ambiguous.
You can always revert to some font-tricking, e.g. bold face C.


>> I think I would like to have the pred for illxml in DTB... since people who want to *implement* rif-rfd, need to implement it anyway... or no?
> 
> No, the predicate does not need to be implemented.  It is a very simple axiomatization, depending on the vocabulary of the RDF graph.
> 
> There is, therefore, no way of defining this predicate without the context of an RDF graph, because ill-typed XML literals cannot 
> be written in RIF.

Yes, but: So, what are you axiomatizing here then???

({Forall (ex:illxml(tr("s"^^rdf:XMLLiteral)))} for every non-well-typed 
literal of the form (s, rdf:XMLLiteral) in VTL) union

The axioms can't be written either... So, the problem is exactly the 
same. I anyway assume you believe me that in my rule system I can, 
without any problem, write a built-in which exactly takes a literal as 
input and checks whether its symbol space is xmlliteral and checks 
wether it is ill-defined, yes?

cheers,
Axel

Received on Monday, 30 June 2008 17:20:55 UTC