Re: Best Practices for Converting CSV into LOD?
I gave this a shot in a previous version of Hyena. By prepending one or more special rows, one could control how the columns were converted: what predicate to use, how to convert the content. If a column specification was missing, defaults were used. There were several options: If a cell value was similar to a tag, resources could be auto-created (the cell value became the resource label, existing resources were looked up via their labels). One could also split a cell value prior to processing it (to account for multiple values per column). Creating meaningful URIs for predicates and rows (resources) is especially important, but tricky. Ideally, import would work bi-directionally (and idempotently): Changes you make in RDF can be written back to the spreadsheet, changes in the spreadsheet can be reimported without causing chaos. Even though my solution worked OK and I do not see how it could be done better, I was not completely happy with it, because writing this kind of CSV/RDF mapping is beyond the capabilities of normal end users. One could automatically create URIs for predicates from column titles, but as for reliable URIs (primary keys), I am at a loss. So it seems like one is stuck with letting an expert write an import specification and hiding it from end users. Then my solution of embedding such a spec in the spreadsheet should be re-thought. And it seems like a simple script might be a better solution than a complex specification language that can handle all the special cases. For example, I hadn’t even thought about two cells contributing to the same literal. Maybe a JVM-hosted scripting language (such as Jython) could be used, but even raw Java is not so bad and has the advantage of superior tool support. This is important stuff, as many people have all kinds of lists in Excel---which would make great LOD data. It also shows that spreadsheets are hard to beat when it comes to getting started quickly: You just enter your data. Should someone come up with a simpler way of translating CSV data then that might translate to general usability improvements for entering LOD data. On Aug 9, 2010, at 18:37 , Wood, Jamey wrote: Are there any established best practices for converting CSV data into LOD-friendly RDF? For example, I would like to produce an LOD-friendly RDF version of the 2001 - Present Net Generation by State by Type of Producer by Energy Source CSV data at: http://www.eia.doe.gov/cneaf/electricity/epa/epa_sprdshts_monthly.html I'm attaching a sample of a first stab at this. Questions I'm running into include the following: 1. Should one try to convert primitive data types (particularly strings) into URI references? Or just leave them as primitives? Or perhaps provide both (with separate predicate names)? For example, the sample EIA data I reference has two-letter state abbreviations in one column. Should those be left alone or converted into URIs? 2. Should one merge separate columns from the original data in order to align to well-known RDF types? For example, the sample EIA data has separate Year and Month columns. Should those be merged in the RDF version so that an xs:gYearMonth type can be used? 3. Should one attempt to introduce some sort of hierarchical structure (to make the LOD more browseable)? The skos:related triples in the attached sample are an initial attempt to do that. Is this a good idea? If so, is that a reasonable predicate to use? If it is a reasonable thing to do, we would presumably craft these triples so that one could navigate through the entire LOD (e.g. state - state/year - state/year/month - state/year/month/typeOfProducer - state/year/month/typeOfProducer/energySource). 4. Any other considerations that I'm overlooking? Thanks, Jamey generation_state_mon.rdf -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
An interactive shell for teaching RDF
I wanted a hands-on session for my lecture on RDF, so I added an interactive shell to Hyena: http://2ality.blogspot.com/2010/07/teaching-rdf.html I'd be interested to know what others use to teach RDF (in a tutorial style). Axel -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: connected information manager, free at hypergraphs.de/hyena/
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
I use RDF like a next-generation relational database and think that RDF could be sold to many people this way (there is possibly are larger audience for this than for ontologies, reasoning, etc.). Especially considering how No-SQL is currently taking off. This part needs some love and seems to suffer from the almost exclusive focus on semantics. Fair enough. I guess Im not sure how this next-generation-RDB usage fits with the RDF semantics, but I'd be interested in pursuing this further. Does this RDF/RDB++ vision provide any guidance towards what RDF is supposed to, like, mean? Pointers? Does it have to mean anything? I’ve always found tuple calculus and relational algebra quite intuitive, but as far as I remember, it is very light on semantics, everything is just data. URIs as symbols are useful, but I would not know how to express the concepts they represent formally. What else is needed? A simple schema language, which should probably assume a closed world and unique names (unless specified otherwise). I’m surprised how something that is trivial (and common!) for relational databases is very hard for SPARQL (for example, letting SPARQL return a table where each row is a resource [1]). Additionally, it would be useful if SPARQL allowed one to do backward-chaining via rules (some RIF implementations seem to do this). I can only come up with a few use-cases (sub-properties, transitive properties), but those would definitely help. [1] http://www.w3.org/2009/12/rdf-ws/papers/ws17 There might not be anything in it, scientifically, but it would help to sell RDF to a community that is largely orthogonal to the one that is after RDF + semantics. -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: connected information manager, free at hypergraphs.de/hyena/
Re: Subjects as Literals
How about internationalization? If the subject is a literal, how would translations be associated? On Jul 1, 2010, at 5:14 , Pat Hayes wrote: On Jun 30, 2010, at 8:14 PM, Ross Singer wrote: I suppose my questions here would be: 1) What's the use case of a literal as subject statement (besides being an academic exercise)? A few off the top of my head. 1. Titles of books, music and other works might have properties such as the date they were registered, who owns them, etc.. 2. Dates may have significant properties such as being the day that someone was shot or when war broke out. 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . I am sure that you can think of many more. In general, allowing strings as subjects opens the door to a wide range of uses of RDF to 'attach' information to pieces of text. Another example which occurs to me: this piece of text is the French translation of that piece of text, expressed as a single RDF triple with two literals. 4. It has been noted that one can map datatyping into RDF itself by treating the datatypes as properties, and there are several use cases for this. The natural way to do it involves having literals as subject, since the dataype map goes from the string to the value: 23 xsd:number 23^^xsd:number . 5. Also, allowing this purely academically has the notable advantage of simplifying RDF(S) inferencing, including making the forward-chaining rules simpler. Right now, there is a strange oddity involving blank node instantiations. One can say things like 'the number of my children is prime by using an blank node: :PatHayes hasNumberOfKids _:x . _:x :a :PrimeNumber . But this legal RDF can't be instantiated in the obvious way: :PatHayes hasNumberOfKids 3^^xsd:number . 3^^xsd:number :a PrimeNumber . This trips up RDFS reasoners, which can often produce inferences by a kind of sneaky use-a-bnode-instead maneuver even when the obvious conclusion cannot be stated because of the restriction. (There are a few examples in the RDF semantics document.) Removing the restriction would enable reasoners to work more efficiently with a smaller set of rules. (I gather that at least some of the RDFS rule engines out there already do this, internally.) 2) Does literal as subject make sense in linked data (I ask mainly from a follow your nose perspective) if blank nodes are considered controversial? Seems to me that from the linked data POV, anything that can be an object should also be useable as a subject. Of course, that does allow for the view that both of them should only ever be IRIs, I guess. Pat Hayes -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ :: Hyena: connected information manager, free at hypergraphs.de/hyena/ ::
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Intuitively, I would expect each subject literal to have a unique identity. For example, I would want to annotate a particular instance of abc and not all literals abc. Wouldn't the latter treatment make literals-as-subjects less appealing? Re. the DL police: I use RDF like a next-generation relational database and think that RDF could be sold to many people this way (there is possibly are larger audience for this than for ontologies, reasoning, etc.). Especially considering how No-SQL is currently taking off. This part needs some love and seems to suffer from the almost exclusive focus on semantics. Axel On Jun 30, 2010, at 21:52 , David Booth wrote: On Wed, 2010-06-30 at 14:09 -0500, Pat Hayes wrote: On Jun 30, 2010, at 11:50 AM, Nathan wrote: [ . . . ] Surely all of the subjects as literals arguments can be countered with 'walk round it', and further good practise could be aided by a few simple notes on best practise for linked data etc. I wholly agree. Allowing literals in subject position in RDF is a no- brainer. I agree, but at the W3C RDF Next Steps workshop over the weekend, I was surprised to find that there was substantial sentiment *against* having literals as subjects. A straw poll showed that of those at the workshop, this is how people felt about having an RDF working group charter include literals as subjects: http://www.w3.org/2010/06/28-rdfn-minutes.html Charter MUST include: 0 Charter SHOULD include:1 Charter MAY include: 6 Charter MUST NOT include: 12 Readers, please note that this was a non-binding, informative STRAW POLL ONLY -- not a vote. Pat, I wish you had been there. ;) David (BTW, it would also immediately solve the 'bugs in the RDF rules' problem.) These arguments against it are nonsensical. The REAL argument against it is that it will mess up OWL-DL, or at any rate it *might* mess up OWL-DL. The Description Logic police are still in charge:-) Pat Best, Nathan IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic. -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ :: Hyena: connected information manager, free at hypergraphs.de/hyena/ ::
SPARQL: sorting resources by label?
The closest I get is the following SPARQL query:
SELECT DISTINCT ?subj ?label
WHERE {
GRAPH ?graph {
?subj ?pred ?obj .
OPTIONAL {
?subj ?labelPred ?label .
FILTER (
(?labelPred = http://www.w3.org/2000/01/rdf-schema#label) #
(1)
)
FILTER( isLiteral(?label) )
}
}
FILTER (?graph = http://hypergraphs.de/TestGraph)
}
ORDER BY ?label ?subj
Comments:
- This solution also works for multiple label predicates (i.e., if there are
subproperties of rdfs:label), then the unary disjunction (1) has more
components.
- ?graph is necessary, because Sesame does not support datasets and I want to
restrict the query to all graphs that are currently visible.
- This query returns unlabeled resources first (?label is unbound), then
labeled resources. Better would be to show labeled resources first. Best would
be to mix them, where unlabeled resources are sorted according to their qname.
Can this be improved?
Thanks for any comments or suggestions...
Axel
--
axel.rauschma...@ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/
Re: SPARQL: sorting resources by label?
I have a GUI data structure that is a pair (resource, label). The label is used
for humans, the resource is used to process RDF.
If I want SPARQL to produce list of these pairs ordered by label, this is the
simplest query that I can think of.
This is but a start, I will later insert more FILTERs (for faceted navigation
etc.).
Axel
On Mar 13, 2010, at 4:51 , Danny Ayers wrote:
On 13 March 2010 04:16, Axel Rauschmayer a...@rauschma.de wrote:
Thanks for any comments or suggestions...
I'm a little perturbed that you have to use something so convoluted to
get labels
Why not something just like (whatever graph) SELECT ?o WHERE { ?s
rdfs:label ?o } , or at worse an OPTIONAL on maybe dc:label or
whatever..?
- are the objects of any labels resources?
Can you please clarify what you are looking for, and explain further -
I honestly hope you are missing something there.
If there is something wrong with the material, the problems should be
surfaced and fixed (and no doubt will be for the next rev, if need be)
Cheers,
Danny.
http://danny.ayers.name
--
axel.rauschma...@ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/
Re: SPARQL: sorting resources by label?
Addendum:
If one wants to produce a table
| URI | label | types |
SPARQL becomes even more unwieldy. Just think of sorting the type column by
the label of the types. Or even of producing a Java object for each row. The
problem is that SPARQL does not support query rows in NFNF. Maybe DESCRIBE can
be used in the future for this?
Axel
On Mar 13, 2010, at 4:51 , Danny Ayers wrote:
On 13 March 2010 04:16, Axel Rauschmayer a...@rauschma.de wrote:
Thanks for any comments or suggestions...
I'm a little perturbed that you have to use something so convoluted to
get labels
Why not something just like (whatever graph) SELECT ?o WHERE { ?s
rdfs:label ?o } , or at worse an OPTIONAL on maybe dc:label or
whatever..?
- are the objects of any labels resources?
Can you please clarify what you are looking for, and explain further -
I honestly hope you are missing something there.
If there is something wrong with the material, the problems should be
surfaced and fixed (and no doubt will be for the next rev, if need be)
Cheers,
Danny.
http://danny.ayers.name
--
axel.rauschma...@ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/
Re: Why are RDF containers (rdf:Seq etc.) so little appreciated?
Im not sure what you mean by 'stable identity', It's a slightly (possibly unorthodox) viewpoint I take during RDF editing: With a container, you can say I will edit the sequence at URI X and be sure that X stays the same, no matter how you change the elements. With a collection, the anchor changes whenever one goes from 0 elements to 1 or more elements (or vice versa). Giving a collection a stable identity seems to have been one of the motivations behind skos:OrderedCollection. but the chief problem with containers is the fact that there is no way to 'close' them. If I say that FOO is a container and A, B and C are in it, there is no way to say that this is *all* that is in it. This makes them useless for encoding structures, eg OWL syntax. Collections' overcome this difficulty. So the collection notion is widely used to layer higher-level notations onto RDF, which is probably why toolkits have special provision for them. I see the point, but it seems like one could achieve the same effect by adding an additional nil element (at the end) to a container. This does not stop you using the containers, of course. They are simple enough that you hardly need syntactic sugar, right? True. -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Why are RDF containers (rdf:Seq etc.) so little appreciated?
In contrast to RDF collections (rdf:List), they have a stable identity and don't use nested resources (=easy to remove). Furthermore, standard RDFS inferencing can be used to infer membership as the property rdfs:member. Yet, most RDF vocabularies that I know of use collections and syntaxes such as Turtle have syntactic sugar for collections, but not for containers. Why is that? Axel -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: [fresnel] Fresnel: State of the Art?
Our goal with the first release of the Fresnel vocabulary in 2006 was to have more people (beyond us) play with it in different contexts and get feedback so that the language could be enhanced iteratively. Maybe it is now time to do such an iteration? I am working on my own Fresnel 2. The spec should be finished in the coming 3 months. It strips Fresnel to what features I consider minimal and adds other things that I've found useful, including editing features. If anyone is interested, I can make this spec public once it is finished and then everyone can comment on it. If someone thinks that I've left out an important feature, we now have the advantage of concrete use cases when adding it back in. That way, we should arrive at a streamlined new Fresnel. I would argue in favor of breaking compatibility, for the sake of simplicity. A script could be used to translate F1 to F2. I do not want to impose and if what I do proves too controversial, I can always fork. If there is to be a version 2 of Fresnel, a small group of people (5 max) should have the final word, to avoid design by committee, where one tries to fulfill all wishes, but ends up fulfilling none. All this after carefully considering all community input, obviously. Greetings, Axel -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: [fresnel] Fresnel: State of the Art?
I think, it would make sense at some point in time to work on Fresnel 2. My experiences (while implementing editing extensions for Fresnel for Hyena [1]) were as follows: - Fresnel works great for editing, with a few extensions. I've found some things to be too complicated (mainly formats and the rules for applying them) for my taste, so I would simplify those for Fresnel 2. - For HTML *display*, I now prefer templating (with ideas similar to JSP). It gives you more control and is conceptually very simple. RDF templating would benefit from standardizing, too; I've just recently seen a paper somewhere that describes (yet another...) RDF templating mechanism. - Fresnel is still useful for editing and for targetting multiple display architectures (e.g. HTML and PDF, e.g. via iText). It is perfect when a form is all you need. [1] http://hypergraphs.de/hyena/ Does this make sense? Does anyone (dis)agree (possibly vehemently ;-) ? Axel On Feb 1, 2010, at 14:44 , Aldo Bucchi wrote: Hi, I was looking at the current JFresnel codebase and the project seems to have little movement. I was wondering if this is the state of the art regarding Declarative Presentation Knowledge for RDF or have efforts moved elsewhere and I have missed it? Thanks! A -- Aldo Bucchi skype:aldo.bucchi http://www.univrz.com/ http://aldobucchi.com/ PRIVILEGED AND CONFIDENTIAL INFORMATION This message is only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If you are not the intended recipient, please do not distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail. -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: Context Tags, Context Sets and Beyond Named Graphs...
This description reminds me of NRL, maybe it is closer to what you need. http://www.semanticdesktop.org/ontologies/nrl/ Axel On Jan 18, 2010, at 21:47 , Leigh Dodds wrote: Hi Jeni, 2010/1/18 Jeni Tennison j...@jenitennison.com: Do you think that http://www.w3.org/2004/03/trix/rdfg-1/ is sufficient for describing the relationships between graphs (for these purposes) and if not, what do you think needs adding? No I don't think its sufficient, certainly not for the kinds of use cases that Paul was describing. The RDFG schema only has two properties defining equivalency and a sub-set relationship. I was thinking more along the lines of a means to describe the process of constructing a graph by operations on a set of other graphs, where those operations would include basic algrebra operators. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: Distributed versioning for RDF?
Looks nice, but only works for keeping a history, not for selectively accessing older versions (right?). On Jul 30, 2009, at 15:21 , Ian Davis wrote: Have you looked into changesets which is used by the Talis Platform? See http://n2.talis.com/wiki/Changesets and http://vocab.org/changeset/schema.html Ian On Wed, Jul 29, 2009 at 2:37 PM, Axel Rauschmayera...@rauschma.de wrote: Offhand, I see the following requirements for many (mostly social) RDF applications: - text indexing - text diff for versioning - distributed versioning and synchronization. http://en.wikipedia.org/wiki/Distributed_version_control - provenance: author, data source (which might have named graphs) Open Anzo [1] and OpenLink Data Spaces [2] come pretty close, but, as far as I can tell, don't offer distributed versioning. Is there anything else out there that I might have missed? Thanks! Axel [1] http://www.openanzo.org/ [2] http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/Ods -- Axel Rauschmayer a...@rauschma.de http://www.pst.ifi.lmu.de/people/staff/rauschmayer/axel-rauschmayer/ http://2ality.blogspot.com/ http://hypergraphs.de/ -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: Distributed versioning for RDF?
Yes. I meant (and want) live access, but would never expect an RDF schema to provide this. ;-) Changesets seem very useful for exporting histories. Axel On Jul 30, 2009, at 15:45 , Ian Davis wrote: On Thu, Jul 30, 2009 at 2:41 PM, Axel Rauschmayera...@rauschma.de wrote: Looks nice, but only works for keeping a history, not for selectively accessing older versions (right?). It's a linked changelog so older versions are reconstructable Ian -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: Alternatives to OWL for linked data?
You were asking about description logic programming; well, OWL 2 RL: http://www.w3.org/TR/owl2-profiles/#OWL_2_RL is exactly that: it is a manifestation of DLP. It has a Direct Semantics 'side', compatible with OWL 2 DL, and a rule based 'side', described by the rule set: http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules This rule set can be used for a forward or backward chaining approach (or a combination thereof) that you describe. I have heard rumours and/or statements on implementations coming up from various vendors. I have, actually, a purely proof-of-concept-stupid-simple implementation doing brute force forward chaining: http://www.ivan-herman.net/Misc/2008/owlrl/ Just to show what happens. And I am sure other implementations will come to the fore that I do not yet about. Cool stuff. How would backward chaining work? Would it be invoked via SPARQL? Is listing all properties of a given resource still possible? Axel -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Alternatives to OWL for linked data?
I'm currently reading Hendler's brilliant book Semantic Web for the Working Ontologist. It really drove home the point that OWL is not a good fit when using RDF for *data* (names are generally not unique, open world assumption, ...). But what is the alternative? For my applications, I have the following requirements: - Properties: transitivity, inverse, sub-properties. - Resources, classes: equivalence. For my purposes, equivalence is a way of implementing the topic merging in topic maps [1]. - Constraints for integrity checking. - Schema declaration: partially overlaps with constraints, serves for documentation and for providing default values for properties. - Computed property values: for example, one property value being the concatenation of two other property values etc. The difficulty seems to me to find something universal that fulfills these requirements and is still easy to understand. Inference, when used for transitivity and equivalence, is simple, but when it comes to editing RDF, they can confound the user: Why can some triples be replaced, others not? Why do I have to replace the triples of a different instance if I want to replace the triples in my instance? While it's not necessarily easier to understand for end users, I've always found Prolog easy to understand, where OWL is more of a challenge. So what solutions are out there? I would prefer description logic programming to OWL. Does Prolog-like backward-chaining make sense for RDF? If so, how would it be combined with SPARQL; or would it replace it? Or maybe something frame-based? Am I making sense? I would appreciate any pointers, hints and insights. Axel [1] http://www.topicmaps.org/xtm/index.html#desc-merging -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: Alternatives to OWL for linked data?
Thanks, looks interesting. I've also found related work: https://www.uni-koblenz-landau.de/koblenz/fb4/institute/IFI/AGStaab/Research/systeme/NetworkedGraphs/ But there does not seem to be a library one can use with, say, Sesame. On Jul 24, 2009, at 15:43 , Martin Hepp (UniBW) wrote: Did you look at SPIN? http://spinrdf.org/ That should allow you do do a lot with data without leaving the now mainstream Semantic Web technology stack (as long as a small fragment of OWL is sufficient for you). Best Martin Axel Rauschmayer wrote: I'm currently reading Hendler's brilliant book Semantic Web for the Working Ontologist. It really drove home the point that OWL is not a good fit when using RDF for *data* (names are generally not unique, open world assumption, ...). But what is the alternative? For my applications, I have the following requirements: - Properties: transitivity, inverse, sub-properties. - Resources, classes: equivalence. For my purposes, equivalence is a way of implementing the topic merging in topic maps [1]. - Constraints for integrity checking. - Schema declaration: partially overlaps with constraints, serves for documentation and for providing default values for properties. - Computed property values: for example, one property value being the concatenation of two other property values etc. The difficulty seems to me to find something universal that fulfills these requirements and is still easy to understand. Inference, when used for transitivity and equivalence, is simple, but when it comes to editing RDF, they can confound the user: Why can some triples be replaced, others not? Why do I have to replace the triples of a different instance if I want to replace the triples in my instance? While it's not necessarily easier to understand for end users, I've always found Prolog easy to understand, where OWL is more of a challenge. So what solutions are out there? I would prefer description logic programming to OWL. Does Prolog-like backward-chaining make sense for RDF? If so, how would it be combined with SPARQL; or would it replace it? Or maybe something frame-based? Am I making sense? I would appreciate any pointers, hints and insights. Axel [1] http://www.topicmaps.org/xtm/index.html#desc-merging -- -- martin hepp e-business web science research group universitaet der bundeswehr muenchen e-mail: mh...@computer.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out GoodRelations for E-Commerce on the Web of Linked Data! = Webcast: http://www.heppnetz.de/projects/goodrelations/webcast/ Recipe for Yahoo SearcMonkey: http://tr.im/rAbN Talk at the Semantic Technology Conference 2009: Semantic Web-based E-Commerce: The GoodRelations Ontology http://tinyurl.com/semtech-hepp Overview article on Semantic Universe: http://tinyurl.com/goodrelations-universe Project page: http://purl.org/goodrelations/ Resources for developers: http://www.ebusiness-unibw.org/wiki/GoodRelations Tutorial materials: CEC'09 2009 Tutorial: The Web of Data for E-Commerce: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey http://tr.im/grcec09 martin_hepp.vcf -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
