- From: Thomas B. Passin <tpassin@comcast.net>
- Date: Wed, 08 Sep 2004 01:18:15 -0400
- To: www-rdf-interest@w3.org
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. 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). Cheers, Tom P -- Thomas B. Passin Explorer's Guide to the Semantic Web (Manning Books) http://www.manning.com/catalog/view.php?book=passin
Received on Wednesday, 8 September 2004 05:16:00 UTC