W3C home > Mailing lists > Public > semantic-web@w3.org > January 2010

Re: Requirements for a possible "RDF 2.0"

From: Peter Ansell <ansell.peter@gmail.com>
Date: Sat, 16 Jan 2010 10:10:17 +1000
Message-ID: <a1be7e0e1001151610r7452a9c4o2ba9d911587e789f@mail.gmail.com>
To: Toby Inkster <tai@g5n.co.uk>
Cc: Danny Ayers <danny.ayers@gmail.com>, jeremy@topquadrant.com, "semantic-web@w3.org" <semantic-web@w3.org>
2010/1/15 Toby Inkster <tai@g5n.co.uk>:
> On Fri, 2010-01-15 at 11:57 +0100, Danny Ayers wrote:
>> Aside from a little  tidiness, what would we actually gain through
>> going the whole hog on what can go in which position in the triple?
>> blank node predicate - what does that tell you that an rdfs:seeAlso
>> wouldn't?
> <#school>
>  [
>    rdfs:subPropertyOf ex:teacher ;
>    rdfs:label "maths teacher" ;
>    ex:relatedTopic dbpedia:Mathematics
>  ]
>    <#joe> .
> <#band>
>  [ rdfs:subPropertyOf foaf:member ; ex:relatedInstrument <#bongo> ]
>    <#jim> .
> These structures are of course already permissible in RDF, but only if
> you're willing to commit to giving the property a URI.

Why is the commitment to a URI such a sticking point? One thing you do
by doing things this way is introduce data-bloat, because every time
you want to say someone is a maths teacher you have to recreate the
definition instead of reusing a definition.

I do agree that it was a bad idea to not let predicates be blank nodes
in general though, as you may have something like the following that
was at least reuseable within the document (as opposed to your RDF
where you would have to create a new blank node for each maths teacher

Data bloat.....

   rdfs:subPropertyOf ex:teacher ;
   rdfs:label "maths teacher" ;
   ex:relatedTopic dbpedia:Mathematics
   <#jim> .

   rdfs:subPropertyOf ex:teacher ;
   rdfs:label "maths teacher" ;
   ex:relatedTopic dbpedia:Mathematics
   <#jack> .

   rdfs:subPropertyOf ex:teacher ;
   rdfs:label "maths teacher" ;
   ex:relatedTopic dbpedia:Mathematics
   <#phillip> .

The following is much more realistic to me and doesn't introduce as
much data bloat, except that you will have to redefine maths teacher
in every document you use it in because you have consciously chosen to
avoid giving it a global scope for some reason.

   rdfs:subPropertyOf ex:teacher ;
   rdfs:label "maths teacher" ;
   ex:relatedTopic dbpedia:Mathematics .

<#school> _:mathsTeacher  <#jim> .
<#school> _:mathsTeacher  <#jack> .
<#school> _:mathsTeacher  <#phillip> .

>> literal subject - aside from quotations:
>> "I can't really see how it would be useful" <x:saidBy> <#me> .
> If the above was the only use case, then it would not be especially
> useful - you'd simply create a x:didSay predicate that worked in the
> reverse direction. With blank node predicates that's even easier:
>  <#me>
>    [ owl:inverseOf x:saidBy ]
>      "I can't really see how it would be useful" .
> But that's not the only use case. Consider relationships between two
> literals:
>  "Toby Inkster" foaf:sha1 "4296ab2b2243bdb1e3cd1952158d2ce5464ea10c" .
> I can imagine wanting to do things like:
>  SELECT ?person ?hash
>  WHERE {
>    ?person ex:password ?pwd .
>    ?pwd foaf:sha1 ?hash .
>    FILTER (?hash = "672059bd1419f8b90633fc2d02529be0de2fa614")
>  }
> Both blank node predicates and literal subjects are already allowed by
> N3 and are theoretically allowed by SPARQL (though I don't know of any
> implementations that choose to support them).

In this case, unless you are going to fill up a database with every
possible password hash you have two more sustainable alternatives IMO.

SELECT ?person
   ?person ex:password ?pwd .
   FILTER (foaf:sha1(?pwd) = "672059bd1419f8b90633fc2d02529be0de2fa614")

if you are willing to include a custom function into SPARQL as it was designed.

Or you could do the following and keep just as much information in the
datastore as you would have to in the case where literals are allowed
to have properties attached to them.

SELECT ?person
   ?person ex:passwordHash ?sha1hash .
   FILTER (?sha1hash = "672059bd1419f8b90633fc2d02529be0de2fa614")

Responders on this thread seem to be very anti-URI's and
anti-BlankNodes. What is a case where they actually cause a problem?
Most people just seem to be annoyed about the fact they have to put
effort into making up a URI or BlankNode to attach properties of a
thing to, when they could attach properties to the actual thing
(whatever that means in formal semantics). If you don't want to commit
to using URI's then you are free to use BlankNodes (with the exception
of properties, where even I like the idea of being able to use a blank
node as a property.)

There also seems to be a deep seated hatred of RDF/XML. I don't
understand it myself, as RDF/XML *can* be generated in a way that is
logical to read, ie, group statements about the same thing ala,
turtle. It is also processable into an AST by many more tools than
Turtle/N3 ever will be. In a similar way to Turtle/N3, there may be
more than one way of presenting the same RDF information, so there is
no advantage there. In my opinion it has been a major factor in the
uptake of RDF that the same document can be presented in one file
format in different ways, although the triple oriented RDF/XML
generated by some tools is particularly hard to read. Limiting RDF/XML
to a triple oriented scheme, as some tools have done, is like limiting
Turtle to NTriples and possibly causes some hatred IMO where it
doesn't have to be. The following snippet would definitely turn people
against RDF/XML if it were the only option.


One advantage of RDF/XML IMO is that the document has a non-RDF based
well-formedness test that in some cases will let you know whether the
file was complete or not. If you leave out the rdf:RDF root element
then you lose this but you are obviously embedding it somewhere
because you don't want to have the RDF/XML root element so you know
what you are doing in that overall context.


Received on Saturday, 16 January 2010 00:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:05 UTC