Thank you Sergio for the explanations. About what you told and which I did understand as "In Linked Data, don't reuse others URI as subject of your triples", could you point me to the documentation (best practice maybe ?) where this is stated ? This discussions is too generic for me, as there are so many ways to design ontologies (also depending on the purpose of your design, including speeding up SPARQL queries using materialization). Another point is that we didn't talk so far about inferences, and I don't see how that "linked data principle" deals with owl:inverseOf ( http://www.w3.org/TR/2004/REC-owl-semantics-20040210/#owl_inverseOf) . Working since more than 10 years with semantic web technologies, I am maybe mixing up "semantic web" general possibilities and "Linked Data" more specific guidelines. Thank you again Fabian
>>> Le 04.11.2014 à 14:48, Sergio Fernández<[email protected]> a écrit dans le message <[email protected]> : Hi guys, On 04/11/14 11:44, Fabian Cretton wrote: > Because in my understanding of the web of data, anyone can say anything > about anything, isn't that correct ? Not really if you consider trust... > For instance, there could be a specific product sold by different > vendors, and each vendor, publishing a catalog in RDF, will provide a > price for that product. So, referring to that produc'ts URI, each vendor > will publish data with the product's URI as subject. That seems a very > simple and realistic case, isn't it ? No, I would not say so. Let's use a concrete product as example, a car, VW Golf. If the manufactured publishes information about that car: <http://www.volkswagen.com/cars/golf/gte> vso:weight "1520" . Then if a retailer sells a model of that car, publishing the following data: <http://www.asturwagen.es/offer1> a gr:Offering ; gr:includes <http://www.volkswagen.com/cars/golf/gte> . <http://www.volkswagen.com/cars/golf/gte> vso:weight "1525" . You should never trust what the retailer says that the weight of the Golf GTE is 1,525 kg. The dealer has no authority to say that. URIs are global identifiers using the hierarchical DNS system. You cannot mint URIs you do not control for saying information about things you do not own. Back to you your product example, the vendor > Then can you help me to better understand what "is/should" a Marmotta's > LDClient ? > On that page [1], it is said that "LDClient is a flexible and modular > Linked Data Client (RDFizer > ( http://www.w3.org/wiki/ConverterToRdf) )" > There is already something not clear for me in that sentence: RDFizing > is, to me, the process of transforming non-rdf data to rdf. > But if I understand it well, LDClient is already able to import natif > RDF, for instance RDFa, Linked Data and also querying a SPARQL > end-point. > > Is LDClient designed to deal only with data published from its own URL, > where all triples have that URL as subject ? It does RDFizing. But it also discards the triples that do not talk about the URI that was referenced. > if so, what happens when LDClient is used as a RDFizer on non-RDF data > ? > > Maybe I should have a look at the RDFa client and also see how data is > processed there. In the RDFa Data Provider is just a transformation process. The cases that might be causing issues for understanding it could be other that make use of APIs to get data out of other formats (e.g., the transformation from Facebook Graph). > But here is what interest us in LDClient: > - import RDF and non-RDF data in the triple store (even if it is an RDF > file where subject don't correspond to the file's URL) > - import first in a temporary location, in order to import only part of > the data, and validate the data. It seems that LDClient does handle this > natively and this feature is very interesting for us. OK, so let's put it this way: the general purpose of LDClient is to respect the URI as identity for the data; but if you have a custom scenario were that needs to be extended, you are completely free to use the infrastructure provided by LDClient. > About dealing with data update, I understand that in your use of > LDCache/LDClient, ensuring that triples with a specific subject come > from one data source is a way to know which triples to update when > refreshing the data. In our case, we deal with 'contexts' (named graph) > to deal with that. That's the business of LDCache, which uses a fixed context for caching the data. > Talking about this, I do have another question: is it a problem for > Marmotta/Kiwi do deal with a certain quantity of contexts ? I know it is > not a problem with other triple stores as OWLIM for instance. Yes, there is not limit on the context KiWi is able to manage. BTW, if you are interested of keeping OWLIM it should be easy to provide a backend for Marmotta... Cheers, -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 660 2747 925 e: [email protected] w: http://redlink.co
