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

On 2010-3-7 10:39 , Mark Birbeck wrote:
> Hi Ivan,
> 
>> I am afraid we disagree:-(
> 
> I know. ;)

:-)

[snip]

> 
> 
>> 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.
>

Hm, this is not what I feel is happening. The processor is working on
some non-RDF data (XHTML+RDFa file) and, the 'vocab' graph directs this
processor on how to generate that 'target' draft. Ie, I do not see your
point (1) at all. The triples from the 'vocab' graph are used while
producing the 'target' graph, and there is no question on processing the
triples that are extracted. The URI-s in the @profile/@vocab attributes
do _not_ appear in the 'target' graph at all! Ie, just as you say for
@base, the uri-s in the @profile are not (RDF) predicates.

Ivan

> 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)

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf