- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Sun, 5 May 2013 07:54:38 +1000
- To: Bo Ferri <zazi@smiy.org>
- Cc: public-rdf-comments@w3.org
- Message-ID: <CAGYFOCSDWxvkiD3frE-0trLS7=R8J5h20W=uhp+QymV5jLb5SA@mail.gmail.com>
Some RDF databases have been internally using 5 elements for a long time, to give each quad a unique "statement" identifier, while using the 4th element as a non-unique resource to aggregate simple triples into graphs. Peter On 4 May 2013 22:16, Bo Ferri <zazi@smiy.org> wrote: > Hi, > > some time ago I made a proposal that one could use the 4th element in an > n-quad like serialisation for statement identifier to make statement > reification a bit more readable ;) [1] > > Cheers, > > > Bo > > [1] http://lists.w3.org/Archives/**Public/public-rdf-comments/** > 2011Jan/0001.html<http://lists.w3.org/Archives/Public/public-rdf-comments/2011Jan/0001.html> > > > On 5/4/2013 1:35 AM, Kingsley Idehen wrote: > >> On 5/3/13 7:07 AM, Jürgen Jakobitsch SWC wrote: >> >>> hi, >>> >>> is there a way to express that a rdf:Statement belongs to a certain >>> graph? >>> >>> i'm asking with respect to changesSets [1] where i want to add the given >>> statement to one or more specified graphs. >>> >>> if there's no best practice, issue or the like i would subclass >>> rdf:Statement if there's nothing i'm missing out.. >>> >>> wkr jürgen >>> >>> [1] http://docs.api.talis.com/**getting-started/changesets<http://docs.api.talis.com/getting-started/changesets> >>> >>> >> Personally, I see a containment oriented relation as an acceptable >> mechanism for expressing how a statement and a named graph are >> associated. I suspect, historically, folks have stayed away from >> expressing this important association due to the amount of triples it >> generates. >> >> <#SomeGraphIRI> >> :contains <#SomeStamentIRI> . >> >> <#SomeStatementIRI> >> a rdf:Statement; >> rdf:subject <#SomeStatementSubjectIRI>; >> rdf:predicate <#SomeStatementPredicateIRI>; >> rdf:object <#SomeStatementObjectIRI>. >> >> Statement reification is useful. We are now getting to the point where >> real-world issues are bringing its utility to the fore :-) >> >> > >
Received on Saturday, 4 May 2013 21:55:05 UTC