Re: Alternatives to containers/collections (was Re: Requirements for a possible "RDF 2.0")

On 01/15/2010 06:29 AM, Pat Hayes wrote:
> 
> On Jan 14, 2010, at 10:50 PM, Jiří Procházka wrote:
> 
>> On 01/15/2010 04:17 AM, Pat Hayes wrote:
>>>
>>> On Jan 14, 2010, at 3:12 PM, Geoff Chappell wrote:
>>>
>>>> -----Original Message-----
>>>> From: semantic-web-request@w3.org
>>>> [mailto:semantic-web-request@w3.org] On
>>>> Behalf Of Pat Hayes
>>>> Sent: Thursday, January 14, 2010 3:19 PM
>>>> To: Dan Brickley
>>>> Cc: Danny Ayers; Steve Harris; Semantic Web
>>>> Subject: Re: Alternatives to containers/collections (was Re:
>>>> Requirements
>>>> for a possible "RDF 2.0")
>>>>
>>>>
>>>> On Jan 14, 2010, at 11:31 AM, Dan Brickley wrote:
>>>>
>>>>>> On Thu, Jan 14, 2010 at 4:20 PM, Pat Hayes <phayes@ihmc.us> wrote:
>>>>>>> A lot, perhaps all, of this hair could be avoided if RDF allowed
>>>>>>> general
>>>>>>> tuples as well as triples. All that is needed is some way to put N
>>>>>>> things
>>>>>>> into a sequence: so, put N things into a sequence. The 'graph
>>>>>>> model' would
>>>>>>> be a hyperlink, drawn as a polygon (eg triangle for N=3) rather
>>>>>>> than a line.
>>>>>>> In triples-style syntax, it would just be moving a dot.
>>>>>>
>>>>>> I periodically wonder what an RDF without the binary restriction
>>>>>> would
>>>>>> look like.
>>>>
>>>>> My 2c suggestions, as answers to the questions.
>>>>>>
>>>>>> Would each property/relation have a fixed arity, eg. dc:source might
>>>>>> 'be a 4', 'foaf:knows' a 7?
>>>>
>>>>> No. But it might be useful to distinguish 'really binary' ones, which
>>>>> only fit in triples, from the others, which can take any number of
>>>>> things in the sequence. Or maybe not, whatever. But the default should
>>>>> be, any number (even though most of them will be 2 in practice, ie
>>>>> triples.)
>>>>
>>>>>> That doesn't make a lot of sense to me. So
>>>>>> presumably they'd vary freely. In which case, we have a lot of
>>>>>> figuring out to do when wondering whether   livesWith(alice, bob,
>>>>>> 2007, 'y') implies livesWith(alice,bob) or livesWith(alice, bob, 'y',
>>>>>> 'foo.html'). The binary straightjacket makes some of these questions
>>>>>> impossible, albeit maddeningly...
>>>>
>>>>> The Common Logic answer is very puritan: each number of arguments is a
>>>>> separate assertion, and they are all independent (unless you write
>>>>> axioms connecting them.) So liveswith(a b c) has nothing to do with
>>>>> liveswith(a b) or with liveswith(a b c d), etc., as far as the logic
>>>>> itself is concerned.  This is actually quite elegant and works well
>>>>> WHEN you can write the axioms you might need. So maybe we would need,
>>>>> for RDF, some way to attach some common inference patterns to these by
>>>>> giving properties to the property of the tuple. For example, one
>>>>> useful and common pattern allows ends of argument lists to be lopped
>>>>> off, so that
>>>>>
>>>>> liveswith(alice, bob, <address>, <maritalstatus>)
>>>>> entails
>>>>> liveswith(alice, bob)
>>>>>
>>>>> and we might specify this pattern (in a semantically extended RDF) by
>>>>> asserting
>>>>>
>>>>> liveswith rdf:type rdf:ExtendableProperty .
>>>>>
>>>>> But this is very much off the top of my head. Whaddayathink?
>>>>>
>>>>> Pat
>>>>
>>>> I wonder how much of this needs to be in RDF itself vs. in query/rule
>>>> languages that operate over RDF.
>>>>
>>>> E.g. we support rules in our sparql extensions and while we of course
>>>> support rules with triples at the head, we also support ones that have
>>>> n-ary
>>>> relations at the head. I find the non-triple variety useful for of
>>>> course
>>>> dealing with inferring relations that have a natural arity greater than
>>>> three but also for just performing transformations without polluting
>>>> the
>>>> triple space. Similarly, we have a native list type which is useful for
>>>> things like accumulating values -- something that would be extremely
>>>> ugly
>>>> with a pure triple syntax. In both cases I find the extensions
>>>> useful/necessary for processing RDF efficiently, but I never really
>>>> feel the
>>>> need to push the extensions into RDF storage/graph layer.
>>>
>>> Well, fair enough. After all, RDF does already have what are in effect
>>> LISP S-expressions embeddable in it, so this is always *possible*. But I
>>> thought the idea of this thread was to find a way to avoid all this
>>> pseudo-Lisp list hacking using triples.
>>>
>>> <rant>
>>> This brings up a broader issue. Everyone agrees its good to keep RDF
>>> simple. But keeping RDF simple by making it in effect into a
>>> general-purpose construction kit, and then expecting that as a matter of
>>> routine people will use the constructions, isn't really being honest
>>> about 'simple'. OWL/RDF is a lot less simple than RDF itself largely
>>> because its written in what we might more honestly call
>>> OWL-syntax-coded-in-lists-described-using-RDF, which IMO isn't really
>>> RDF any more. If we want to expect RDF to do this kind of thing, then it
>>> ought to have a whole datastructuring facility built in explicitly,
>>> perhaps along JSON lines, rather than prostituting the triple store to
>>> be a data structuring tool.
>>> </rant>
>>
>> Wasn't this the whole idea of RDF? Simple language for expressing any
>> information? Doesn't it use triples, simple relations between two
>> objects, specifically for the reason that it is universal, and any kind
>> of structure can be expressed by it?
> 
> There are two notions of universal here, and we shouldn't get them
> confused. One is a universal programming language, which can be used to
> build arbitrary data structures and define operations over them. In
> other words, in fact, a programming language. The other sense is a
> universal *descriptive* language, which RDF is supposed to be , but
> isn't because it is too simple. (Thats why we need OWL, etc.; though RDF
> is closer than I used to think, see my ISWC talk.)
>
> My point was only that if RDF needs to *use* sequences (like, as data
> structures to encode OWL syntax, for example, or as a way of hacking
> N-ary relations using only binary links) then this is more like building
> data structures than describing anything, and maybe it would be better
> to admit this up front and deal with it with a real datatstructuring
> notation. It wasn't the whole idea of RDF to have it be a kind of
> awkward version of simplified LISP.

