W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > November 2011

Re: Triple(s) that describe the vocabulary

From: Niklas Lindström <lindstream@gmail.com>
Date: Fri, 11 Nov 2011 18:21:14 +0100
Message-ID: <CADjV5jdp24e=Rq=Vie-c9DxHwejYR4A=tvQx-pjKxjbSqjScBQ@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Shane McCarron <shane@aptest.com>, public-rdfa-wg@w3.org
Hi,

On Fri, Nov 11, 2011 at 5:30 PM, Ivan Herman <ivan@w3.org> wrote:
> We did discuss it: for each @vocab element there is a triple put into the graph. I think it was ISSUE-103.
>
> On Nov 11, 2011, at 17:12 , Shane McCarron wrote:
>
>> In the Sequence section, step 2, there is some strange text:
>>> The value of @vocab is used to generate a triple as follows:
>>> subject
>>> base
>>> predicate
>>> http://www.w3.org/ns/rdfa#hasVocabulary
>>> object
>>> value from @vocab
>>
>> first. didn't we change the URI for the 'namespace' to some vocab space?
>>
>
> No. That is clearly in the rdfa namespace.

Shouldn't that be 'usesVocabulary', as per [1]?


>> Second, this seems odd.  There can be hundreds of @vocab elements in a document.  Why would I want to see this triple for each of them.  Also, since the subject is base, it seems to me that I wouldn't have a way to know what vocab was related to what parts of the document.
>
> Hundreds? I do not think so. I would expect 3-4 @vocab usage in a document, but mostly one...

It may be that some authors choose to use different @vocab for
different sections of the documents though (and if generating pages
there might be lots of them). So although I too expect the same ratio
as you, we can't be sure.


> You are right about the second statement, b.t.w. But the reason of having this triple is to allow processors to perform the vocabulary expansion, ie, the mini RDFS entailement, on the result graph. From that point of view, the origin is irrelevant, only the URI of the vocab is important. But if that information is not in the output graph, than no processor, other than the RDF distiller itself, can ever perform the right expansion.

Unless they follow their noses on the used predicates (reasonably
caching anything resolvable, after any 303). And/or chomps off
everything after the last "#" or "/" and attempts to resolve the
resulting IRI. The latter is theoretically incorrect (since IRIs are
opaque) but would work for basically any published vocabulary in
practice. That would be based on the assumption that expansion is
desirable for *any* predicate used though, not just for anyone
syntactically created using @vocab. I think we settled for the latter
assumption, but I'm not entirely sure if that's proper.

(It may be that this triple becomes as annoying to some as the
xhv:stylesheet is today...)

There is also one formally bad thing about using the value in @vocab
as an object *IRI*. The actual vocabulary IRI isn't always the IRI
ending with "#" (which we use because the construction of terms is
based on string concatenation and not resolving). Some say it should
never be, which is a topic all it's own. I'd recommend reading [2] for
the gist of it, and [3] for some statistics by Richard Cyganiak. Based
on this reasoning, if we need to keep the value in @vocab, it may be
more correct to use a *literal* as the object in the triple (possibly
an xsd:anyURI).

Best regards,
Niklas

[1]: http://www.w3.org/2010/02/rdfa/meetings/2011-08-25
[2]: http://lists.w3.org/Archives/Public/public-lod/2010Oct/0143.html
[3]: http://groups.google.com/group/pedantic-web/msg/505c158813c9bff2


> Ivan
>
>
>>
>> I guess I don't remember putting this text in, and I don't understand what problem it is trying to solve.  Help?
>> --
>> Shane McCarron
>> Managing Director, Applied Testing and Technology, Inc.
>> +1 763 786 8160 x120
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>
>
Received on Friday, 11 November 2011 17:22:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:18 GMT