Re: Abstract syntax: an attempt

Brian McBride wrote:
> 
> Hi Sergey,
> 
> Sergey Melnik wrote:
> >
> > Brian,
> >
> > I'd just like to reiterate some of the arguments for making reification
> > a built-in feature (possibly as an optional layer):
> 
> I wasn't sure what you meant by 'built in' but I guess you mean specifically
> called out in the abstract syntax.
> 
> >
> > - in M&S, reified statements need to have a URI. It looks like they
> > should be unique, but nobody wants to deal with uniqueness, but still
> > some sort of URIs need to be assigned, so we end up having to deal with
> > different URIs denoting the same statement etc.
> 
> I have the same question as Danbri here - why do they have to have a URI.
> M&S allows there construction without.

I'm tempted to postpone arguing about this issue until we worked out
what anonymous resources are and whether we need them. However, I'd like
to point out that if you want to use reification in databases, you may
avoid unintuitive query results if reified statements are unique, i.e.
have same IDs, whatever they are. To be frank, I only see unnecessary
complications associated with "multiple occurrences" of reified
statements, or anonymous resources, but no tangible benefits.

> > - in M&S, we need a specific vocabulary to express/use reification.
> > Reification could be defined without relying on vocabularies.
> 
> I'm wondering what you mean here by 'relying' on vocabularies.  Reification
> is currently defined using rdf:type, rdf:subject etc.  Those are
> vocabularies.

I'm joining Graham's suggestion on this issue.

> > - as defined in M&S, reification is extremely verbose and clumsy both in
> > APIs and in the syntax, and very few people are using it as suggested.
> > However, I personally believe it is a useful feature when introduced
> > correctly and compactly, and it can be easily handled in APIs and
> > databases as an intrinsic model feature.
> 
> Absolutely.
> >
> > Finally, (s1 p1 (s2 p2 o2)) looks nicer in the abstract syntax...
> 
> Right.  Much neater and simpler.  However ...
> 
> There has been a bunch of discussion lately on www-rdf-logic about this.
> It would be very helpful if one someone who understands these issues
> (far) better than I (Pat, FrankM, ?  please) could summarize the key points -
> and
> straighten me out if what I'm about to say is wrong.

I'd love to see this summary, too...

> The upshot of that discussion is that there are (at least) two different
> concepts floating about, distinguished by the ideas of 'use' and 'mention'.
> 
> The simplest examples to distinguish these I have seen are:
> 
>   London is a city.
>   'London' is a word.
> 
> The first of these is use, the second is mention of the name 'London'.

I have a feeling that this example might be too simple to illustrate the
problem, since it could be tackled using urn:cities:London and
urn:rdf:literal:London.

> A logical language needs both mechanisms.  Reification, as described in
> M&S is an example of mention e.g. Ralph said 'the sky is blue'.
> 
> My working assumption at the moment is that reification is a different
> mechanism from nested expressions.  If we use nested expression syntax
> to represent reification, then a future working group can't use it
> to represent nested statements.

I tend to agree. My impression is that reification provides a
qualitatively different instrument, which allows referring to states of
affairs, so the distinguished notation would be justified. I think if we
need nested expressions (e.g. for representing LISP, rules etc.), we can
always define some dedicated vocabulary. Ideally, the semantics of such
a nested expression would be consistent with that defined by RDF "core"
(i.e. a nested expression in the abstract syntax would be interpreted as
a nested expression in the domain of discourse), with additional
interpretation functions or relations that would help to capture the
extra semantics. Again, I'd appreciate a logician's summary on those
issues...

Sergey

Received on Tuesday, 19 June 2001 21:57:02 UTC