RE: Reification - whats best practice?

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Thomas B.
> Passin
> Sent: 08 September, 2004 08:18
> To: www-rdf-interest@w3.org
> Subject: Re: Reification - whats best practice?
> 
> 
> 
> Patrick.Stickler@nokia.com wrote:
> >>[mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Thomas B.
> >>Passin
> >>Well, yes, if we had a good way to identify and name a 
> subgraph that 
> >>would take care if it.  I'm not convinced I've seen that yet.  
> > 
> > Have you seen 
> > 
> > http://www.w3.org/2004/03/trix/
> > 
> > specifically
> > 
> > http://www.hpl.hp.com/techreports/2004/HPL-2004-57
> > 
> 
> Yes, or some earlier version of the work.  I've now re-read 
> it, and it 
> seems to me that it answers some but not really all of the 
> things I am 
> considering right now (too bad we have to change or extend rdf to get 
> these capabilities).
> 
> I am especially interested in two kinds of things so far as 
> this thread 
> is concerned -
> 
> 1) An ability to attach arbitrary meta data to subgraphs, and 
> especially 
> down to the granularity of individual triples.  This is needed in 
> practical diagramming and data store work.  For example, to keep an 
> history of all changes to a triple (their dates, the user who changed 
> them, etc.), to specify drawing symbols, and line placement and 
> characteristics, and so on and so on on.  Metis and DOORS are two 
> examples of applications that allow such meta data.  Metis, 
> in fact, is 
> practically RDF except for this feature.
> 
> Put another way, there is no reason that triples (or relationsips, at 
> least) should not be treated as first class objects, the same as 
> subjects.  It's true that most logic formulations keep predicates as 
> classes or types rather than individuals, but it's equally true that 
> practical work requires them to in fact be individuals.

I've chewed on this issue before, and at one time defined a subclass
of rdf:Statement called rdfx:Assertion which corresponded to the
reification of an asserted triple, as opposed to simply the reification
of a statement which may or may not be asserted.

This seems similar (if not identical) to what you are talking about
here -- the ability to describe actual triples/assertions as "first
class" resources.

A combination of statements about individual rdfx:Assertion's
and named graphs should cover the use cases you mention above,
I think.

Eh?

> 
> For example, if we draw a graph of a set of rdf triples, each 
> edge is in 
> fact distinct from every other, at least in its placement on 
> the page. 
> It is an obvious step to be able to label an edge with an arbitrary 
> collection of meta data about it.  Since no edge is in fact 
> re-used, an 
> edge (as an individual) is sufficient to identify the 
> specific triple it 
> is part of.  So such meta data can reasonably be taken to 
> apply to the 
> entire triple if we like.
> 
> 2) To have this ability with minimal (or no) changes to rdf as it 
> currently is.  If it has to change somehow, then I would like to see 
> current rdf/xml syntax kept with minimal or no changes (and 
> in the named 
> graphs proposal that would be impractical, since I want to be able to 
> specify subgraphs within one and the same document if possible).
> 
> Well, maybe these two desires cannot be achieved together.  But if 
> predicates were individuals, they could be.  And full RDF does allow 
> this, as I understand it.
> 
>  >>...
> >>OTOH, I can also imagine defining a class of resources for 
> which - by 
> >>definition - their identifier *does* match up with their 
> >>content.  Then 
> >>such a scheme would work, at least if you want to create an 
> >>actual rdf 
> >>document for each case and if you can figure out how to make 
> >>it all work 
> >>in an rdf data store, which would have to import the subgraph 
> >>and match 
> >>it against the main graph but still keep it separate somehow.
> > 
> > 
> > Do you mean a "triple URI" where the triple is encapsulated in
> > the URI itself? True, that would be more concise than reification,
> > but named graphs seem to me to be far more efficient, particularly
> > when dealing with provenence and trust.
> 
> Not necessarily limited to triples, I would say.  Let a 
> resource be of 
> this type.  Then you automatically know that it is supposed to be 
> retrievable from its URI, and that when retrieved, the content or 
> "meaning" of the resource is exactly its collection of 
> retrieved triples 
> (which might just be a single triple).  Here we would 
> essentially have a 
> form of named graphs, just by defining this special class of 
> resources. 
> (It would not be as general as with your proposal, but maybe it would 
> serve, and it would require no changes to current rdf except for the 
> definition of this special class).

Well, technically, I don't see named graphs requiring any
change to the RDF MT. It's really just about packaging and
management by particular systems.

Since named graphs are named by URIs, one can say what one
likes about them. And per your suggestion above, one could
also expect to have access to representations of those graphs
via their URIs, and a common representation would be an RDF/XML
serialization of the statements contained in that graph.

The missing machinery is mostly on the query/processing side,
or with the interchange of multiple graphs via a single
serialization (which isn't technically manditory, since
one could use multipart MIME and have each graph serialized
separately using RDF/XML); not so much on the MT side.

Patrick

Received on Wednesday, 8 September 2004 11:56:04 UTC