incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <>
Subject Re: apply-method for language
Date Wed, 22 Jun 2011 14:03:11 GMT

On 22 Jun 2011, at 15:28, Reto Bachmann-Gmuer wrote:

> On Wed, Jun 22, 2011 at 3:11 PM, Henry Story <> wrote:
> On 22 Jun 2011, at 13:20, Reto Bachmann-Gmuer wrote:
>> On Tue, Jun 21, 2011 at 3:01 PM, Henry Story <> wrote:
>> On 21 Jun 2011, at 08:23, Reto Bachmann-Gmuer wrote:
>>> Do you think you have some time today to demonstrate how things work in the unit
tests? Afaict the examples you wrote in the comments, e.g. the one with (FOAF.knows)(g.bnode("Danny
Ayers"('en))) cannot work.
>> I'll start doing that now.
>> Let me know if you need some help. It would be great if we could close that issue
today or tomorrow.
> I simplified the EasyGraph, added an initial LangId class just to get going, and filled
in the unit tests. They should
> work but don't . I need to write a couple of things, so I checked it in, in case you
can see what the problem may be.
> I'll look at it.
> Some ideas: one could rename EasyGraph(Node) to EzGraph(Node). Then it contains the z
of Clerezza (and of Zorro too ;-) 
> I have removed the "Builder" in "LiteralBuilder" The Literal is not a Builder. It's just
that Scala makes it easy to map between literals.
> It's an thing that returns a typedLiteral when adding a type, a plain literal when adding
a language and which dynamically convert to xsd:string typedLiteral, don't see wha's wrong
with "builder".

It's no more a Builder than your TypedLiteralImpl is a builder. All constructors are builders
if you want to look at it that way, but we don't add ...Builder to every class. Indeed EzLiteral
is just a plain literal. 

case class EzLiteral(lexicalForm: String) extends Literal

You can map a plain literal to a typed literal of course. Numbers can be mapped to other numbers
that does not make them builders. Thinking in terms of builders is still very procedural.

> "an english string" :en "an english string"@en 
> The new syntax is with a ":"-method on the new Language class?

No, that was valid n3 above.

Though I was thinking of changing the + method in your NameSpace to  :
The problem with : is that 

The associativity of an operator is determined by the operator’s last character. Operators
ending in a colon ‘:’ are right-associative. All other operators are leftassociative.

So one should try out what that means in practice.

> is both correct in rdf semantics and available in n3. In any case it is a good way to
think of the meaning of @ or ^^
> They are maps from strings to literals. That is indeed how they are defined in the RDF
Semantics spec.
> Right, that's why there is this dynamic conversion from String to LiteralBuilder. Because
you can apply a language or a type to a String and then it becomes a literal (or a UriRef
for that mather, with the .uri method).

yes, there are dynamic conversions from String because we can't change java. But really 

java:java.lang.String owl:sameAs rdf:PlainLiteral (or whatever the name for rdf plain literals

If you look at the end of section 7.4 of "RDF Semantics"
you will find the following transformation rules

xsd 1a	   uuu aaa "sss".	uuu aaa "sss"^^xsd:string .
xsd 1b	   uuu aaa "sss"^^xsd:string .	uuu aaa "sss".

ie: xsd:string is the identity relations for strings, like the +0 or *1 functions  for numbers.

Social Web Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message