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

Re: further on ISSUE-39

From: Ivan Herman <ivan@w3.org>
Date: Fri, 13 Aug 2010 13:43:24 +0200
Cc: "Toby Inkster" <tai@g5n.co.uk>, public-rdfa-wg@w3.org
Message-Id: <C1EAC5A3-6E6A-4C39-9649-2D5457FB4665@w3.org>
To: Richard Cyganiak <richard.cyganiak@deri.org>

On Aug 13, 2010, at 13:08 , Richard Cyganiak wrote:
[snip]
> 
>> 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.


For the current setup it does. Section 9 says

[[[
If one of the objects is not a Literal or if there are additional rdfa:uri or rdfa:term predicates sharing the same subject, no mapping is created.
]]]

which, if we translated to the new setup, would mean that both triples would be ignored, ie, no term mapping would be done. 

But if we follow the closed world approach then this issue might become moot.

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

Let us see what others say...

Ivan


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


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







Received on Friday, 13 August 2010 11:42:25 GMT

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