W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2010

Re: further on ISSUE-39

From: Richard Cyganiak <richard.cyganiak@deri.org>
Date: Fri, 13 Aug 2010 12:08:43 +0100
To: Ivan Herman <ivan@w3.org>
Message-Id: <F1C3D66A-090A-449C-8B02-CA6FC1F82711@deri.org>
Cc: "Toby Inkster" <tai@g5n.co.uk>, public-rdfa-wg@w3.org

On 13 Aug 2010, at 09:33, Ivan Herman wrote:
> You say Toby's examples below are compelling, and he definitely  
> argues for keeping the current structure for prefixes. Do you  
> propose to have a different approach for terms than for prefixes?

I would be ok with having different approaches for establishing term  
mappings and prefix mappings. They do different things, after all.

> You also said (in your other mail) that you do not feel Toby's  
> arguments are valid for terms, only for prefixes. To change his  
> examples a bit: if I have a term definition
>
> <http://www.ex.org/vocab/1.0/MyTerm> rdfa:term "exampleTerm" .
>
> and, through some evolution of the vocabulary we have a 2.0 version,  
> but this has a bridge of the form
>
> <http://www.ex.org/vocab/1.0/MyTerm> owl:sameAs <http://www.ex.org/vocab/2.0/MyTerm 
> > .

Term mappings are used with classes and properties (and datatypes).  
For classes and properties, OWL has specific mechanisms --  
owl:equivalentClass and owl:equivalentProperty -- which do not have  
the effect of “copying” statements like rdfa:term over from one entity  
to the other. For datatypes, using owl:sameAs is just asking for  
trouble. So the use of owl:sameAs on the URIs involved in a term  
mapping is likely an authoring mistake, and certainly bad practice.

That being said, I still don't see any major problems arising from it  
for RDFa, see below.

> That, actually, means that I can also deduce a triple of the form
>
> <http://www.ex.org/vocab/2.0/MyTerm> rdfa:term "exampleTerm" .
>
> So how do we handle that?

So if you apply OWL reasoning to the profile document, you get:

   <http://www.ex.org/vocab/1.0/MyTerm> rdfa:term "exampleTerm" .
   <http://www.ex.org/vocab/2.0/MyTerm> rdfa:term "exampleTerm" .

This just means the profile author has established a mapping of the  
same term to two different URIs. I suppose the RDFa draft already  
specifies how to handle profiles like that? I read the document but  
couldn't tell -- this needs to be tightened up in the document IMO,  
and that should then take care of the owl:sameAs issue.

> Unless we can, somehow, formally _restrict_ the effect of an  
> rdfa:term predicate on a specific graph somehow (that may be a  
> possibility but I am not 100% sure how to do that, but maybe we  
> can), this may create the same type of issues as the ones Toby is  
> referring to.

You say it “may create the same type of isses”. Well, does it or does  
it not? If it does, example please. If not, let's move on.

> So. Trying to move forward... The RDFa Core document is already  
> juggling with the term "graph". It talks about default graph, the  
> processor graph, etc. Ie, we can very well refer to the profile  
> graph for a specific document. We could then make it very explicit  
> in the RDFa Core spec that only those triples are considered that  
> are part of that graph; this would take away this problem (as well  
> as Toby's problem). Yes, we are bringing a closed world in through  
> the back door:-)

This is in effect *already done* in the current draft, although  
without using the word “graph”:

“Attempt to retrieve the content of the URI … parse the retrieved  
content as an RDFa document … extract the triples into a collection  
associated with that URI. Note: These triples must not be co-mingled  
with the triples being extracted from any other URI.”
“It is possible that a referenced RDFa [profile] document will in turn  
reference other documents via @profile. Regardless of the depth to  
which such references might go, only the triples in the top level  
document effect current processing.”
http://www.w3.org/TR/2010/WD-rdfa-core-20100803/#s_profiles

I agree that the RDFa Profiles section could be improved by  
consistently using a term like “profile graph”, replacing phrases such  
as “extract the triples into a collection” or “for every extracted  
triple”, regardless of the URI/literal issue discussed above.

Best,
Richard


> I must honestly admit that I still feel uneasy about the change,  
> though. But trying to find a way forward...
>
> Ivan
>
>
>>
>> Best,
>> Richard
>>
>>
>>>
>>> Ivan
>>>
>>>> Best,
>>>> Richard
>>>>
>>>>
>>>> On 12 Aug 2010, at 10:24, Toby Inkster wrote:
>>>>
>>>>> On Fri, 6 Aug 2010 07:40:04 +0200
>>>>> Ivan Herman <ivan@w3.org> wrote:
>>>>>
>>>>>> This was discussed several times on the mailing list and I fully
>>>>>> understand your issues. Here is the reason I was in favour of the
>>>>>> current setup, but I am absolutely open to discussion because,  
>>>>>> well,
>>>>>> it does complicate processing (speaking as an implementer).
>>>>>
>>>>> FWIW, I agree with your reasoning for the current vocab. Prefix  
>>>>> and term
>>>>> mappings are semantically a relationship between two strings.
>>>>>
>>>>> Imagine this:
>>>>>
>>>>> 	<http://xmlns.com/foaf/0.1/> rdfa:prefix "foaf" .
>>>>>
>>>>> Now, the following is also true (probably):
>>>>>
>>>>> 	<http://xmlns.com/foaf/0.1/>
>>>>> 	  a owl:Ontology ;
>>>>> 	  owl:sameAs <http://dbpedia.org/resource/FOAF_(software)> .
>>>>>
>>>>> Thus it follows that:
>>>>>
>>>>> 	<http://dbpedia.org/resource/FOAF_(software)>
>>>>> 	  rdfa:prefix "foaf" .
>>>>>
>>>>> Thus an RDFa processor could expand 'foaf:name' to:
>>>>>
>>>>> 	<http://dbpedia.org/resource/FOAF_(software)name>
>>>>>
>>>>> Which we wouldn't want to happen.
>>>>>
>>>>> In RDF terms, when we're defining prefixes and terms we're not
>>>>> describing the underlying resources - we're just talking about
>>>>> the xsd:strings. We're not even talking about xsd:anyURIs, because
>>>>> say, "htt" is a valid expansion for a prefix, which might be used
>>>>> as follows:
>>>>>
>>>>> 	prefix="h: htt"
>>>>> 	property="h:p://xmlns.com/foaf/0.1/"
>>>>>
>>>>> So I'd recommend keeping the current pattern, though I think the
>>>>> range of rdfa:uri should be changed to xsd:string for the above
>>>>> reason.
>>>>>
>>>>> Another argument against switching to
>>>>>
>>>>> 	<http://xmlns.com/foaf/0.1/> rdfa:prefix "foaf" .
>>>>>
>>>>> would be the fact that you'd lose the owl:FunctionalProperty- 
>>>>> ness of
>>>>> rdfa:prefix and rdfa:term.
>>>>>
>>>>> -- 
>>>>> Toby A Inkster
>>>>> <mailto:mail@tobyinkster.co.uk>
>>>>> <http://tobyinkster.co.uk>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ----
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>> -- 
>> Linked Data Technologist • Linked Data Research Centre
>> Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
>> http://linkeddata.deri.ie/
>> skype:richard.cyganiak
>> tel:+353-91-49-5711
>>
>>
>
>
> ----
> 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
>
>
>
>
>

-- 
Linked Data Technologist • Linked Data Research Centre
Digital Enterprise Research Institute (DERI), NUI Galway, Ireland
http://linkeddata.deri.ie/
skype:richard.cyganiak
tel:+353-91-49-5711
Received on Friday, 13 August 2010 11:09:21 GMT

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