Re: attempting to merge the 'vocab' and 'profile' documents

Hi Ivan,

> I am afraid we disagree:-(

I know. ;)


> The way I see it, what we have is an RDF graph that is used by a
> processor that produces _another_ RDF graph by extracting it from some
> data.

Yes, of course. But that's the point I'm getting at; when you have a
hammer, everything looks like a nail. :)

Since RDF can express pretty much any kind of information it's obvious
that it can express the 'control' information. But that doesn't mean
it should.

(I.e., when you have RDF, everything looks like a triple.)


> That 'control' RDF graph is there to give additional information
> on how that extraction should operate. It is, in this abstract sense,
> the same as when one uses an RDF graph to describe how a particular
> relational data from an RDB, using a particular Relational Database
> Schema, should be extracted to generate an RDF graph (and such systems
> do exist already). The two graphs, ie, the 'control' one and the
> 'target' one, are different; there is no circularity for me.

But what you are describing here is not the same thing at all.

Using an RDF graph to define the processing of another RDF graph is
fine, but the implication here is that you have (1) interpreted both
graphs, and now (2) you are doing some processing with the triples
you've extracted -- the parsing is opaque.

There are of course many scenarios that do what you describe here; I
might use one graph to provide OWL, and that might help me to reason
about the second graph. Or I might have one graph that provides some
terms that will guide some NLP or entity extraction to be carried out
on the second graph.

But interpreting graphs and then using them for processing is very
different to what you are describing with profiles and prefix
mappings, since that relates to the step *before* interpretation. In
this scenario you are saying that in order to actually *parse* the RDF
graphs I'm going to use another RDF graph.

And that is turtles all the way down...


> And yes,
> you are right that we could use the same mechanism for base (and the
> fact that the value may be relative is only an implementation
> complication). Of course, there is no reason for doing that because we
> already have a well established mechanism to set the base...

No, I didn't say you could use this mechanism for base. :)

I began by saying that *at first sight* it would appear that 'base' is
a property of the document. I.e., Since 'carrying an RDF hammer makes
everything look like a triple', it would appear that 'base' is just
another predicate.

But then I said that on closer inspection 'base' is not a predicate --
it's actually part of the serialisation scaffolding.

You only have to think about the many possible ways that we could take
some triples and serialise them out to a document, with or without a
'base' value, to realise that 'base' is not part of the core
information being conveyed (the triples), but is instead part of the
scaffolding that conveys those triples.

The same goes for @profile (i.e., I believe we shouldn't use
@rel="profile"), and of course for prefix and token mappings (I
believe that they should not be expressed in RDF).

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Sunday, 7 March 2010 09:40:17 UTC