No, I am not mixing in programming languages, I am talking about
descriptive language, though I am not a logician, so could you please
explain what universal descriptive language needs to fulfill (or provide
a link to such explanation)? I cannot imagine anything that cannot be
described by RDF+RDFS - you say we need OWL - but OWL is defined using
RDF+RDFS.

Anyway you probably meant the universal descriptive language has to be
able to describe anything using only it's own terms, be self-hosted
(bootstrapped), not aided by natural language like with RDFS.
I don't see why it needs to be that way, in fact I see that as its
strength - we can use it to describe things with various levels of
detail. For example I can define simply:

<NaturalNumbers> a rdfs:Class ;
  rdfs:comment "A class of natural numbers - integers which are greater
than zero" .

Or I could use OWL and express formally it's relation to integers, but I
don't need to.

>> Why should we give preferential
>> treatment to relations describing structure than those describing time,
>> measures, events, organizations, people, pizzas...?
> 
> Because they aren't *descriptions* of structure, they are structures
> being used to describe other things. Just like triples are.

I believe triples were chosen because they are the simplest of the
structures, yet can describe any other.

Do you intend to define all structures possible which can be used to
describe other things?

>> This is what I always thought what RDF was supposed to be and things
>> like containers, blank nodes, literal data types, language tags got in
>> because of pragmatical reasons, mainly to give users some kind of
>> direction, examples how to get started.
> 
> Well, not really. All of these things are needed in order to describe
> things that people wanted to describe, and couldn't be described any
> other way. If you don't have literals, how are you going to use numbers
> in a description? Without language tags, how are you going to say that
> something is written in French? Well, OK, maybe containers...

<data:text/plain;charset=utf-8,Je%20ne%20comprends%20pas.> ex:language
lang:French .

I don't advocate using data URI scheme instead of literals, but it
should be possible.
Maybe you are right about the blank nodes though, I am not sure if this
would work (meaning the URI is irrelevant):

<j48fd8dj3> rdf:type ex:UnnamedNode .

>> Reality that even such thing as RDFS was made separate of the RDF itself
>> support my view (even though I suspect one of reasons if that separation
>> was the process of it's development).
> 
> Yes, most the latter. I would have preferred to have one namespace, but
> this was set in stone very early on.
> 
>>
>> On the other hand I am not against creating community developed
>> framework for making common uses of Semantic Web technologies easier,
>> defining useful structures and design patterns... but build that *on
>> top* of RDF as separate framework.
>>
>> I would like RDF to be as lightweight (low level) as possible - if I
>> were to make mine RDF, there would be no containers, bnodes, literal
>> data types, language tags, maybe even no literals - using data URI
>> scheme. Anyway I value compatibility and adoption more than sticking to
>> my view of the world so I use RDF as it is.
>>
>> Other alternative would be to have the low level core, build modules on
>> top of it, for example like some programming languages do (Python,
>> Java...) and call the whole thing RDF - I guess that is what would make
>> most people happy.
> 
> But this whole idea of 'building modules on top' is a programming idea,
> not a description language idea. It muddles up the notion of a
> description. Which 'level' defines the semantics you should be using in
> a query? There's no way to know.

You can use any level, because all levels are defined by levels under
them, lowest of them being RDF core.

Best,
Jiri

PS: Actually there is one thing which would aid bootstrapped nature of RDF:

ex:contains rdf:type rdf:Property ;
  rdfs:comment "property for stating that a reified triple is part of
graph" ;
  rdfs:range rdf:Statement .

> Pat
> 
>>
>> Best,
>> Jiri Prochazka
>>
>>>
>>> Pat
>>>
>>>
>>>
>>>>
>>>> Rgds,
>>>>
>>>> -Geoff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> IHMC                                     (850)434 8903 or (650)494 3973
>>> 40 South Alcaniz St.           (850)202 4416   office
>>> Pensacola                            (850)202 4440   fax
>>> FL 32502                              (850)291 0667   mobile
>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>>
>>
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
>